Thread overview
expression results
Apr 13, 2007
bobef
Apr 17, 2007
Davidl
Apr 18, 2007
bobef
Apr 19, 2007
Jascha Wetzel
Apr 19, 2007
Jascha Wetzel
Apr 17, 2007
Ary Manzana
Apr 19, 2007
Jascha Wetzel
April 13, 2007
Hello. I have some notes regarding the expression results.

Multiline strings are impossible to parse. Consider this example

char[] str="line 1\n line \" more";

In ddbg
= str
will look something like this

->= str
"line1
 line " more"

so the end could not be determined.
Also char ch=255; results "4invalid utf8 sequence" in the results.
I suggest the type of the variable to be indicated in the output with one letter including the string length. Then the chars could be printed as decimal/hex value and if they are valid utf8 the symbol itself could be printed too.
April 17, 2007
no, i would rather printed in the non-utf8 form. since most locale
doesn't use utf8 and seeing their decimal/hex value is nonsense in
most case of a string.
I would appreciate another command to show it in ur way

> Hello. I have some notes regarding the expression results.
>
> Multiline strings are impossible to parse. Consider this example
>
> char[] str="line 1\n line \" more";
>
> In ddbg
> = str
> will look something like this
>
> ->= str
> "line1
>  line " more"
>
> so the end could not be determined.
> Also char ch=255; results "4invalid utf8 sequence" in the results.
> I suggest the type of the variable to be indicated in the output with one letter including the string length. Then the chars could be printed as decimal/hex value and if they are valid utf8 the symbol itself could be printed too.

April 17, 2007
bobef escribió:
> Hello. I have some notes regarding the expression results.
> 
> Multiline strings are impossible to parse. Consider this example
> 
> char[] str="line 1\n line \" more";
> 
> In ddbg
> = str
> will look something like this
> 
> ->= str
> "line1
>  line " more"
> 
> so the end could not be determined.
> Also char ch=255; results "4invalid utf8 sequence" in the results.
> I suggest the type of the variable to be indicated in the output with one letter including the string length. Then the chars could be printed as decimal/hex value and if they are valid utf8 the symbol itself could be printed too.

The above string could be shown by ddbg as:

"line 1\n line \" more"
April 18, 2007
I mean hex for chars not for strings. For strings maybe enitities...

Davidl Wrote:

> no, i would rather printed in the non-utf8 form. since most locale
> doesn't use utf8 and seeing their decimal/hex value is nonsense in
> most case of a string.
> I would appreciate another command to show it in ur way
> 
> > Hello. I have some notes regarding the expression results.
> >
> > Multiline strings are impossible to parse. Consider this example
> >
> > char[] str="line 1\n line \" more";
> >
> > In ddbg
> > = str
> > will look something like this
> >
> > ->= str
> > "line1
> >  line " more"
> >
> > so the end could not be determined.
> > Also char ch=255; results "4invalid utf8 sequence" in the results.
> > I suggest the type of the variable to be indicated in the output with
> > one letter including the string length. Then the chars could be printed
> > as decimal/hex value and if they are valid utf8 the symbol itself could
> > be printed too.
> 

April 19, 2007
...which is what the next release will be doing.

Ary Manzana wrote:
> bobef escribió:
>> Hello. I have some notes regarding the expression results.
>>
>> Multiline strings are impossible to parse. Consider this example
>>
>> char[] str="line 1\n line \" more";
>>
>> In ddbg
>> = str
>> will look something like this
>>
>> ->= str
>> "line1
>>  line " more"
>>
>> so the end could not be determined.
>> Also char ch=255; results "4invalid utf8 sequence" in the results.
>> I suggest the type of the variable to be indicated in the output with
>> one letter including the string length. Then the chars could be
>> printed as decimal/hex value and if they are valid utf8 the symbol
>> itself could be printed too.
> 
> The above string could be shown by ddbg as:
> 
> "line 1\n line \" more"
April 19, 2007
i'll add a command to switch between utf8 and ascii output. i think that it's okay to have utf8 by default, since it's the default for D too.

Davidl wrote:
> no, i would rather printed in the non-utf8 form. since most locale
> doesn't use utf8 and seeing their decimal/hex value is nonsense in
> most case of a string.
> I would appreciate another command to show it in ur way
> 
>> Hello. I have some notes regarding the expression results.
>>
>> Multiline strings are impossible to parse. Consider this example
>>
>> char[] str="line 1\n line \" more";
>>
>> In ddbg
>> = str
>> will look something like this
>>
>> ->= str
>> "line1
>>  line " more"
>>
>> so the end could not be determined.
>> Also char ch=255; results "4invalid utf8 sequence" in the results.
>> I suggest the type of the variable to be indicated in the output with
>> one letter including the string length. Then the chars could be
>> printed as decimal/hex value and if they are valid utf8 the symbol
>> itself could be printed too.
> 
April 19, 2007
the next release will ouput single characters (char, wchar and dchar) as
hex numbers.

bobef wrote:
> I mean hex for chars not for strings. For strings maybe enitities...
> 
> Davidl Wrote:
> 
>> no, i would rather printed in the non-utf8 form. since most locale
>> doesn't use utf8 and seeing their decimal/hex value is nonsense in
>> most case of a string.
>> I would appreciate another command to show it in ur way
>>
>>> Hello. I have some notes regarding the expression results.
>>>
>>> Multiline strings are impossible to parse. Consider this example
>>>
>>> char[] str="line 1\n line \" more";
>>>
>>> In ddbg
>>> = str
>>> will look something like this
>>>
>>> ->= str
>>> "line1
>>>  line " more"
>>>
>>> so the end could not be determined.
>>> Also char ch=255; results "4invalid utf8 sequence" in the results.
>>> I suggest the type of the variable to be indicated in the output with
>>> one letter including the string length. Then the chars could be printed
>>> as decimal/hex value and if they are valid utf8 the symbol itself could
>>> be printed too.
>