Re: debugger suggestions

[Chad MILLER]

On 25 Mar 2007, at 14:08, Jocelyn Fournier wrote:
> Just curious : what kind of OS / Debugger are you used to use  
> inside MySQL ?
> At work I'm using solaris 10 + workshop/sunstudio (dbx) on SPARC  
> hardware which is fine, but at home I'm trying to use kubuntu +  
> KDbg (gdb), and unfortunately I'm not happy with the result...

We don't use a particular environment or OS.  Internally, we're as  
heterogeneous as the rest of our users; in fact, I think we'd  
consider it a dire emergency if we were a monoculture and not a cross- 
section of the community.

I use mostly Ubuntu and plain old GDB or I'll pepper the source code  
with printfs (DBUG_PRINT, to be exact).  When the pointers are so  
complex that I'd need paper to graph them, I usually resort to DDD.

- chad


> Chad MILLER a écrit :
>> [add CC jimw]
>> On 20 Mar 2007, at 11:32, joce@stripped wrote:
>>> I assume implementing %f is linked to WL#2934 ?
>> Hi Jocelyn.
>> No, I don't think there's a dependent relationship.  It would be  
>> nice to have WL#2934 implemented, but clever use of mundane sprintf 
>> () could solve this specific case well enough until it is.  We'll  
>> want to put a note in that worklog to refactor my_snprintf()  
>> later.  We're obviously not using "%f" in many places, and here  
>> it's not something that would trigger the platform-specific  
>> variances in values.
>>> What's the status of the functions in decimal.c ?
>>> (especially double2decimal and decimal2string)
>> Heh, I didn't know until I just now looked.   double2decimal()  
>> uses sprintf(s, "%.16G", from) to get to a string, and then  
>> converts that string to the internal decimal type.  That's  
>> somewhere we'll eventually refactor when WL#2934 is implemented.   
>> So, if you think you'd like to use that, I imagine it's okay.
>> - chad
>>>>
>>>>> --- sql_parse.cc.old    2007-03-03 17:53:15.000000000 +0100
>>>>> +++ sql_parse.cc    2007-03-03 17:53:31.000000000 +0100
>>>>> @@ -2119,7 +2119,7 @@
>>>>>             &LOCK_status);
>>>>>      calc_sum_of_all_status(&current_global_status_var);
>>>>>      uptime= (ulong) (thd->start_time - start_time);
>>>>> -    length= my_snprintf((char*) buff, buff_len - 1,
>>>>> +    length= snprintf((char*) buff, buff_len - 1,
>>>>>                          "Uptime: %lu  Threads: %d  Questions: % 
>>>>> lu  "
>>>>>                          "Slow queries: %lu  Opens: %lu  Flush
>>>>> tables: %lu  "
>>>>>                          "Open tables: %u  Queries per second avg:
>>>>> %.3f",
>>>>
>>>>
>>>> In addition to Sergei's comment that we should never use snprintf()
>>>> outside the check for HAVE_SNPRINTF, the return value of snprintf()
>>>> varies across implementations, so we should never even trust  
>>>> "length"
>>>> in this case.  Thus, another reason we can't accept this approach.
>>>> You're right, that adding floating-point decoding to my_snprintf 
>>>> () is
>>>> the right approach.
>>>>
>>>> Jocelyn, are you comfortable implementing "%f"?
>>>>
>>>> - chad
>> -- 
>> Chad Miller, Software Developer                          
>> chad@stripped
>> MySQL Inc., www.mysql.com
>> Orlando, Florida, USA                                13-20z,   
>> UTC-0400
>> Office: [phone]                         sip: 
>> 6740@stripped
>
> -- 
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals? 
> unsub=cmiller@stripped
>

--
Chad Miller, Software Developer                         chad@stripped
MySQL Inc., www.mysql.com
Orlando, Florida, USA                                13-20z,  UTC-0400
Office: [phone]                         sip:6740@stripped



Attachment: [application/pgp-signature] This is a digitally signed message part PGP.sig