Implementing std.log

[Jacob Carlborg]

On 2011-05-10 16:41, Andrei Alexandrescu wrote:
> 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
>

Well, I only brought it up because I didn't know about Runtime.args.

-- 
/Jacob Carlborg