adobe-source-devel — ASL development topic discussion

[Adobe-source-devel] group nesting issues windows

[Thomas W. <wi...@ac...>]

Hi,

attached are sheets that demonstrate what I think are nesting issues 
with the group widget on Windows. On Windows XP the nested group uses a 
bigger font for the group name and the overlay displays as one black block.

Regards

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Begin crash

[Thomas W. <wi...@ac...>]

On Jan 3, 2006, at 6:38 PM, Thomas Witt wrote:

>
> Trying to load the attached files will make begin crash in the last  
> line of the following code snippet (line wrapping due to mailer):

Ok, I could narrow it down a little. Every use of an edit_number with  
an empty name will trigger this issue. The problem is that the poi_m  
vector is empty in this case. BTW this occurs on Windows.

HTH

Thomas


Thomas Witt
wi...@ac...

[Adobe-source-devel] Begin crash

[Thomas W. <wi...@ac...>]

Trying to load the attached files will make begin crash in the last line 
of the following code snippet (line wrapping due to mailer):

void edit_text_t::implementation_t::set_bounds(
    const point_2d_t& pos,
    const extents_t& geo)
{
	assert(control_m);

	point_2d_t		position(pos);
	extents_t	geometry(geo);

	geometry_m = geometry;
	long baseline =
	  geometry.slice_m[extents_slices_t::vertical].poi_m[0];

with a vector subscript out of range.

Thomas

PS: As a sidenote I've modified my local copy of begin to save a backup 
file on update this makes tracing these crashes a lot easier. Might be a 
usefull feature in general.

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Begin line ending handling

[Thomas W. <wi...@ac...>]

Sean,

On Dec 29, 2005, at 1:26 PM, Thomas Witt wrote:

> Sean,
>
> Sean Parent wrote:
>> On Dec 29, 2005, at 9:14 AM, Thomas Witt wrote:
>>> Sean,
>>>
>>> On Dec 28, 2005, at 10:44 PM, Sean Parent wrote:
>>>
>
>> The Begin  app has to convert to platform line endings at some  
>> point because the  OS controls deal with it that way.
>
> I think you are wrong here. I am pretty sure Windows deals in '\n'  
> only. Here is an excerpt from the MSDN docs regarding fopen.
>

Well I don't quite know how to put it, it seems in the end you are  
right. Even .Net controls seem to require CRLF in order to function  
correctly. This is puzzling on so many levels. I'll be hiding behind  
a copy of the "Unix Haters Handbook" for a while.

Humbly-yours

Thomas

Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] widget fixes win32

[Foster T. B. <fbr...@ad...>]

This patch has been applied. Thanks for the fixes, Thomas. Keep 'em  
coming!

Blessings,
Foster


On Dec 29, 2005, at 04:12p, Thomas Witt wrote:

>
> Hi,
>
> The attached patch fixes 2 issues with the widget implementation on  
> win32 that show up in begin.
>
> a) The text in an edit_text widget is truncated to 1023 char on  
> extraction. As a result loading any example in begin that is longer  
> than that (some are) and making a small modification will see the  
> update fail with a syntax error.
>
> b) The edit_text widget does not grow vertically. This makes  
> editing/viewing larger examples in Begin a pain. It works for begin  
> but this fix might need more review.
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
> Index: ui_core_implementation.cpp
> ===================================================================
> RCS file: /cvsroot/adobe-source/adobe-source/adobe/future/widgets/ 
> sources/win/ui_core_implementation.cpp,v
> retrieving revision 1.5
> diff -u -3 -p -u -r1.5 ui_core_implementation.cpp
> --- ui_core_implementation.cpp	2 Dec 2005 02:52:56 -0000	1.5
> +++ ui_core_implementation.cpp	30 Dec 2005 00:02:05 -0000
> @@ -245,11 +245,13 @@ std::string get_window_title(HWND window
>  {
>  	assert(window);
>
> -	std::vector<WCHAR> titlename;
> +  int const buffer_size = ::GetWindowTextLengthW(window) + 1;
>
> -	titlename.resize(1024);
> +  std::vector<WCHAR> titlename(buffer_size, 0);
>
> -	*(&titlename[::GetWindowTextW(window, &titlename[0], 1024)]) = 0;
> +  int const text_length = ::GetWindowTextW(window, &titlename[0],  
> buffer_size);
> +
> +  assert(text_length < buffer_size);
>
>  	return std::string(hackery::convert_utf(&titlename[0]));
>  }
> @@ -3143,7 +3145,10 @@ void edit_text_t::implementation_t::set_
>  	// alignment.
>  	//
>  	position.y_m += baseline - edit_baseline_m;
> -	geometry.height() = edit_height_m;
> +
> +  // Do we need to adapt the height for baseline alignment? (thw)
> +  // Disabled as it disables vertical align_fill (thw)
> +  // geometry.height() = edit_height_m;
>  	_super::set_bounds(position, geometry);
>  }
>

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"The fact is that the author of STL does not know how to write min,  
the author of C++ is not quite sure, and the standards committee is  
at a loss." -- Alexander Stepanov

Re: [Adobe-source-devel] Begin woes

[Foster T. B. <fbr...@ad...>]

The patch has been applied (it was actually fixed locally and due to  
be released in .12).

Blessings,
Foster

On Dec 30, 2005, at 10:13a, Thomas Witt wrote:

> Sean Parent wrote:
>> I've asked Foster to fix the Save button -
>
> The attached patch fixes the save button semantics. I.e. update  
> file buffer contents before save.
>
> Thomas
>
>
>> Please if you have any reproducible crashes let us know.
>> Sean
>> On Dec 28, 2005, at 3:51 PM, Thomas Witt wrote:
>>>
>>> Hi,
>>>
>>> Just a comment, the current semantics for the save button are   
>>> misleading (well at least to me). Currently the editor contents  
>>> and  the file contents are out of sync unless a successful update  
>>> was  done after the last edit.
>
> -- 
> Thomas Witt
> wi...@ac...
> Index: express_viewer.cpp
> ===================================================================
> RCS file: /cvsroot/adobe-source/adobe-source/adobe/test/begin/ 
> sources/express_viewer.cpp,v
> retrieving revision 1.6
> diff -u -3 -p -u -r1.6 express_viewer.cpp
> --- express_viewer.cpp	2 Dec 2005 02:52:56 -0000	1.6
> +++ express_viewer.cpp	30 Dec 2005 18:10:35 -0000
> @@ -304,9 +304,17 @@ void application_t::_editor_op( adobe::n
>  			display_window();
>  		}
>  		else if ( name == save_adam_name_g )
> -			{ _adam_file_m.save(); }
> +		{
> +      _adam_file_m.set_contents(result.begin(), result.end());
> +
> +      _adam_file_m.save();
> +    }
>  		else if ( name == save_eve_name_g )
> -			{ _eve_file_m.save(); }
> +		{
> +      _eve_file_m.set_contents(result.begin(), result.end());
> +
> +      _eve_file_m.save();
> +    }
>  		else
>  			system_beep(); // unknown request.
>  	}

--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"The fact is that the author of STL does not know how to write min,  
the author of C++ is not quite sure, and the standards committee is  
at a loss." -- Alexander Stepanov

Re: [Adobe-source-devel] widget fixes win32

[Thomas W. <wi...@ac...>]

Ralph.

Ralph Thomas wrote:
> Hi Thomas,
> 
>   The first change (to get_window_title) looks good. I assume that
> your issue with (2) is that the Begin window grows but the edit text
> widgets remain the same size. It seems like it should grow...

That's what it does on Mac.

> I'll
> test your change and verify that the baseline is correct.

Thanks!

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Begin woes

[Thomas W. <wi...@ac...>]

Sean Parent wrote:
> I've asked Foster to fix the Save button -

The attached patch fixes the save button semantics. I.e. update file 
buffer contents before save.

Thomas


> Please if you have any reproducible crashes let us know.
> Sean
> 
> On Dec 28, 2005, at 3:51 PM, Thomas Witt wrote:
> 
>>
>> Hi,
>>
>> Just a comment, the current semantics for the save button are  
>> misleading (well at least to me). Currently the editor contents and  
>> the file contents are out of sync unless a successful update was  done 
>> after the last edit.

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] widget fixes win32

[Ralph T. <ra...@gm...>]

Hi Thomas,

  The first change (to get_window_title) looks good. I assume that
your issue with (2) is that the Begin window grows but the edit text
widgets remain the same size. It seems like it should grow... I'll
test your change and verify that the baseline is correct.

  Sean, what is the correct behavior for the edit text widget here?

Thanks,
 Ralph

On 12/29/05, Thomas Witt <wi...@ac...> wrote:
>
> Hi,
>
> The attached patch fixes 2 issues with the widget implementation on
> win32 that show up in begin.
>
> a) The text in an edit_text widget is truncated to 1023 char on
> extraction. As a result loading any example in begin that is longer than
> that (some are) and making a small modification will see the update fail
> with a syntax error.
>
> b) The edit_text widget does not grow vertically. This makes
> editing/viewing larger examples in Begin a pain. It works for begin but
> this fix might need more review.
>
> Thomas
>
> --
> Thomas Witt
> wi...@ac...
>
>
> Index: ui_core_implementation.cpp
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/adobe-source/adobe-source/adobe/future/widgets/sources=
/win/ui_core_implementation.cpp,v
> retrieving revision 1.5
> diff -u -3 -p -u -r1.5 ui_core_implementation.cpp
> --- ui_core_implementation.cpp  2 Dec 2005 02:52:56 -0000       1.5
> +++ ui_core_implementation.cpp  30 Dec 2005 00:02:05 -0000
> @@ -245,11 +245,13 @@ std::string get_window_title(HWND window
>  {
>         assert(window);
>
> -       std::vector<WCHAR> titlename;
> +  int const buffer_size =3D ::GetWindowTextLengthW(window) + 1;
>
> -       titlename.resize(1024);
> +  std::vector<WCHAR> titlename(buffer_size, 0);
>
> -       *(&titlename[::GetWindowTextW(window, &titlename[0], 1024)]) =3D =
0;
> +  int const text_length =3D ::GetWindowTextW(window, &titlename[0], buff=
er_size);
> +
> +  assert(text_length < buffer_size);
>
>         return std::string(hackery::convert_utf(&titlename[0]));
>  }
> @@ -3143,7 +3145,10 @@ void edit_text_t::implementation_t::set_
>         // alignment.
>         //
>         position.y_m +=3D baseline - edit_baseline_m;
> -       geometry.height() =3D edit_height_m;
> +
> +  // Do we need to adapt the height for baseline alignment? (thw)
> +  // Disabled as it disables vertical align_fill (thw)
> +  // geometry.height() =3D edit_height_m;
>         _super::set_bounds(position, geometry);
>  }
>
>
>
>

Re: [Adobe-source-devel] Begin line ending handling

[Thomas W. <wi...@ac...>]

Sean,

Sean Parent wrote:
> New hypothesis,
> 
> After looking at the code there is the following line in  
> express_viewer.hpp
> ---
>         adobe::replace( filtered, '\r', '\n' );
> ---
> 
> My guess is that this is there to handle \r to \n conversion on the  Mac 
> - but this is also getting applied on Windows.
> 
> The result is that the file which was \r\n windows line endings now  has 
> \n\n line endings which are then getting converted by the windows  
> stream code to \r\n\r\n which is what I'm seeing in the final file -

Yup, I think that's what happens. In my local copy I use text mode for 
reading and I've removed that line. Works as long as you don't have 
files from other plattforms.

Thomas


-- 
Thomas Witt
wi...@ac...

[Adobe-source-devel] widget fixes win32

[Thomas W. <wi...@ac...>]

Hi,

The attached patch fixes 2 issues with the widget implementation on 
win32 that show up in begin.

a) The text in an edit_text widget is truncated to 1023 char on 
extraction. As a result loading any example in begin that is longer than 
that (some are) and making a small modification will see the update fail 
with a syntax error.

b) The edit_text widget does not grow vertically. This makes 
editing/viewing larger examples in Begin a pain. It works for begin but 
this fix might need more review.

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Begin line ending handling

[Sean P. <sp...@ad...>]

New hypothesis,

After looking at the code there is the following line in =20
express_viewer.hpp
---
		adobe::replace( filtered, '\r', '\n' );
---

My guess is that this is there to handle \r to \n conversion on the =20
Mac - but this is also getting applied on Windows.

The result is that the file which was \r\n windows line endings now =20
has \n\n line endings which are then getting converted by the windows =20=

stream code to \r\n\r\n which is what I'm seeing in the final file -

Since I'm not clear on what the requirements are for the intermediate =20=

formats I'm not going to attempt a quick fix. I'll let Foster noodle =20
it around when he's back from vacation :-)

Sean


On Dec 29, 2005, at 1:26 PM, Thomas Witt wrote:

>
> Sean,
>
> Sean Parent wrote:
>> On Dec 29, 2005, at 9:14 AM, Thomas Witt wrote:
>>> Sean,
>>>
>>> On Dec 28, 2005, at 10:44 PM, Sean Parent wrote:
>>>
>
>> The Begin  app has to convert to platform line endings at some =20
>> point because the  OS controls deal with it that way.
>
> I think you are wrong here. I am pretty sure Windows deals in '\n' =20
> only. Here is an excerpt from the MSDN docs regarding fopen.
>
> ...
>
> t
>
> Open in text (translated) mode. In this mode, CTRL+Z is interpreted =20=

> as an end-of-file character on input. In files opened for reading/=20
> writing with "a+", fopen checks for a CTRL+Z at the end of the file =20=

> and removes it, if possible. This is done because using fseek and =20
> ftell to move within a file that ends with a CTRL+Z, may cause =20
> fseek to behave improperly near the end of the file.
>
> Also, in text mode, carriage return=96linefeed combinations are =20
> translated into single linefeeds on input, and linefeed characters =20
> are translated to carriage return=96linefeed combinations on output. =20=

> When a Unicode stream-I/O function operates in text mode (the =20
> default), the source or destination stream is assumed to be a =20
> sequence of multibyte characters. Therefore, the Unicode stream-=20
> input functions convert multibyte characters to wide characters (as =20=

> if by a call to the mbtowc function). For the same reason, the =20
> Unicode stream-output functions convert wide characters to =20
> multibyte characters (as if by a call to the wctomb function).
>
> b
>
> Open in binary (untranslated) mode; translations involving carriage-=20=

> return and linefeed characters are suppressed.
>
> If t or b is not given in mode, the default translation mode is =20
> defined by the global variable _fmode. If t or b is prefixed to the =20=

> argument, the function fails and returns NULL.
>
> For more information about using text and binary modes in Unicode =20
> and multibyte stream-I/O, see Text and Binary Mode File I/O and =20
> Unicode Stream I/O in Text and Binary Modes.
>
> ...
>
> with text mode I/O being the default.
>
> Looking at the libstdc++v3 FAQ in Apples developer documentation =20
> you'll see the same thing. I.e. text mode I/O does convert native =20
> line endings to '\n'
>
> I am aware of the fact that this is no proof that the controls or =20
> any other part of the API will deal in '\n' only but it's at least =20
> a strong indication. Having the default file I/O mode being =20
> incompatible with the rest of the API is hard to imagine even for =20
> seasoned Windows programmer.
>
>>> IIUC this is what every std conforming iostream library does by  =20
>>> default. Well to be precise, it is what it asks the OS to do. =20
>>> I.e.  the OS is responsible for the mapping between in memory  =20
>>> representation and on disk representation of file contents. On  =20
>>> Windows this will mean mapping "\r\n" to "\n". I haven't seen a  =20
>>> plattform where the in memory representation uses anything but a  =20=

>>> single '\n' for line endings. Come to think of this does the C  =20
>>> standard actually specify this?
>> There is no such requirement for C to map line endings (or C++) =20
>> in  the standard.
>
> AFAICS the standard (either one) is mostly silent on what text mode =20=

> and binary mode means. I wonder if that should be considered a defect.
>
> My statement seems to correspond to existing practice though.
>
> > We recently reviewed the definition of a line ending in  the
>> standard committee because GCC treats treats the following as a  =20
>> single comment line where [sp] is any sequence of white space  =20
>> characters:
>> // some comment \[sp]
>> a =3D b;
>> The \ character quotes an "end of line" which gcc defines to be =20
>> any  white space followed by \n. I don't recall what the Windows =20
>> iostream  library actually does here - I think they convert the =20
>> other way on  the way in (\n -> \r\n) but I'd have to go look again.
>
> I have to reread the thread but I think this is actually a =20
> different issue. It involves the interpretation of source files by =20
> the compiler and the compiler is free to use any I/O scheme to read =20=

> them.
>
>
>>>
>>> Given this there seem to be two strategies to deal with this.
>>>
>>> a) Require every file to be in the plattforms native encoding =20
>>> and  let the OS do the work. The program logic will always assume =20=

>>> line  endings to be '\n'.
>> This isn't workable because as noted above the "in memory"  =20
>> representation at some point will have to be for the platform (\r=20
>> \n  on Windows) for the OS controls to function properly.
>
> As said above I think you are wrong here.
>
>> The on disk  representation can be anything because files get =20
>> moved from platform  to platform.
>
> Agreed if you want to tolerate this a) is not workable.
>
>>>
>>> b) Try to detect the line ending encoding on input and do the  =20
>>> mapping "native-encoding" -> '\n' yourself on input (Experience  =20
>>> shows that this is complicated and a frequent source of bugs). =20
>>> The  rest of the program logic will still assume line endings to =20
>>> be  '\n'. When writing the file you can either write to the =20
>>> original  encoding, that is only if you memorized that, or to the =20=

>>> native  encoding.
>> In general I'd rather simply be agnostic as much as possible and  =20
>> convert only when necessary
>
> Lets say you modify the file contents and then write them to disk =20
> what line endings do you use in your modifications?
>
>> I can see three valid behaviors for the begin application - first =20
>> it  should properly read _any_ line endings then it should:
>
> That is a reasonable requirement. As a user I would not ask for =20
> that, but it is nice to have.
>
>> 1. Always write platform line endings
>> 2. Always write Unix line endings as a canonical form (probably a =20
>> bad  thing because many Windows apps can't read this correctly)
>> 3. Always preserve line endings styles of the file
>> So I'd vote for 1 with the caveat that  we define \n to be the =20
>> "platform line endings" for Mac instead of the  classic Mac OS \r.
>
> Agreed.
>
>> Can you send me a file where the line endings have been "doubled" =20
>> -  I'd like to see what they actually are (please ZIP the file or =20
>> the  email system will attempt to convert line endings...). The =20
>> Adobe e- mail server is picky about letting in zip files so change =20=

>> the  extension to .zap or send it to sea...@ma....
>
> Will do.
>
> Thomas
>
> --=20
> Thomas Witt
> wi...@ac...

Re: [Adobe-source-devel] Begin line ending handling

[Thomas W. <wi...@ac...>]

Sean,

Sean Parent wrote:
>=20
> On Dec 29, 2005, at 9:14 AM, Thomas Witt wrote:
>=20
>> Sean,
>>
>> On Dec 28, 2005, at 10:44 PM, Sean Parent wrote:
>>

> The Begin =20
> app has to convert to platform line endings at some point because the =20
> OS controls deal with it that way.

I think you are wrong here. I am pretty sure Windows deals in '\n' only.=20
Here is an excerpt from the MSDN docs regarding fopen.

...

t

Open in text (translated) mode. In this mode, CTRL+Z is interpreted as=20
an end-of-file character on input. In files opened for reading/writing=20
with "a+", fopen checks for a CTRL+Z at the end of the file and removes=20
it, if possible. This is done because using fseek and ftell to move=20
within a file that ends with a CTRL+Z, may cause fseek to behave=20
improperly near the end of the file.

Also, in text mode, carriage return=96linefeed combinations are translate=
d=20
into single linefeeds on input, and linefeed characters are translated=20
to carriage return=96linefeed combinations on output. When a Unicode=20
stream-I/O function operates in text mode (the default), the source or=20
destination stream is assumed to be a sequence of multibyte characters.=20
Therefore, the Unicode stream-input functions convert multibyte=20
characters to wide characters (as if by a call to the mbtowc function).=20
For the same reason, the Unicode stream-output functions convert wide=20
characters to multibyte characters (as if by a call to the wctomb=20
function).

b

Open in binary (untranslated) mode; translations involving=20
carriage-return and linefeed characters are suppressed.

If t or b is not given in mode, the default translation mode is defined=20
by the global variable _fmode. If t or b is prefixed to the argument,=20
the function fails and returns NULL.

For more information about using text and binary modes in Unicode and=20
multibyte stream-I/O, see Text and Binary Mode File I/O and Unicode=20
Stream I/O in Text and Binary Modes.

...

with text mode I/O being the default.

Looking at the libstdc++v3 FAQ in Apples developer documentation you'll=20
see the same thing. I.e. text mode I/O does convert native line endings=20
to '\n'

I am aware of the fact that this is no proof that the controls or any=20
other part of the API will deal in '\n' only but it's at least a strong=20
indication. Having the default file I/O mode being incompatible with the=20
rest of the API is hard to imagine even for seasoned Windows programmer.

>> IIUC this is what every std conforming iostream library does by =20
>> default. Well to be precise, it is what it asks the OS to do. I.e. =20
>> the OS is responsible for the mapping between in memory =20
>> representation and on disk representation of file contents. On =20
>> Windows this will mean mapping "\r\n" to "\n". I haven't seen a =20
>> plattform where the in memory representation uses anything but a =20
>> single '\n' for line endings. Come to think of this does the C =20
>> standard actually specify this?
>=20
>=20
> There is no such requirement for C to map line endings (or C++) in  the=
=20
> standard.

AFAICS the standard (either one) is mostly silent on what text mode and=20
binary mode means. I wonder if that should be considered a defect.

My statement seems to correspond to existing practice though.

 > We recently reviewed the definition of a line ending in  the
> standard committee because GCC treats treats the following as a  single=
=20
> comment line where [sp] is any sequence of white space  characters:
>=20
> // some comment \[sp]
> a =3D b;
>=20
> The \ character quotes an "end of line" which gcc defines to be any =20
> white space followed by \n. I don't recall what the Windows iostream =20
> library actually does here - I think they convert the other way on  the=
=20
> way in (\n -> \r\n) but I'd have to go look again.

I have to reread the thread but I think this is actually a different=20
issue. It involves the interpretation of source files by the compiler=20
and the compiler is free to use any I/O scheme to read them.


>=20
>>
>> Given this there seem to be two strategies to deal with this.
>>
>> a) Require every file to be in the plattforms native encoding and  let=
=20
>> the OS do the work. The program logic will always assume line  endings=
=20
>> to be '\n'.
>=20
>=20
> This isn't workable because as noted above the "in memory" =20
> representation at some point will have to be for the platform (\r\n  on=
=20
> Windows) for the OS controls to function properly.

As said above I think you are wrong here.

> The on disk =20
> representation can be anything because files get moved from platform  t=
o=20
> platform.

Agreed if you want to tolerate this a) is not workable.

>=20
>>
>> b) Try to detect the line ending encoding on input and do the  mapping=
=20
>> "native-encoding" -> '\n' yourself on input (Experience  shows that=20
>> this is complicated and a frequent source of bugs). The  rest of the=20
>> program logic will still assume line endings to be  '\n'. When writing=
=20
>> the file you can either write to the original  encoding, that is only=20
>> if you memorized that, or to the native  encoding.
>=20
>=20
> In general I'd rather simply be agnostic as much as possible and =20
> convert only when necessary=20

Lets say you modify the file contents and then write them to disk what=20
line endings do you use in your modifications?

> I can see three valid behaviors for the begin application - first it =20
> should properly read _any_ line endings then it should:

That is a reasonable requirement. As a user I would not ask for that,=20
but it is nice to have.

>=20
> 1. Always write platform line endings
> 2. Always write Unix line endings as a canonical form (probably a bad =20
> thing because many Windows apps can't read this correctly)
> 3. Always preserve line endings styles of the file
>=20
> So I'd vote for 1 with the caveat that  we=20
> define \n to be the "platform line endings" for Mac instead of the =20
> classic Mac OS \r.

Agreed.

>=20
> Can you send me a file where the line endings have been "doubled" -  I'=
d=20
> like to see what they actually are (please ZIP the file or the  email=20
> system will attempt to convert line endings...). The Adobe e- mail=20
> server is picky about letting in zip files so change the  extension to=20
> .zap or send it to sea...@ma....

Will do.

Thomas

--=20
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Begin line ending handling

[Sean P. <sp...@ad...>]

On Dec 29, 2005, at 9:14 AM, Thomas Witt wrote:

> Sean,
>
> On Dec 28, 2005, at 10:44 PM, Sean Parent wrote:
>
>> The parsers are all line ending agnostic. For the Begin app - I'd =20
>> assume (I haven't looked at that part of the code) it converts =20
>> into platform line endings on the way in - and probably leaves =20
>> them that way.
>
> Hmm=85 to me this seems like a complicated and brittle way to deal =20
> with this. Let me explain=85

The parsers being line ending agnostic (I happen to think all code =20
dealing with text files should be) - is the correct thing. The Begin =20
app has to convert to platform line endings at some point because the =20=

OS controls deal with it that way.
>
>> On Windows this would convert /n to /r/n - which may be what you =20
>> are seeing?
>
>> I _really_ dislike any iostream libraries which try to auto-=20
>> convert line endings
>
> IIUC this is what every std conforming iostream library does by =20
> default. Well to be precise, it is what it asks the OS to do. I.e. =20
> the OS is responsible for the mapping between in memory =20
> representation and on disk representation of file contents. On =20
> Windows this will mean mapping "\r\n" to "\n". I haven't seen a =20
> plattform where the in memory representation uses anything but a =20
> single '\n' for line endings. Come to think of this does the C =20
> standard actually specify this?

There is no such requirement for C to map line endings (or C++) in =20
the standard. We recently reviewed the definition of a line ending in =20=

the standard committee because GCC treats treats the following as a =20
single comment line where [sp] is any sequence of white space =20
characters:

// some comment \[sp]
a =3D b;

The \ character quotes an "end of line" which gcc defines to be any =20
white space followed by \n. I don't recall what the Windows iostream =20
library actually does here - I think they convert the other way on =20
the way in (\n -> \r\n) but I'd have to go look again.

>
> Given this there seem to be two strategies to deal with this.
>
> a) Require every file to be in the plattforms native encoding and =20
> let the OS do the work. The program logic will always assume line =20
> endings to be '\n'.

This isn't workable because as noted above the "in memory" =20
representation at some point will have to be for the platform (\r\n =20
on Windows) for the OS controls to function properly. The on disk =20
representation can be anything because files get moved from platform =20
to platform.

>
> b) Try to detect the line ending encoding on input and do the =20
> mapping "native-encoding" -> '\n' yourself on input (Experience =20
> shows that this is complicated and a frequent source of bugs). The =20
> rest of the program logic will still assume line endings to be =20
> '\n'. When writing the file you can either write to the original =20
> encoding, that is only if you memorized that, or to the native =20
> encoding.

In general I'd rather simply be agnostic as much as possible and =20
convert only when necessary - if our current logic to convert on =20
reading for Windows is correct (it may not be, I have not review it) =20
and what you are seeing is simply \n getting converted to \r\n then I =20=

don't have any issues - if you are actually seeing extra blank lines =20
in the Begin app then we have something wrong.

I can see three valid behaviors for the begin application - first it =20
should properly read _any_ line endings then it should:

1. Always write platform line endings
2. Always write Unix line endings as a canonical form (probably a bad =20=

thing because many Windows apps can't read this correctly)
3. Always preserve line endings styles of the file

On the Mac I tend to prefer answer 2 or 3 because the tool set is =20
agnostic - but if you consider the Unix side now to be the "native" =20
representation on the Mac then 2 and 1 become the same. On Windows I =20
prefer 1 because this allows you to use other tools on the platform =20
with files saved from begin. So I'd vote for 1 with the caveat that =20
we define \n to be the "platform line endings" for Mac instead of the =20=

classic Mac OS \r.

Sean


>
> In my experience b) is rarely worth the added complexity, but this =20
> pretty much depends on your use case. I've used frequently used a) =20
> in cross plattform projects without problems even with users =20
> working on two plattforms simultaneously. To get back to my first =20
> sentence. To me the key part of both solutions is to only use the =20
> "native" C++ encoding '\n' internally as it simplifies the code and =20=

> ensures interoperability with third party code like widget libraries.
>
> What do you think?
>
>> - Often these will just do things like convert /r to /n... which =20
>> would double your line endings. We'll look into it.
>>
>> I did fix some code related to line endings awhile ago - are you =20
>> running the 1.0.11 release?
>
> Unless I am missing something it's CVS Head.

Can you send me a file where the line endings have been "doubled" - =20
I'd like to see what they actually are (please ZIP the file or the =20
email system will attempt to convert line endings...). The Adobe e-=20
mail server is picky about letting in zip files so change the =20
extension to .zap or send it to sea...@ma....

Sean


>
> Regards
>
> Thomas
>
> Thomas Witt
> wi...@ac...
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through =20
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD =20
> SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] Begin line ending handling

[Thomas W. <wi...@ac...>]

Sean,

On Dec 28, 2005, at 10:44 PM, Sean Parent wrote:

> The parsers are all line ending agnostic. For the Begin app - I'd =20
> assume (I haven't looked at that part of the code) it converts into =20=

> platform line endings on the way in - and probably leaves them that =20=

> way.

Hmm=85 to me this seems like a complicated and brittle way to deal with =20=

this. Let me explain=85

> On Windows this would convert /n to /r/n - which may be what you =20
> are seeing?

> I _really_ dislike any iostream libraries which try to auto-convert =20=

> line endings

IIUC this is what every std conforming iostream library does by =20
default. Well to be precise, it is what it asks the OS to do. I.e. =20
the OS is responsible for the mapping between in memory =20
representation and on disk representation of file contents. On =20
Windows this will mean mapping "\r\n" to "\n". I haven't seen a =20
plattform where the in memory representation uses anything but a =20
single '\n' for line endings. Come to think of this does the C =20
standard actually specify this?

Given this there seem to be two strategies to deal with this.

a) Require every file to be in the plattforms native encoding and let =20=

the OS do the work. The program logic will always assume line endings =20=

to be '\n'.

b) Try to detect the line ending encoding on input and do the mapping =20=

"native-encoding" -> '\n' yourself on input (Experience shows that =20
this is complicated and a frequent source of bugs). The rest of the =20
program logic will still assume line endings to be '\n'. When writing =20=

the file you can either write to the original encoding, that is only =20
if you memorized that, or to the native encoding.

In my experience b) is rarely worth the added complexity, but this =20
pretty much depends on your use case. I've used frequently used a) in =20=

cross plattform projects without problems even with users working on =20
two plattforms simultaneously. To get back to my first sentence. To =20
me the key part of both solutions is to only use the "native" C++ =20
encoding '\n' internally as it simplifies the code and ensures =20
interoperability with third party code like widget libraries.

What do you think?

> - Often these will just do things like convert /r to /n... which =20
> would double your line endings. We'll look into it.
>
> I did fix some code related to line endings awhile ago - are you =20
> running the 1.0.11 release?

Unless I am missing something it's CVS Head.

Regards

Thomas

Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] Begin line ending handling

[Sean P. <sea...@ma...>]

The parsers are all line ending agnostic. For the Begin app - I'd  
assume (I haven't looked at that part of the code) it converts into  
platform line endings on the way in - and probably leaves them that  
way. On Windows this would convert /n to /r/n - which may be what you  
are seeing? I _really_ dislike any iostream libraries which try to  
auto-convert line endings - Often these will just do things like  
convert /r to /n... which would double your line endings. We'll look  
into it.

I did fix some code related to line endings awhile ago - are you  
running the 1.0.11 release?

Sean

On Dec 28, 2005, at 7:03 PM, Thomas Witt wrote:

>
> Hi,
>
> what's the rationale for Begin to deal with the different plattform  
> specific line endings? In my understanding iostreams handle this  
> transparently by default. Whatever the rationale is the current  
> windows logic seems broken as it doubles the newlines on save.
>
> Regards
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Begin line ending handling

[Thomas W. <wi...@ac...>]

Hi,

what's the rationale for Begin to deal with the different plattform 
specific line endings? In my understanding iostreams handle this 
transparently by default. Whatever the rationale is the current windows 
logic seems broken as it doubles the newlines on save.

Regards

Thomas

-- 
Thomas Witt
wi...@ac...

[Adobe-source-devel] Begin woes

[Thomas W. <wi...@ac...>]

Hi,

Just a comment, the current semantics for the save button are misleading 
(well at least to me). Currently the editor contents and the file 
contents are out of sync unless a successful update was done after the 
last edit.

This and the fact that begin crashes occasionaly will make you loose 
some work eventually when experimenting in begin. In my case it took me 
almost 1h in total to figure out what was going on.

Regards

Thomas

-- 
Thomas Witt
wi...@ac...

Re: [Adobe-source-devel] dictionary_t tutorial

[Sean P. <sp...@ad...>]

It isn't _that_ suboptimal. The time to construct a name_t is O(log 
(N)) where N is the number of names in the current process. The  
comparisons are also optimized to be reasonably fast so this should  
perform just fine for most usage.

Sean



On Dec 13, 2005, at 8:47 PM, Thomas Witt wrote:

>
> Hi,
>
> The first code snippet in the dictionary example contains the  
> following function:
>
> void foo(adobe::dictionary_t param) // makes a copy of the  
> dictionary_t
> {
>     std::cout << param[adobe::name_t("my_key")].get<std::string>();
> }
>
> If I understand the characteristics of name_t correctly the usage  
> of a tempory name_t here is, well suboptimal. The construction is O 
> (n) where n is the number of distinct name_t values in the process.  
> I am aware that name_t usage is not the point here, but this  
> particular usage looks so natural that it might be worthwile to  
> avoid misleading the programmer even in unrelated examples.
>
> Just my 2ct
>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] dictionary_t tutorial

[Thomas W. <wi...@ac...>]

Hi,

The first code snippet in the dictionary example contains the following 
function:

void foo(adobe::dictionary_t param) // makes a copy of the dictionary_t
{
     std::cout << param[adobe::name_t("my_key")].get<std::string>();
}

If I understand the characteristics of name_t correctly the usage of a 
tempory name_t here is, well suboptimal. The construction is O(n) where 
n is the number of distinct name_t values in the process. I am aware 
that name_t usage is not the point here, but this particular usage looks 
so natural that it might be worthwile to avoid misleading the programmer 
even in unrelated examples.

Just my 2ct

Thomas

-- 
Thomas Witt
wi...@ac...

[Adobe-source-devel] Re: asl-users: reverse fullorder for forest -

[Sean P. <sp...@ad...>]

On Dec 13, 2005, at 10:10 AM, Foster T. Brereton wrote:

> Just a couple comments at this point...
>
> On Dec 12, 2005, at 04:57p, Sean Parent wrote:
>
>> One option is to nuke the reverse fullorder iterator (Eric?) - you  
>> could still use a general reverse iterator adaptor, but you would  
>> lose the ability to toggle edges which in reverse is a  
>> questionable thing to do (it base iterator does a very odd flip  
>> around the pointed to node).
>
> What's the difference between a cursor and an iterator?

Well - generally a cursor is a more general form of an iterator - I  
go back and forth with Forest between wanting to call it a fullorder  
iterator and fullorder cursor - it meets the requirements of an  
iterator, but I find it odd to have an iterator which visits every  
node twice.... I might just stick with iterator though and pull the  
cursor terminology.

>
>> Another thing I somewhat dislike is the use of a bool (maybe it  
>> should be called edge and return an enum?) -
>>
>> if (i.edge() == adobe::forest_leading_s)...
>>
>> I like the idea but dealing with enum types is just plain  
>> cumbersome...
>
> adobe/future/enum_ops.hpp may help out with enumeration  
> manipulation. I like the idea of being more explicit about the edge  
> the iterator is on. It makes the code easier to read, and can lend  
> itself to better generalization IMO (see below).
>
>> Another option that I'm somewhat fond of is to simply use  
>> leading_of and trailing_of as stand alone functions - then maybe  
>> have an is_leading and is_trailing for completeness-
>>
>> <snip>
>>
>> is_edge<adobe::forest_leading_s>(i);
>> i = edge<adobe::forest_trailing_s>(i);
>
> This to me would be a natural extension of using the enumerations  
> above -- I like it. Wouldn't it also allow for the consolidation of  
> preorder_iterator and postorder_iterator into some  
> order_iterator<Enum>(), where the while statement is simply while (! 
> this->base().edge() == Enum) ? There could be more consolidation  
> than even this, but it was the first one that I saw.

A good observation - thanks,
Sean

>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "The fact is that the author of STL does not know how to write min,  
> the author of C++ is not quite sure, and the standards committee is  
> at a loss." -- Alexander Stepanov
>
>

[Adobe-source-devel] Re: asl-users: reverse fullorder for forest -

[Foster T. B. <fbr...@ad...>]

Just a couple comments at this point...

On Dec 12, 2005, at 04:57p, Sean Parent wrote:

> One option is to nuke the reverse fullorder iterator (Eric?) - you  
> could still use a general reverse iterator adaptor, but you would  
> lose the ability to toggle edges which in reverse is a questionable  
> thing to do (it base iterator does a very odd flip around the  
> pointed to node).

What's the difference between a cursor and an iterator?

> Another thing I somewhat dislike is the use of a bool (maybe it  
> should be called edge and return an enum?) -
>
> if (i.edge() == adobe::forest_leading_s)...
>
> I like the idea but dealing with enum types is just plain  
> cumbersome...

adobe/future/enum_ops.hpp may help out with enumeration manipulation.  
I like the idea of being more explicit about the edge the iterator is  
on. It makes the code easier to read, and can lend itself to better  
generalization IMO (see below).

> Another option that I'm somewhat fond of is to simply use  
> leading_of and trailing_of as stand alone functions - then maybe  
> have an is_leading and is_trailing for completeness-
>
> <snip>
>
> is_edge<adobe::forest_leading_s>(i);
> i = edge<adobe::forest_trailing_s>(i);

This to me would be a natural extension of using the enumerations  
above -- I like it. Wouldn't it also allow for the consolidation of  
preorder_iterator and postorder_iterator into some  
order_iterator<Enum>(), where the while statement is simply while (! 
this->base().edge() == Enum) ? There could be more consolidation than  
even this, but it was the first one that I saw.

Blessings,
Foster


--
Foster T. Brereton              <}}}><              Romans 3:21-26
A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
"The fact is that the author of STL does not know how to write min,  
the author of C++ is not quite sure, and the standards committee is  
at a loss." -- Alexander Stepanov

[Adobe-source-devel] reverse fullorder for forest -

[Sean P. <sp...@ad...>]

A little more on the great forest cleanup... since nobody responded  
to my last note, depth is now moved to an adapter.

Next item, I don't like the interface around edges:

bool leading() const;
void set_leading(bool);
bool pivot();

My first thought was that there are really any invariants being  
protected here - and just expose leading as a data member:

bool leading;

That, however, doesn't work well with the adaptors -

Second thought:

bool leading() const;
bool& leading();

This fails with the reverse iterator though were toggling leading  
_is_ more complicated than toggling a bool (which gets us back to a  
set_leading() interface).

One option is to nuke the reverse fullorder iterator (Eric?) - you  
could still use a general reverse iterator adaptor, but you would  
lose the ability to toggle edges which in reverse is a questionable  
thing to do (it base iterator does a very odd flip around the pointed  
to node).

Another thing I somewhat dislike is the use of a bool (maybe it  
should be called edge and return an enum?) -

if (i.edge() == adobe::forest_leading_s)...

I like the idea but dealing with enum types is just plain cumbersome...

Another option that I'm somewhat fond of is to simply use leading_of  
and trailing_of as stand alone functions - then maybe have an  
is_leading and is_trailing for completeness-

bool is_leading(iterator);
bool is_trailing(iterator);
iterator leading_of(iterator);
iterator trailing_of(iterator);

if (adobe::is_leading(i)) i = adobe::trialing_of(i);

I can't find a case where it's very desirable to actually pivot -  
usually you want to just force to one side or another...

This could also be combined with the previous - something like:

is_edge<adobe::forest_leading_s>(i);
i = edge<adobe::forest_trailing_s>(i);

Anyone have suggestions?

Sean

Re: [Adobe-source-devel] any_iterator equal

[Sean P. <sp...@ad...>]

On Dec 12, 2005, at 2:42 PM, Thomas Witt wrote:

>
> Hi,
>
> any_iterator equal is currently implemented as follows
>
> iterator.hpp:242
>
> bool equal(const any_iterator& x) const
> {
>   return (type() == x.type()) && object_m->equal(*x.object_m);
> }
>
> IIUC the type equality check is unneeded and may hide bugs.
>
> Type equality is given implicitly by the requirement that both  
> iterators point into the same sequence. As a sidenote AFAICS  
> any_iterators do not support interoperable iterators, eg.  
> vector<int>::iterator/vector<int>::const_iterator but the equal  
> implementations would yield false for these even if they point to  
> the same position in a sequence.
>
> What did I miss

Hi Thomas -
I don't think you missed anything. This is a good point about the type 
() equality being implicitly required - I will replace the check with  
an assert. "interoperable" iterators (iterators with different  
underlying types pointing to the same structure) was not a design goal.

Sean

>
> Thomas
>
> -- 
> Thomas Witt
> wi...@ac...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] any_iterator equal

[Thomas W. <wi...@ac...>]

Hi,

any_iterator equal is currently implemented as follows

iterator.hpp:242

bool equal(const any_iterator& x) const
{
   return (type() == x.type()) && object_m->equal(*x.object_m);
}

IIUC the type equality check is unneeded and may hide bugs.

Type equality is given implicitly by the requirement that both iterators 
point into the same sequence. As a sidenote AFAICS any_iterators do not 
support interoperable iterators, eg. 
vector<int>::iterator/vector<int>::const_iterator but the equal 
implementations would yield false for these even if they point to the 
same position in a sequence.

What did I miss

Thomas

-- 
Thomas Witt
wi...@ac...