adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] Re: MSVC warning fix checked into sandbox

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

The warnings are that ADL was used to resolve the function - however, 
the reason why we have adobe::swap() is that this is the one function 
(other than the operators) where ADL is desirable. The correct fix here 
would simply be to use a pragma to silence the warning inside 
do_swap(). We don't want to change to call with std::swap because then 
if we add on overload of swap for line_position_t (there may already be 
one... I'm not looking at the source right now) then we will miss it.

Sean

On Mar 23, 2005, at 2:19 AM, Ralph Thomas wrote:

> Okay, now I understand why it was the way it was (and have backed out
> my change). My apologies for not better examining the change.
>
> I now think (although I should probably postpone further thinking 'til
> the morning..) that a better change would be in istream.hpp. Please
> let me know if this is acceptable or not:
>
> Index: adobe-source/adobe/istream.hpp
> ===================================================================
> RCS file: 
> /cvsroot/adobe-source/sandbox/adobe-source/adobe/istream.hpp,v
> retrieving revision 1.1
> diff -u -r1.1 istream.hpp
> --- adobe-source/adobe/istream.hpp	19 Mar 2005 00:16:38 -0000	1.1
> +++ adobe-source/adobe/istream.hpp	23 Mar 2005 10:15:49 -0000
> @@ -67,7 +67,7 @@
>   	stream_error_t(stream_error_t& base, const line_position_t& 
> position) :
>   		std::logic_error(base.what())
>   	{
> -		adobe::swap(line_position_set_m, base.line_position_set_m);
> +		std::swap(line_position_set_m, base.line_position_set_m);
>   		line_position_set_m.push_back(position);
>   	}
>
>
> This is the warning I get:
>
>
> Compiler is Microsoft Visual C++
> ...patience...
> ...found 1176 targets...
> ...updating 21 targets...
> C++ external\adobe\source\adam.obj
> adam.cpp
> external\adobe\algorithm.hpp(45) : warning C4675: 'void 
> std::swap<adobe::line_po
> sition_t,std::allocator<_Ty>>(std::vector<_Ty> &,std::vector<_Ty> &)' 
> : resolved
>  overload was found by argument-dependent lookup
>         with
>         [
>             _Ty=adobe::line_position_t
>         ]
>         F:\Program Files\Microsoft Visual Studio .NET 
> 2003\Vc7\include\vector(94
> 4) : see declaration of 'std::swap'
>         external\adobe\algorithm.hpp(129) : see reference to function 
> template i
> nstantiation 'void adobe::implementation::do_swap<T>(T &,T &)' being 
> compiled
>         with
>         [
>             T=adobe::stream_error_t::position_set_t
>         ]
>         external\adobe\istream.hpp(70) : see reference to function 
> template inst
> antiation 'void 
> adobe::fn::swap<adobe::stream_error_t::position_set_t>(T &,T &)'
>  being compiled
>         with
>         [
>             T=adobe::stream_error_t::position_set_t
>         ]
> ...interrupted
> Terminate batch job (Y/N)? y
>
>
> On Wed, 23 Mar 2005 00:49:39 -0800, Ralph Thomas <ra...@gm...> 
> wrote:
>> I just checked a small change into algorithm.hpp in the sandbox fixing
>> a warning which appeared for most files in ASL.
>>
>> Was there any reason why swap was ambiguous before (i.e.: does this
>> break builds on other compilers)?
>>
>> Thanks,
>>  Ralph
>>
>> Index: adobe-source/adobe/algorithm.hpp
>> ===================================================================
>> RCS file: 
>> /cvsroot/adobe-source/sandbox/adobe-source/adobe/algorithm.hpp,v
>> retrieving revision 1.1
>> diff -u -r1.1 algorithm.hpp
>> --- adobe-source/adobe/algorithm.hpp    19 Mar 2005 00:16:38 -0000    
>>   1.1
>> +++ adobe-source/adobe/algorithm.hpp    23 Mar 2005 08:43:02 -0000
>> @@ -41,8 +41,7 @@
>>  template <typename T>
>>  inline void do_swap(T& a, T& b)
>>  {
>> -       using namespace std;
>> -       swap(a, b);
>> +       std::swap(a, b);
>>  }
>>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: 2005 Windows Mobile Application 
> Contest
> Submit applications for Windows Mobile(tm)-based Pocket PCs or 
> Smartphones
> for the chance to win $25,000 and application distribution. Enter 
> today at
> http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] More XCode issues

[Niki S. <nik...@gm...>]

On Tue, 22 Mar 2005 20:27:58 -0800, David Catmull
<unc...@un...> wrote:
> There are several places where #ifdef __MWERKS__ is used for
> Mac-specific stuff, which of course fails in XCode. I would suggest #if
> TARGET_OS_MAC instead (defined in /usr/include/TargetConditionals.h).
> This makes me wonder, is BOOST_MSVC a reliable value for Windows? The
> name suggests not.

Of course not.
I already submitted a patch for one such check.

Niki Spahiev

[Adobe-source-devel] Re: MSVC warning fix checked into sandbox

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

Okay, now I understand why it was the way it was (and have backed out
my change). My apologies for not better examining the change.

I now think (although I should probably postpone further thinking 'til
the morning..) that a better change would be in istream.hpp. Please
let me know if this is acceptable or not:

Index: adobe-source/adobe/istream.hpp
===================================================================
RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/istream.hpp,v
retrieving revision 1.1
diff -u -r1.1 istream.hpp
--- adobe-source/adobe/istream.hpp	19 Mar 2005 00:16:38 -0000	1.1
+++ adobe-source/adobe/istream.hpp	23 Mar 2005 10:15:49 -0000
@@ -67,7 +67,7 @@
  	stream_error_t(stream_error_t& base, const line_position_t& position) :
  		std::logic_error(base.what())
  	{
-		adobe::swap(line_position_set_m, base.line_position_set_m);
+		std::swap(line_position_set_m, base.line_position_set_m);
  		line_position_set_m.push_back(position);
  	}


This is the warning I get:


Compiler is Microsoft Visual C++
...patience...
...found 1176 targets...
...updating 21 targets...
C++ external\adobe\source\adam.obj
adam.cpp
external\adobe\algorithm.hpp(45) : warning C4675: 'void std::swap<adobe::line_po
sition_t,std::allocator<_Ty>>(std::vector<_Ty> &,std::vector<_Ty> &)' : resolved
 overload was found by argument-dependent lookup
        with
        [
            _Ty=adobe::line_position_t
        ]
        F:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\vector(94
4) : see declaration of 'std::swap'
        external\adobe\algorithm.hpp(129) : see reference to function template i
nstantiation 'void adobe::implementation::do_swap<T>(T &,T &)' being compiled
        with
        [
            T=adobe::stream_error_t::position_set_t
        ]
        external\adobe\istream.hpp(70) : see reference to function template inst
antiation 'void adobe::fn::swap<adobe::stream_error_t::position_set_t>(T &,T &)'
 being compiled
        with
        [
            T=adobe::stream_error_t::position_set_t
        ]
...interrupted
Terminate batch job (Y/N)? y


On Wed, 23 Mar 2005 00:49:39 -0800, Ralph Thomas <ra...@gm...> wrote:
> I just checked a small change into algorithm.hpp in the sandbox fixing
> a warning which appeared for most files in ASL.
> 
> Was there any reason why swap was ambiguous before (i.e.: does this
> break builds on other compilers)?
> 
> Thanks,
>  Ralph
> 
> Index: adobe-source/adobe/algorithm.hpp
> ===================================================================
> RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/algorithm.hpp,v
> retrieving revision 1.1
> diff -u -r1.1 algorithm.hpp
> --- adobe-source/adobe/algorithm.hpp    19 Mar 2005 00:16:38 -0000      1.1
> +++ adobe-source/adobe/algorithm.hpp    23 Mar 2005 08:43:02 -0000
> @@ -41,8 +41,7 @@
>  template <typename T>
>  inline void do_swap(T& a, T& b)
>  {
> -       using namespace std;
> -       swap(a, b);
> +       std::swap(a, b);
>  }
>

[Adobe-source-devel] MSVC warning fix checked into sandbox

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

I just checked a small change into algorithm.hpp in the sandbox fixing
a warning which appeared for most files in ASL.

Was there any reason why swap was ambigous before (i.e.: does this
break builds on other compilers)?

Thanks,
 Ralph

Index: adobe-source/adobe/algorithm.hpp
===================================================================
RCS file: /cvsroot/adobe-source/sandbox/adobe-source/adobe/algorithm.hpp,v
retrieving revision 1.1
diff -u -r1.1 algorithm.hpp
--- adobe-source/adobe/algorithm.hpp	19 Mar 2005 00:16:38 -0000	1.1
+++ adobe-source/adobe/algorithm.hpp	23 Mar 2005 08:43:02 -0000
@@ -41,8 +41,7 @@
 template <typename T>
 inline void do_swap(T& a, T& b)
 {
-	using namespace std;
-	swap(a, b);
+	std::swap(a, b);
 }

[Adobe-source-devel] More XCode issues

[David C. <unc...@un...>]

There are several places where #ifdef __MWERKS__ is used for 
Mac-specific stuff, which of course fails in XCode. I would suggest #if 
TARGET_OS_MAC instead (defined in /usr/include/TargetConditionals.h). 
This makes me wonder, is BOOST_MSVC a reliable value for Windows? The 
name suggests not.

There are also places, such as in ui_core_implementation.hpp, where the 
## symbol follows a <, ( or ::, and the compiler complains that the 
pasting doesn't result in a legal token - like "<CFStringRef". Adding a 
space fixes it, but I don't see that the ## is necessary anyway in 
these cases.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

[Adobe-source-devel] XCode compile errors

[David C. <unc...@un...>]

I'm working on my XCode "Adobe Begin" project. After setting up the 
header paths so it properly finds boost and so forth, I get these 
errors:

headers/report_exception.hpp:43: error: looser throw specifier for 
`virtual adobe::implementation::os_exception::~os_exception()'
/usr/include/gcc/darwin/3.3/c++/exception:56: error:   overriding 
`virtual std::exception::~exception() throw ()'
headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does not 
have any field named `trigger_func_m'
headers/latch.hpp:32: error: class `adobe::latch_t<ValueType>' does not 
have any field named `validity_func_m'
adobe/test/visual/sources/client_assembler.cpp:1314: error: parse error 
before `>' token

The throw specifier issue seems to be from the implicit destructor for 
os_exception.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] msvc8/visual

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

[Whoops! I forgot to copy the list on this one, apologies for any duplicates!]

> 4.
> compiling and running the win32 visual example  gives several asserts and then crashes:
>
> - first in express_viewer.cpp: void open_editor() > assert(stream.is_open());

At least in the sandbox version (and possibly in the regular version,
depending on how you run it) you need to have editor.adm and
editor.eve files in the same directory as the visual.exe binary. I
have been putting one of the simple examples (like the line path one)
in place of the real editor.adm and editor.eve because not all of the
widgets work yet.

> - then 2 times in void eve_t::implementation_t::solve(slice_select_t select) -> assert(limiter);
>
> - finally a crash in ui_core.cpp:
>         void window_t::set_visible(bool make_visible)
>                 { object_m->set_visible(make_visible); }

I've seen ui_core.cpp crash because some of the widgets haven't been
finished, but not in window_t. I'll try to try using the express beta
compiler, but I won't be able to do it for a couple of weeks.

Thanks,
  Ralph

> Regards,
> Peter

Re: [Adobe-source-devel] msvc8/visual

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

Thanks for these, Peter. Are you seeing these on the mainline, or the=20
sandbox, or both?

Regarding #2, I'm not sure if it is a bug or not. Sean may have a=20
better answer.

Regarding #4, I'm able to execute Adobe Begin on Windows- I'm not=20
seeing these. Granted I'm using MSVC7.1 to compile, but the runtime=20
asserts shouldn't matter on what compiler they were built. Have you=20
tried to compile all this on MSVC7.1, to see if the problem might be in=20=

MSVC8?

Regarding the others, If they are unfixed in the sandbox and you can=20
submit these changes (I believe you are marked as a developer already,=20=

but if not let me know) it would be very beneficial.

Blessings,
Foster

On Mar 22, 2005, at 11:45a, Peter K=FCmmel wrote:

> Hello,
>
> here some points when compiling the visual example with msvc8 =
(express)
>
>
> 1.
> in circular_queue.hpp macro guard only for old ms compilers:
>
> #if (defined BOOST_MSVC) && (_MSC_VER < 1400)
> 	friend void ::swap<T, capacity_k>(adobe::circular_queue<T,=20
> Capacity>&, adobe::circular_queue<T, Capacity>&);
> #else
>
>
>
> 2.
> maybe bug in /future/source/assemblage.cpp,
> (isn't it a pointer to a member function!?):
>
> assemblage_t::~assemblage_t()
> {	// disconnect all our connections
>     adobe::for_each(connections_m, boost::bind(=20
> connection_t::disconnect, _1));
>                                          ----> &connection_t
>
>
> 3.
> the boost_lib.vcproj misses 'boost/libs/thread/src/xtime.cpp'
>
>
>
> 4.
> compiling and running the win32 visual example  gives several asserts=20=

> and then crashes:
>
>
> - first in express_viewer.cpp: void open_editor() >=20
> assert(stream.is_open());
>
> - then 2 times in void eve_t::implementation_t::solve(slice_select_t=20=

> select) -> assert(limiter);
>
> - finally a crash in ui_core.cpp:
> 	void window_t::set_visible(bool make_visible)
> 		{ object_m->set_visible(make_visible); }
>
> Regards,
> Peter
> 	=09
> -------------------------------------------------------
> This SF.net email is sponsored by: 2005 Windows Mobile Application=20
> Contest
> Submit applications for Windows Mobile(tm)-based Pocket PCs or=20
> Smartphones
> for the chance to win $25,000 and application distribution. Enter=20
> today at
> http://ads.osdn.com/?ad_id=3D6882&alloc_id=3D15148&op=3Dclick
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>
--
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
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] msvc8/visual

[<syn...@gm...>]

Hello,

here some points when compiling the visual example with msvc8 (express)


1.
in circular_queue.hpp macro guard only for old ms compilers:

#if (defined BOOST_MSVC) && (_MSC_VER < 1400)
	friend void ::swap<T, capacity_k>(adobe::circular_queue<T, Capacity>&, adobe::circular_queue<T, Capacity>&);
#else



2.
maybe bug in /future/source/assemblage.cpp,
(isn't it a pointer to a member function!?):

assemblage_t::~assemblage_t()
{	// disconnect all our connections
     adobe::for_each(connections_m, boost::bind( connection_t::disconnect, _1));
                                          ----> &connection_t


3.
the boost_lib.vcproj misses 'boost/libs/thread/src/xtime.cpp'



4.
compiling and running the win32 visual example  gives several asserts and then crashes:


- first in express_viewer.cpp: void open_editor() > assert(stream.is_open());

- then 2 times in void eve_t::implementation_t::solve(slice_select_t select) -> assert(limiter);

- finally a crash in ui_core.cpp:
	void window_t::set_visible(bool make_visible)
		{ object_m->set_visible(make_visible); }
		




Regards,
Peter
		

Re: [Adobe-source-devel] win32 and linux backends?

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

> How much interaction is there supposed to be between the ui-core code
> (window_t, button_t...) and application code? Is it all meant to
> happen through Adam and Eve, is there ever a circumstance where you
> want to touch a button_t directly from application code?

Our contention is that if you are coding to the semantics of the 
widget, beating on the platform widget directly should not be 
necessary. If you are finding a need to do so, you should ask yourself:

Am I trying to do something that would go against the semantics of the 
widget (irrespective of the API)? If yes, consider another widget for 
what you are trying to do. If not, what is lacking in the API that 
would improve its reflection of the semantics of the widget? The answer 
to this could be a good change to the API for the widget.

> If not, is it
> important to implement the same C++ interfaces on every platform so
> long as the interface from Eve is the same?

Yes.

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
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

Re: [Adobe-source-devel] XCode projects?

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

Hey David,

I highly encourage you to work on the inclusion of those XCode 
projects! If you are willing let me know-- I believe you are on the 
developer list already but if not I can add you to it quickly. I'm sure 
you are not the only person out there who would benefit from such work.

Blessings,
Foster

On Mar 21, 2005, at 05:40p, David Catmull wrote:

> Can I make a plea for XCode projects to be added? Not all of us have 
> CodeWarrior 9, and opening the existing projects in CW8 loses the 
> access paths and stuff. Thanks.
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>
--
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
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

Re: [Adobe-source-devel] XCode projects?

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

You could build using bjam (which can be downloaded from
http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=72941
).

It should be easy enough to create XCode project files (by looking at
the existing Jamfiles to see what to define) but I've not actually
used XCode for more than a few minutes...

Thanks,
 Ralph

David Catmull <unc...@un...> wrote:
> Can I make a plea for XCode projects to be added? Not all of us have
> CodeWarrior 9, and opening the existing projects in CW8 loses the
> access paths and stuff. Thanks.
> 
> --
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

[Adobe-source-devel] XCode projects?

[David C. <unc...@un...>]

Can I make a plea for XCode projects to be added? Not all of us have 
CodeWarrior 9, and opening the existing projects in CW8 loses the 
access paths and stuff. Thanks.

-- 
David Catmull
unc...@un...
http://www.uncommonplace.com/

Re: [Adobe-source-devel] Adobe Begin changes

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

I've made some changes to get Ralph's submission building again in 
CodeWarrior, and checked in the changes to the sandbox.

Thanks, Ralph!

Blessings,
Foster

On Mar 20, 2005, at 08:35p, Ralph Thomas wrote:

> Hi folks,
>
> I just checked in some changes to the adobe/test/visual program (in
> the sandbox):
>
>   * Jamfile, boost-build.jam, project-root.jam -- the program can now
> be built using bjam
>   * headers/latch.hpp -- now compiles
>   * headers/report_exception.hpp -- REGRESSION: only logs exceptions
> to disk, as editor_sheet_g was removed
>   * headers/ui_core.hpp -- made change to visiblilty of
> window_t::implementation_t for GCC as had been done for MSVC.
>   * headers/express_viewer.hpp -- defines simpleApplication class
>   * sources/express_viewer.cpp -- implements simpleApplication class
>   * sources/mac/main.cpp -- main driver for macintosh
>   * sources/win/main.cpp -- main driver for Win32
>
> Previously the Adobe Begin application was all in express_viewer.cpp.
> I broke it out and put the platform independent bits (most of the
> code) in express_viewer.cpp (in a class called simpleApplication --
> might be a good idea to rename it to express_viewer...). The main.cpp
> files contain the main functions, and any platform specific code
> (typically very little).
>
> I hope to fix the regression soon. I have been able to build this on
> Windows (using MSVC 2003, it should also work with the free MSVC
> Toolbox), and I have been able to build the files I touched for Mac,
> using GCC. I had trouble getting the rest of the application to
> compile with GCC, however (I have modifications which get most of the
> way there, but only hacks at this stage). Hopefully it will all
> compile fine on codewarrior.
>
> Thanks,
>  Ralph
>
> PS: It would be nice if ui_core supported application menus (in the
> main window, or at the top of the screen) -- currently a lot of
> functionality is inaccessible on Win32 because there is no application
> menu.
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>
--
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
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] Adobe Begin changes

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

Hi folks,

I just checked in some changes to the adobe/test/visual program (in
the sandbox):

  * Jamfile, boost-build.jam, project-root.jam -- the program can now
be built using bjam
  * headers/latch.hpp -- now compiles
  * headers/report_exception.hpp -- REGRESSION: only logs exceptions
to disk, as editor_sheet_g was removed
  * headers/ui_core.hpp -- made change to visiblilty of
window_t::implementation_t for GCC as had been done for MSVC.
  * headers/express_viewer.hpp -- defines simpleApplication class
  * sources/express_viewer.cpp -- implements simpleApplication class
  * sources/mac/main.cpp -- main driver for macintosh
  * sources/win/main.cpp -- main driver for Win32

Previously the Adobe Begin application was all in express_viewer.cpp.
I broke it out and put the platform independent bits (most of the
code) in express_viewer.cpp (in a class called simpleApplication --
might be a good idea to rename it to express_viewer...). The main.cpp
files contain the main functions, and any platform specific code
(typically very little).

I hope to fix the regression soon. I have been able to build this on
Windows (using MSVC 2003, it should also work with the free MSVC
Toolbox), and I have been able to build the files I touched for Mac,
using GCC. I had trouble getting the rest of the application to
compile with GCC, however (I have modifications which get most of the
way there, but only hacks at this stage). Hopefully it will all
compile fine on codewarrior.

Thanks,
 Ralph

PS: It would be nice if ui_core supported application menus (in the
main window, or at the top of the screen) -- currently a lot of
functionality is inaccessible on Win32 because there is no application
menu.

Re: [Adobe-source-devel] PATCH: including wrong name header in parser_shared.hpp

[Niki S. <nik...@gm...>]

===================================================================
> RCS file: /cvsroot/adobe-source/adobe-source/adobe/test/adam_tutorial/Jamfile,v
> retrieving revision 1.1
> diff -u -r1.1 Jamfile
> --- adobe/test/adam_tutorial/Jamfile    7 Mar 2005 07:28:36 -0000       1.1
> +++ adobe/test/adam_tutorial/Jamfile    15 Mar 2005 08:49:50 -0000
> @@ -43,5 +43,6 @@
>                 ../../../third_party/boost_tp/boost/libs/thread/src/exceptions.cpp
>                 ../../../third_party/boost_tp/boost/libs/thread/src/mutex.cpp
>                 ../../../third_party/boost_tp/boost/libs/thread/src/once.cpp
> -       :       <define>ADOBE_SERIALIZATION
> +               ../../../third_party/boost_tp/boost/libs/thread/src/xtime.cpp
> +       :       <define>ADOBE_SERIALIZATION <define>BOOST_ALL_NO_LIB=1
> <define>BOOST_THREAD_USE_LIB
>         ;

FYI this works for mingw too.

Niki Spahiev

Re: [Adobe-source-devel] what version of GCC should be used?

[Niki S. <nik...@gm...>]

current cvs compiles with gcc-3.4.2 (mingw) with small patch:

Index: eve.cpp
===================================================================
RCS file: /cvsroot/adobe-source/adobe-source/adobe/source/eve.cpp,v
retrieving revision 1.3
diff -u -r1.3 eve.cpp
--- eve.cpp	17 Mar 2005 18:03:14 -0000	1.3
+++ eve.cpp	18 Mar 2005 16:04:29 -0000
@@ -38,7 +38,7 @@
 
 /*************************************************************************************************/
 
-#ifdef BOOST_MSVC
+#if defined(__GNUC__) || defined(BOOST_MSVC)
 #include <cmath>
 #endif

Re: [Adobe-source-devel] starting win32 implementation

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

I've checked in the changes to CVS. Please let me know if you have any 
problems with my submission.

Blessings,
Foster

On Mar 17, 2005, at 08:50a, Foster T. Brereton wrote:

> Hey Ralph,
>
> Thanks for taking these first steps. I've been on vacation for a 
> couple days and am triaging my email at the moment...
>
> I'm actually in the midst of porting the code to Win32 right now, and 
> have made a set of changes to the code base that I'd like to check in 
> to CVS as soon as possible. Most of my changes involve a 
> Windows-specific ui_core_implementation.hpp/cpp. The biggest help you 
> can provide would actually be in generalizing express_viewer.cpp. I 
> have made some changes there but there is a lot more that could/should 
> be done.
>
> My request at this point is to hold off for a bit until I can get my 
> changes checked in to CVS. I'll post on this list when the changes are 
> in. Once that is done any help on furthering the Win32 implementation 
> would be great!
>
> Blessings,
> Foster
>
> On Mar 16, 2005, at 11:53p, Ralph Thomas wrote:
>
>> Hello,
>>
>>   I've started to write a Win32 implementation of the test/visual
>> program. What's the best way for me to write something which can be
>> checked in? I was planning on moving the proxy objects in
>> client_assembler.cpp into a separate hpp and cpp files, writing a
>> Win32 version of ui_core_implementation.cpp and making an abstract
>> interface to the main loops (i.e.: RunApplicationEventLoop and
>> GetEvent/TranslateEvent/DispatchEvent).
>>
>>   This should be enough to turn the visual sample into a library and
>> example which can be used by other people more readily than the
>> current stuff can.
>>
>> Thanks,
>>   Ralph
>>
>>
>> -------------------------------------------------------
>> SF email is sponsored by - The IT Product Guide
>> Read honest & candid reviews on hundreds of IT Products from real 
>> users.
>> Discover which products truly live up to the hype. Start reading now.
>> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>>
>>
> --
> 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
> "What 99 percent of programmers need to know is not how to build
> components but how to use them." -- Alexander Stepanov
>
>
--
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
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

Re: [Adobe-source-devel] starting win32 implementation

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

Hey Ralph,

Thanks for taking these first steps. I've been on vacation for a couple 
days and am triaging my email at the moment...

I'm actually in the midst of porting the code to Win32 right now, and 
have made a set of changes to the code base that I'd like to check in 
to CVS as soon as possible. Most of my changes involve a 
Windows-specific ui_core_implementation.hpp/cpp. The biggest help you 
can provide would actually be in generalizing express_viewer.cpp. I 
have made some changes there but there is a lot more that could/should 
be done.

My request at this point is to hold off for a bit until I can get my 
changes checked in to CVS. I'll post on this list when the changes are 
in. Once that is done any help on furthering the Win32 implementation 
would be great!

Blessings,
Foster

On Mar 16, 2005, at 11:53p, Ralph Thomas wrote:

> Hello,
>
>   I've started to write a Win32 implementation of the test/visual
> program. What's the best way for me to write something which can be
> checked in? I was planning on moving the proxy objects in
> client_assembler.cpp into a separate hpp and cpp files, writing a
> Win32 version of ui_core_implementation.cpp and making an abstract
> interface to the main loops (i.e.: RunApplicationEventLoop and
> GetEvent/TranslateEvent/DispatchEvent).
>
>   This should be enough to turn the visual sample into a library and
> example which can be used by other people more readily than the
> current stuff can.
>
> Thanks,
>   Ralph
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>
--
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
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] starting win32 implementation

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

Hello,

  I've started to write a Win32 implementation of the test/visual
program. What's the best way for me to write something which can be
checked in? I was planning on moving the proxy objects in
client_assembler.cpp into a separate hpp and cpp files, writing a
Win32 version of ui_core_implementation.cpp and making an abstract
interface to the main loops (i.e.: RunApplicationEventLoop and
GetEvent/TranslateEvent/DispatchEvent).

  This should be enough to turn the visual sample into a library and
example which can be used by other people more readily than the
current stuff can.

Thanks,
  Ralph

Re: [Adobe-source-devel] what version of GCC should be used?

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

3.4.2 currently isn't on our list of compilers (our GCC usage is  
tracking Apple's released compilers at the moment) - However, I made  
some changes that we should roll out soon:

On Mar 15, 2005, at 3:40 AM, Niki Spahiev wrote:

> Using - gcc version 3.4.2 (mingw-special) i got this
>
> gcc.compile.c++ bin\gcc\debug\eve.o
> In file included from ../../../adobe/eve.hpp:19,
>                  from ..\..\source\eve.cpp:22:
> ../../../adobe/forest.hpp:392: error: expected `;' before "nodes_m"

This is our bug, I'm removing the qualifier.

> ../../../adobe/forest.hpp:402: error: non-template `rebind' used as  
> template

Hmm - not sure if this is our issue or not - but I added a template  
qualifier that should fix it.

>
> and this
>
> gcc.compile.c++ bin\gcc\debug\virtual_machine.o
> ../../../third_party/boost_tp/boost/boost/type_traits/remove_const.hpp:
> In function `void <unnamed>::virtual_machine_init_once()':
> ../../../third_party/boost_tp/boost/boost/type_traits/ 
> remove_const.hpp:56:
> error: `template<class T> struct boost::remove_const' is not a
> function,
> ../../../adobe/conversion.hpp:42: error:   conflict with
> `template<class T> T& adobe::remove_const(const T&)'
> ..\..\source\virtual_machine.cpp:355: error:   in call to  
> `remove_const'

Yikes - This is very odd - the error message is saying that a fully  
qualified function name is conflicting with a structure in another  
namespace... I suspect this is a gcc bug in this version.

Foster's on vacation at the moment - I'll have him update the CVS when  
he returns with the above fixes.
Sean

>
> regards,
> Niki Spahiev
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real  
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] what version of GCC should be used?

[Niki S. <nik...@gm...>]

Using - gcc version 3.4.2 (mingw-special) i got this

gcc.compile.c++ bin\gcc\debug\eve.o
In file included from ../../../adobe/eve.hpp:19,
                 from ..\..\source\eve.cpp:22:
../../../adobe/forest.hpp:392: error: expected `;' before "nodes_m"
../../../adobe/forest.hpp:402: error: non-template `rebind' used as template

and this

gcc.compile.c++ bin\gcc\debug\virtual_machine.o
../../../third_party/boost_tp/boost/boost/type_traits/remove_const.hpp:
In function `void <unnamed>::virtual_machine_init_once()':
../../../third_party/boost_tp/boost/boost/type_traits/remove_const.hpp:56:
error: `template<class T> struct boost::remove_const' is not a
function,
../../../adobe/conversion.hpp:42: error:   conflict with
`template<class T> T& adobe::remove_const(const T&)'
..\..\source\virtual_machine.cpp:355: error:   in call to `remove_const'

regards,
Niki Spahiev

Re: [Adobe-source-devel] PATCH: including wrong name header in parser_shared.hpp

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

Great!

I also had to make some changes to the adam_tutorial Jamfile to make
it build on Win32/MSVC7.1... I don't think that the
BOOST_THREAD_USE_LIB is really correct, but without it the link fails
because some symbols don't get exported (for some other reason, _DLL
is defined and this makes boost.thread think that it should do symbol
hiding).

Thanks,
 Ralph

Index: adobe/test/adam_tutorial/Jamfile
===================================================================
RCS file: /cvsroot/adobe-source/adobe-source/adobe/test/adam_tutorial/Jamfile,v
retrieving revision 1.1
diff -u -r1.1 Jamfile
--- adobe/test/adam_tutorial/Jamfile	7 Mar 2005 07:28:36 -0000	1.1
+++ adobe/test/adam_tutorial/Jamfile	15 Mar 2005 08:49:50 -0000
@@ -43,5 +43,6 @@
 		../../../third_party/boost_tp/boost/libs/thread/src/exceptions.cpp 
 		../../../third_party/boost_tp/boost/libs/thread/src/mutex.cpp 
 		../../../third_party/boost_tp/boost/libs/thread/src/once.cpp
-	:	<define>ADOBE_SERIALIZATION
+		../../../third_party/boost_tp/boost/libs/thread/src/xtime.cpp
+	:	<define>ADOBE_SERIALIZATION <define>BOOST_ALL_NO_LIB=1
<define>BOOST_THREAD_USE_LIB
 	;

On Mon, 14 Mar 2005 21:31:06 -0800, Sean Parent <sp...@ad...> wrote:
> Hi Ralph,
> Thanks for the catch - the correct fix is to #include <adobe/name.hpp>
> in parser_shared.cpp (we try to stick to only forward includes in the
> headers - this issue with name_t hadn't come up, I'll think about it to
> see if I can find a way to handle it that will show the error more
> readily in the future).
> 
> I checked in a fix on our side to our perforce depot - I'll have Foster
> roll it into CVS.
> 
> Thanks for the updated instructions also! - we'll incorporate it into a
> building ASL page (we have such a page internally, it hadn't come up
> yet for the open source release).
> 
> Sean
> 
> On Mar 14, 2005, at 8:24 PM, Ralph Thomas wrote:
> 
> > Hi folks,
> >
> >   I tried using ASL on Linux/x86, with GCC 3.2.3. I couldn't link a
> > release build of the adam tutorial (after I'd removed the call to
> > adam_t::inspect, which is only available in debug builds), because
> > parser_shared.o didn't know that name_t::get was inline. Changing the
> > name_t header file which parser_shared.hpp includes fixes the problem
> > (oddly enough a debug build compiles and links fine without the change
> > -- maybe debug turns off inlining).
> >
> >   I didn't see any instructions on how to make a build (perhaps I
> > didn't look hard enough -- I ended up reading the shell script which
> > checks the code out of boxer.corp...), so I wrote a brief list:
> >
> >   http://www.infinite-imagination.com/software/asl/
> >
> > Thanks,
> >  Ralph
> >
> >> c_rdiff parser_shared.hpp
> > Index: parser_shared.hpp
> > ===================================================================
> > RCS file:
> > /cvsroot/adobe-source/adobe-source/adobe/source/parser_shared.hpp,v
> > retrieving revision 1.2
> > diff -r1.2 parser_shared.hpp
> > 15c15
> > < #include <adobe/name_fwd.hpp>
> > ---
> >> #include <adobe/name.hpp>
> >
> >

Re: [Adobe-source-devel] PATCH: including wrong name header in parser_shared.hpp

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

Hi Ralph,
Thanks for the catch - the correct fix is to #include <adobe/name.hpp> 
in parser_shared.cpp (we try to stick to only forward includes in the 
headers - this issue with name_t hadn't come up, I'll think about it to 
see if I can find a way to handle it that will show the error more 
readily in the future).

I checked in a fix on our side to our perforce depot - I'll have Foster 
roll it into CVS.

Thanks for the updated instructions also! - we'll incorporate it into a 
building ASL page (we have such a page internally, it hadn't come up 
yet for the open source release).

Sean

On Mar 14, 2005, at 8:24 PM, Ralph Thomas wrote:

> Hi folks,
>
>   I tried using ASL on Linux/x86, with GCC 3.2.3. I couldn't link a
> release build of the adam tutorial (after I'd removed the call to
> adam_t::inspect, which is only available in debug builds), because
> parser_shared.o didn't know that name_t::get was inline. Changing the
> name_t header file which parser_shared.hpp includes fixes the problem
> (oddly enough a debug build compiles and links fine without the change
> -- maybe debug turns off inlining).
>
>   I didn't see any instructions on how to make a build (perhaps I
> didn't look hard enough -- I ended up reading the shell script which
> checks the code out of boxer.corp...), so I wrote a brief list:
>
>   http://www.infinite-imagination.com/software/asl/
>
> Thanks,
>  Ralph
>
>> c_rdiff parser_shared.hpp
> Index: parser_shared.hpp
> ===================================================================
> RCS file: 
> /cvsroot/adobe-source/adobe-source/adobe/source/parser_shared.hpp,v
> retrieving revision 1.2
> diff -r1.2 parser_shared.hpp
> 15c15
> < #include <adobe/name_fwd.hpp>
> ---
>> #include <adobe/name.hpp>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real 
> users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] PATCH: including wrong name header in parser_shared.hpp

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

Hi folks,

  I tried using ASL on Linux/x86, with GCC 3.2.3. I couldn't link a
release build of the adam tutorial (after I'd removed the call to
adam_t::inspect, which is only available in debug builds), because
parser_shared.o didn't know that name_t::get was inline. Changing the
name_t header file which parser_shared.hpp includes fixes the problem
(oddly enough a debug build compiles and links fine without the change
-- maybe debug turns off inlining).

  I didn't see any instructions on how to make a build (perhaps I
didn't look hard enough -- I ended up reading the shell script which
checks the code out of boxer.corp...), so I wrote a brief list:

  http://www.infinite-imagination.com/software/asl/

Thanks,
 Ralph

> c_rdiff parser_shared.hpp 
Index: parser_shared.hpp
===================================================================
RCS file: /cvsroot/adobe-source/adobe-source/adobe/source/parser_shared.hpp,v
retrieving revision 1.2
diff -r1.2 parser_shared.hpp
15c15
< #include <adobe/name_fwd.hpp>
---
> #include <adobe/name.hpp>