Re: [pdt-dev] PDT 2.0 and use of encodings for remote debug

[Dave Kelsey <d_kelsey@xxxxxxxxxx>]

Hi Michael,

I plan to use the output encoding in
define the encoding sent to the debug and browser output views in the same
manner as zend and I think that is a good thing to be able to define.
For small strings I will having a single
collapsed entity as you describe, but I will definitely split it for large
strings otherwise it becomes unusable witrhin the variables view.

I am still not convinced that transfer
encoding is only used for php string binary data. I see it as being similar
to the DBGp encoding which defines the encoding which the commands and
responses are sent over the wire. It doesn't dictate the encoding to use
to convert a php string to a java.lang.String. However I could use that
preference specifically for that meaning within the xdebug environment.

Best regards

Dave Kelsey



pdt-dev-bounces@xxxxxxxxxxx wrote on 06/08/2008 15:03:24:

> Hi,

> 2008/8/6 Dave Kelsey <d_kelsey@xxxxxxxxxx>
> 
> My initial thoughts are 
> 
> for 1: have a dual byte string representation in the variable view
> for example (see screen shot - if it works :-)  ) 
> 
> [image removed] 
> 
> May be binary representation should be collapsed initially into some
node?
> 
> Something like that:
> 
>      length = 1024
> [+] binary representation
> 
>  
> 
> 
> and for 2, I was thinking about having a data encoding preference
as
> a first step and the ability to change that encoding for a string
> using a pop up menu item in the variables view in a later step. 
> 
> I think existing transfer encoding is a data encoding that your are
> talking about (at least by design).
> I don't remember why there's a special preference for Output 
> Encoding, which is used only for receiving a script output from a
> debugger (may be for the case when you have $var containing 
> something in Hebrew, but actual script output is in Chinese...)
> Anyway, we should either reuse transfer encoding or remove it as 
> deprecated (and think whether Output encoding is really needed).
>  
> 
> 
> transfer encoding remains the same but isn't used to decode php 
> strings into java lang strings. 
> 
> Dave Kelsey
> 
> 
> pdt-dev-bounces@xxxxxxxxxxx wrote on 06/08/2008 14:10:11:
> 
> > 
> > Hi,
> 
> > 2008/8/6 Dave Kelsey <d_kelsey@xxxxxxxxxx> 
> > 
> > Hi Michael, it looks like transfer encoding applies to things
like 
> > stack frames as well for example. I see transfer encoding is
the 
> > encoding to use when converting the binary wire data into java.lang.
> > String so that is a fixed encoding that I would assume is agreed
> > between the zend debugger and PDT when a debug session starts,
and 
> > configurable by the user. 
> > 
> > The problem I see is that a PHP String can contain 2 types of
data 
> > 
> > 1. Binary data - This cannot be converted to a java.lang.String
so 
> > should have a useful representation within the eclipse variable
view
> > such as a byte presentation. 
> > 2. Character data = "" should be converted to a java.lang.String
> > based on the encoding this data is in. The question is what encoding
> > is it in ? the php script knows and one solution could be for
the 
> > user  to set the transfer encoding to the same as this in
order to 
> > view it, but the transfer encoding is also used for other things
so 
> > I am not sure that this encoding setting should be used for this
> > purpose. Also the transfer encoding has a limited set of encodings
> > allowed and what if the character data is in a Japanese code
for example. 
> > 
> > That's true (Eclipse limitation, I think), but the combo-box
is 
> > editable and one can enter in any encoding he likes. 
> > 
> > In the case of 1, a PHP string could have some child variables
that 
> > represent the length and a byte array so that you can view the
data 
> > as a byte array 
> > In the case of 2, there needs to be some sort of default for
PHP 
> > String encodings and maybe the possibility of being able to override
> > that default within the variables view in the small case where
a php
> > script may have multiple strings containing character data in
> > different encodings. 
> > 
> > If I understand correctly, do you propose configuration of transfer
> > encoding per file or even per variable? Won't it make the 
> > configuration more difficult to user?
> >   
> > 
> > 
> > I am currently looking to see how to address these problems for
> > XDebug and think that the problem must also be common for the
zend 
> > debugger as well and wondered if anything was being done in this
> > area ? I don't think I will get around to solving 2, but I hope
to 
> > solve 1 at least. 
> > 
> > Dave Kelsey
> > 
> > 
> > pdt-dev-bounces@xxxxxxxxxxx wrote on 06/08/2008 13:17:01: 
> > 
> > 
> > > 
> > > Hi,
> > > 
> > > Output and Transfer encodings are only applied to variable
and 
> > > output views. Besides that debug process should work as
usual.
> > > Is there any specific problem you see with variables containing
> binary data?
> > > 
> > > Thanks! 
> > 
> > > 2008/8/6 Dave Kelsey <d_kelsey@xxxxxxxxxx> 
> > > 
> > > I am looking at the various areas where encoding applies
and the 
> > > current configurable options available in PDT 2.0 
> > > 
> > > The output encoding looks like it only applies to output
from the 
> > > php script which will be displayed in the Debug and Browser
output views. 
> > > 
> > > The transfer encoding applies to the binary data that flows
over the
> > > wire (so must be in sync with the encoding used by the debug
engine 
> > > when sending information such as stack frame names, variable
names 
> > > etc). It also looks like the transfer encoding is used to
convert 
> > > php string information to Java.lang.String for display in
the 
> > > variables display. 
> > > 
> > > Is this correct ? 
> > > 
> > > One of the issues I have is that in php strings (ignoring
php6 at 
> > > present) can contain binary or character data. The character
data 
> > > and the encoding that correctly represents that data is
known to the
> > > php program and could very well be different to the transfer
encoding. 
> > > 
> > > A Common problem I see for both Zend and XDebug debug environments
> > > is a user may want to have a binary representation of a
php string 
> > > in the debugger or may want to display the string based
on a user 
> > > selected encoding. 
> > > 
> > > Is anyone looking at this issue for PDT 2.0 ? I haven't
had the 
> > > opportunity to investigate it but it seems to me that the
solution 
> > > should be common for any installed debugger. 
> > > 
> > > regards 
> > > Dave Kelsey
> 
> 
> 
> 
> 

> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with
> number 741598. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
PO6 3AU 
> 
> 
> 
> 

> 
> _______________________________________________
> pdt-dev mailing list
> pdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pdt-dev

> 
> 
> 
> -- 
> Michael_______________________________________________
> pdt-dev mailing list
> pdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/pdt-dev

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU