adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] visual link errors

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

I've tried rebuilding all the libraries, but I can't figure out how  
to make these link errors go away. Here's the current list of errors:

__ZNSt11char_traitsIhE11eq_int_typeERKmS2_
__ZNSt11char_traitsIhE11to_int_typeERKh
__ZNSt11char_traitsIhE12to_char_typeERKm
__ZNSt11char_traitsIhE2eqERKhS2_
__ZNSt11char_traitsIhE3eofEv
__ZNSt11char_traitsIhE4copyEPhPKhm
__ZNSt11char_traitsIhE6assignERhRKh
__ZNSt11char_traitsIhE7not_eofERKm
__ZNSt15_List_node_base4hookEPS_
__ZNSt15_List_node_base6unhookEv
__ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base
__ZSt18_Rb_tree_incrementPSt18_Rb_tree_node_base
__ZSt28_Rb_tree_rebalance_for_erasePSt18_Rb_tree_node_baseRS_
__ZSt29_Rb_tree_insert_and_rebalancebPSt18_Rb_tree_node_baseS0_RS_
__ZNSt15_List_node_base4swapERS_S0_
__ZNSt15_List_node_base7reverseEv
__ZNSt15_List_node_base8transferEPS_S0_

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

Re: [Adobe-source-devel] visual link errors

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

The first is in boost/libs/thread/src/once.cpp, but should be included 
by the boost_lib project.

The latter are standard library functions, most included by <string>

Blessings,
Foster

On May 16, 2005, at 01:55p, David Catmull wrote:

> I get these link errors when I try to build the visual app. With the 
> way the names are mangled, I can't tell what files I should be looking 
> for to add to the projects.
>
> __ZN5boost9call_onceEPFvvER22_opaque_pthread_once_t
> __ZNSt11char_traitsIhE11eq_int_typeERKmS2_
> __ZNSt11char_traitsIhE11to_int_typeERKh
> __ZNSt11char_traitsIhE12to_char_typeERKm
> __ZNSt11char_traitsIhE2eqERKhS2_
> __ZNSt11char_traitsIhE3eofEv
> __ZNSt11char_traitsIhE4copyEPhPKhm
> __ZNSt11char_traitsIhE6assignERhRKh
> __ZNSt11char_traitsIhE7not_eofERKm
>
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&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] Errors with auto_resource::operator safe_bool()

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

This one isn't quite so easy to fix... I've been meaning to roll in the 
suggestions from here:

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#463

Into my implementation of auto_ptr. I'll work on that today and try to 
get a new implementation out ASAP.
Sean

On May 16, 2005, at 12:44 PM, David Catmull wrote:

> ../../../adobe/future/memory.hpp:292: error: declaration of 
> 'adobe::auto_resource<X, Traits>::operator void 
> (adobe::auto_resource<X, Traits>::dummy::*)()() const'
> ../../../adobe/future/memory.hpp:289: error: conflicts with previous 
> declaration 'adobe::auto_resource<X, Traits>::operator 
> adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename 
> Traits::rebind<Y>::other>()'

[Adobe-source-devel] visual link errors

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

I get these link errors when I try to build the visual app. With the  
way the names are mangled, I can't tell what files I should be  
looking for to add to the projects.

__ZN5boost9call_onceEPFvvER22_opaque_pthread_once_t
__ZNSt11char_traitsIhE11eq_int_typeERKmS2_
__ZNSt11char_traitsIhE11to_int_typeERKh
__ZNSt11char_traitsIhE12to_char_typeERKm
__ZNSt11char_traitsIhE2eqERKhS2_
__ZNSt11char_traitsIhE3eofEv
__ZNSt11char_traitsIhE4copyEPhPKhm
__ZNSt11char_traitsIhE6assignERhRKh
__ZNSt11char_traitsIhE7not_eofERKm


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

Re: [Adobe-source-devel] Errors with auto_resource::operator safe_bool()

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

There are still quite a few errors left. I assumed that they were  
related enough that one or two changes will fix them all, but I may  
be wrong. It does compile without errors with gcc 3.3 though, so if  
there are no further problems with getting Begin to build (I haven't  
tried the app target yet) I'll check in the changes to the project.


../../../adobe/future/memory.hpp:292: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>()'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<__CFNumberFormatter*,  
adobe::ptr_traits<__CFNumberFormatter*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
headers/mac/ui_core_implementation.hpp:323:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X =  
__CFNumberFormatter*, Traits = adobe::ptr_traits<__CFNumberFormatter*>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = __CFNumberFormatter*,  
Traits = adobe::ptr_traits<__CFNumberFormatter*>]'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<const __CFString*, adobe::ptr_traits<const  
__CFString*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/mac/ui_core_implementation.cpp:123:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X = const  
__CFString*, Traits = adobe::ptr_traits<const __CFString*>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = const __CFString*,  
Traits = adobe::ptr_traits<const __CFString*>]'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<OpaqueGrafPtr*,  
adobe::ptr_traits<OpaqueGrafPtr*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/mac/ui_core_implementation.cpp:391:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X =  
OpaqueGrafPtr*, Traits = adobe::ptr_traits<OpaqueGrafPtr*>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = OpaqueGrafPtr*, Traits =  
adobe::ptr_traits<OpaqueGrafPtr*>]'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<OpaqueRgnHandle*,  
adobe::ptr_traits<OpaqueRgnHandle*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/mac/ui_core_implementation.cpp:1154:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X =  
OpaqueRgnHandle*, Traits = adobe::ptr_traits<OpaqueRgnHandle*>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = OpaqueRgnHandle*, Traits  
= adobe::ptr_traits<OpaqueRgnHandle*>]'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<char**, adobe::ptr_traits<char**> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/mac/ui_core_implementation.cpp:1446:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X =  
char**, Traits = adobe::ptr_traits<char**>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = char**, Traits =  
adobe::ptr_traits<char**>]'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<const __CFLocale*, adobe::ptr_traits<const  
__CFLocale*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/mac/ui_core_implementation.cpp:2226:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X = const  
__CFLocale*, Traits = adobe::ptr_traits<const __CFLocale*>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = const __CFLocale*,  
Traits = adobe::ptr_traits<const __CFLocale*>]'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<__CFDictionary*,  
adobe::ptr_traits<__CFDictionary*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/mac/ui_core_implementation.cpp:3709:   instantiated from here
../../../adobe/future/memory.hpp:263: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const [with X =  
__CFDictionary*, Traits = adobe::ptr_traits<__CFDictionary*>]'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<X, Traits>::auto_resource_ref<Y, typename  
Traits::rebind<Y>::other>() [with Y = Y, X = __CFDictionary*, Traits  
= adobe::ptr_traits<__CFDictionary*>]'

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

Re: [Adobe-source-devel] Errors with auto_resource::operator safe_bool()

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

The change is rolled out to CVS.

On May 16, 2005, at 10:52a, Sean Parent wrote:

>
> On May 15, 2005, at 11:19 AM, David Catmull wrote:
>
>> ../../../adobe/future/memory.hpp:289: error: conflicts with previous 
>> declaration 'adobe::auto_resource<X, Traits>::operator 
>> adobe::auto_resource<Y, typename Traits::rebind<Y>::other>'
>>
>
> I checked in a potential fix by removing this declaration (and the 
> associated definition) - (Foster will have to roll the out to CVS). 
> I'm not sure why these declarations would conflict - but this 
> declaration seems to be unnecessary (the conversion can be handled by 
> the constructor and assignment operator, I would think...). Removing 
> it required no other changes in our code so I took it out.
>
> Sean
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7412&alloc_id=16344&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] Errors with auto_resource::operator safe_bool()

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

On May 15, 2005, at 11:19 AM, David Catmull wrote:

> ../../../adobe/future/memory.hpp:289: error: conflicts with previous 
> declaration 'adobe::auto_resource<X, Traits>::operator 
> adobe::auto_resource<Y, typename Traits::rebind<Y>::other>'
>

I checked in a potential fix by removing this declaration (and the 
associated definition) - (Foster will have to roll the out to CVS). I'm 
not sure why these declarations would conflict - but this declaration 
seems to be unnecessary (the conversion can be handled by the 
constructor and assignment operator, I would think...). Removing it 
required no other changes in our code so I took it out.

Sean

[Adobe-source-devel] Errors with auto_resource::operator safe_bool()

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

I'm getting a bunch of errors like this when compiling  
ui_core_implementation.cpp:

../../../adobe/future/memory.hpp:295: error: declaration of  
'adobe::auto_resource<X, Traits>::operator void  
(adobe::auto_resource<X, Traits>::dummy::*)()() const'
../../../adobe/future/memory.hpp:289: error: conflicts with previous  
declaration 'adobe::auto_resource<X, Traits>::operator  
adobe::auto_resource<Y, typename Traits::rebind<Y>::other>'
../../../adobe/future/memory.hpp: In instantiation of  
`adobe::auto_resource<__CFNumberFormatter*,  
adobe::ptr_traits<__CFNumberFormatter*> >':
/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
headers/mac/ui_core_implementation.hpp:323:   instantiated from here

Compiling with gcc 4 (in XCode 2.0) went much better than I expected,  
after what I went through on other projects. The main thing is the  
repeated boost warnings that gcc 4 is an "unknown compiler version".  
Is there a boost update to fix this?

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

Re: [Adobe-source-devel] Re: [adobe-source-commits] sandbox/adobe-source/adobe/test/visual/sources express_viewer.cpp,1.13,1.14

[Mat M. <mm...@ad...>]

Swap no longer generates the infinite recursion compiler warning
under msvc 7.1. We fixed warnings in some other files too (including
some in boost) so I was able to check in new versions of the
asl_dev_lib and visual with (level 3) "warnings as errors" turned on.
Also we are now linking against only static libs.

 - Mat

--On Thursday, May 12, 2005 12:57 AM -0700 Sean Parent
<sp...@ad...> wrote:

> 
> On May 11, 2005, at 11:38 PM, Ralph Thomas wrote:
> 
>> Also, either the number
>> formatter is busted, or the hack I made to adobe::swap to compile
>> on  GCC
>> is broken (I haven't committed the hack, though, hopefully Sean
>> and I  can
>> figure out a real solution later in the week).
> 
> Mat was running into more issues with swap on the release build for
> Windows - we spent some time this afternoon coming up with a fix
> that I believe handles all the cases (and we've locally silenced
> the adl warnings). adobe::swap() is now renamed adobe::asl_swap() -
> and classes in the adobe namespace can now declare their swap
> overloads in the adobe namespace.
> 
> The code is checked in on our side - Mat, can you double check the
> new code on Windows? Foster, can you roll the changes from change
> list 1371 out to the sandbox for Ralph? Thanks.
> 
> Ralph, _Very_ cool to see us running with fltk!
> 
> Sean
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
> 
>  

[Adobe-source-devel] Re: sandbox/adobe-source/adobe/test/visual/sources express_viewer.cpp,1.13,1.14

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

It's great to hear that you've been working on it -- for me the
compiler chooses adobe::swap in swap_space::do_swap and ends up in an
infinite loop. I think it was trying to swap a value_t.

For anybody who's trying to build FLTK2 as part of thier project, I
have a Jamfile which builds FLTK as a bjam project (which can then be
referenced in the visual Jamfile) here:

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

This is the same Jamfile I'm using for my program, and it seems to
work well enough.

Thanks!
  Ralph

On 5/12/05, Sean Parent <sp...@ad...> wrote:
>=20
> On May 11, 2005, at 11:38 PM, Ralph Thomas wrote:
>=20
> > Also, either the number
> > formatter is busted, or the hack I made to adobe::swap to compile on=20
> > GCC
> > is broken (I haven't committed the hack, though, hopefully Sean and I=
=20
> > can
> > figure out a real solution later in the week).
>=20
> Mat was running into more issues with swap on the release build for=20
> Windows - we spent some time this afternoon coming up with a fix that I=
=20
> believe handles all the cases (and we've locally silenced the adl=20
> warnings). adobe::swap() is now renamed adobe::asl_swap() - and classes=
=20
> in the adobe namespace can now declare their swap overloads in the=20
> adobe namespace.
>=20
> The code is checked in on our side - Mat, can you double check the new=20
> code on Windows? Foster, can you roll the changes from change list 1371=
=20
> out to the sandbox for Ralph? Thanks.
>=20
> Ralph, _Very_ cool to see us running with fltk!
>=20
> Sean
>=20
>

[Adobe-source-devel] Re: [adobe-source-commits] sandbox/adobe-source/adobe/test/visual/sources express_viewer.cpp,1.13,1.14

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

On May 11, 2005, at 11:38 PM, Ralph Thomas wrote:

> Also, either the number
> formatter is busted, or the hack I made to adobe::swap to compile on 
> GCC
> is broken (I haven't committed the hack, though, hopefully Sean and I 
> can
> figure out a real solution later in the week).

Mat was running into more issues with swap on the release build for 
Windows - we spent some time this afternoon coming up with a fix that I 
believe handles all the cases (and we've locally silenced the adl 
warnings). adobe::swap() is now renamed adobe::asl_swap() - and classes 
in the adobe namespace can now declare their swap overloads in the 
adobe namespace.

The code is checked in on our side - Mat, can you double check the new 
code on Windows? Foster, can you roll the changes from change list 1371 
out to the sandbox for Ralph? Thanks.

Ralph, _Very_ cool to see us running with fltk!

Sean

[Adobe-source-devel] ui_overlay

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

Hey all,

I pulled out the hitless class out of ui_core_implementation and added 
it to its own file, now called ui_overlay_t. The API is much cleaner 
and is distinct from ui_core, which means you can add the tick marking 
to your own custom widgets for debugging purposes. The file has been 
added to the Mac CW project, MSVC project, and the Jamfile in visual. 
Other project users please include this new file... thanks!

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

[Adobe-source-devel] Release Schedule and an Apology

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

Everyone,
All of your contributions of late have been great - and I wanted to 
apologize for the lack of a "heads-up" on the 1.0.3 release. I was 
driving to get our internal and external releases in sync and neglected 
to inform all of you of the plan. It would have been good to get more 
of your changes into the final build.

Inside Adobe, ASL is now included in a significant number of projects 
and as such my team needs to be a bit more predicable on releases and 
build schedules.

What I would like to do is release the first Thursday of each month 
(this gives us the M-W to stabilize and F to address any issues we 
missed before the weekend). As the library matures we'll likely back 
off to releasing less often, but for now my feeling is once a month is 
about right.

We'll also be working to do more frequent builds and smoke tests - 
targeting (at a minimum) XCode 2 (gcc 4), MW 9.4, and Visual C++ 7.1. 
Any suggestion on getting this going would be appreciated (the ideally 
would be automated, continuous, builds on each submit - but we may 
start with nightly builds).

Thanks again,
Sean

[Adobe-source-devel] ASL 1.0.3 Released

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

I'm pleased to announce the arrival of Adobe Source Libraries 1.0.3. 
This is mostly a maintenance release but also boasts a small set of new 
features, including a threadsafe, context-sensitive string lookup 
system for internationalization of apps and binaries. There are also a 
slew of bug fixes that make this release well worth the download. The 
bits are still warm - get 'em while they're hot!

(CVS is updated, and the downloadables section will be updated shortly.)

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] Infinite recursion

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

This function should only be called once, as it's an initialization 
routine. The reason the view is static is so the assemblage stays 
around for the lifetime of the application (and hence the editor dialog 
stays around that long, too). We can dispose of the stream as soon as 
the dialog has been created, so it need not be static. Another problem 
with the stream being static is that eve definition is "open" as long 
as the application is running, which isn't the behavior you want.

Blessings,
Foster

On Apr 29, 2005, at 11:24a, David Catmull wrote:

> On Apr 29, 2005, at 11:15 AM, Foster T. Brereton wrote:
>> The line wouldn't compile on Metrowerks, either. I put in a similar 
>> fix to David's (except I didn't have my stream as static) and 
>> everything is working fine for me. I've checked it in to the 
>> repository.
>
> I was thinking that if it's being used to initialize a static 
> variable, then it ought to be static too. I suppose it's a trade-off 
> between having it never get disposed vs being unnecessarily 
> constructed on subsequent calls.
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
--
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] Infinite recursion

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

The line wouldn't compile on Metrowerks, either. I put in a similar fix  
to David's (except I didn't have my stream as static) and everything is  
working fine for me. I've checked it in to the repository.

The compiler error has to do with the fact that the std::istream&  
parameter isn't const. It's eluding me at the moment, but the problem  
deals with something like C++ compilers shouldn't allow the  
manipulation of temporary variables. In the case below the name of the  
file (const char* from c_str) was being used to construct a temporary  
std::ifstream, whose reference was then being passed to make_view, and  
I don't think compiler should like this. If the std::ifstream parameter  
was a const std::ifstream& the compiler would allow it, but then you  
wouldn't be able to manipulate the stream. David's fix (without the  
static keyword) is, I believe, the correct one.

Blessings,
Foster

On Apr 28, 2005, at 03:15p, David Catmull wrote:

> I made this change in express_viewer.cpp (starting at line 131):
>
> 	static std::ifstream editor_stream_s(editor_eve.c_str());
> 	static adobe::auto_ptr<eve_client::eve_client_holder> editor_view_s(
> 		eve_client::make_view( editor_eve.c_str(),
> 			editor_stream_s,//std::ifstream(editor_eve.c_str()),
> 			editor_sheet_s,
> 			[snip]
>
> to fix this:
>
> /Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
> sources/express_viewer.cpp:141: error: could not convert  
> `ifstream((&editor_eve)->std::basic_string<_CharT, _Traits,  
> _Alloc>::c_str() const [with _CharT = char, _Traits =  
> std::char_traits<char>, _Alloc = std::allocator<char>](),  
> (std::_Ios_Openmode)8)' to `std::istream&'
>
> ...but that gets me an infinite recursion situation in Begin that has  
> been difficult to track down. But maybe I won't have to if there's a  
> different fix for the above error :)
>
> -- 
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> 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] Another boost patch

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

Everyone,

Another bug has been found in boost and patched. In order to use the 
new xstring work that was just checked in, please check the boost patch 
file and apply the new patch to boost/function/function_template.hpp.

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: Re[2]: [Adobe-source-devel] Can't figure out why controls are behavedifferently

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

Serge,

Ah! This is a bug in the Win32 ASL 1.0.2 release. If you can grab the 
latest sources from the CVS repository (the sandbox module), it has 
been fixed. Sorry for not tackling your problem the first time.

Blessings,
Foster

On Apr 29, 2005, at 02:10a, serge fukanchik wrote:

> Foster, thank you for your careful answer, it helps very much with 
> understanding of how things work.
> But due to my fault to ask properly and prepare short example, you 
> have not told about my problem.
>
> So here is the new much simpler example:
> -----
> sheet test
> {
> interface:
> 	t	: false;
> 	a	: false;
> }
> ------
> dialog()
> {
> 	group(name: "SSFFeam")
> 	{
> 		checkbox(bind: @t, name: "Do not use optional parameters");
> 	}
> 	checkbox(bind: @a, name: "Test");
> }
> ----
> In short: when i do not place checkbox inside "group" it works 
> properly and handles user input. But when it is placed inside "group" 
> (as in this sample) it fails to change it's own state when i click on 
> it, i.e nothing happens with checkbox bound to 't' when i click on it 
> and rather checkbox bound to 'a' changes it's own state.
>
> So here is the question: is this bug or feature? Is it possible to 
> place checkbox inside group? Or, probably, i am the only one with such 
> trouble?
> ----
> Serge
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> 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[2]: [Adobe-source-devel] Can't figure out why controls are behavedifferently

[serge f. <fu...@ma...>]

Foster, thank you for your careful answer, it helps very much with understanding of how things work.
But due to my fault to ask properly and prepare short example, you have not told about my problem.

So here is the new much simpler example:
-----
sheet test
{
interface:
	t	: false;
	a	: false;
}
------
dialog()
{
	group(name: "SSFFeam")
	{
		checkbox(bind: @t, name: "Do not use optional parameters");
	}
	checkbox(bind: @a, name: "Test");
}
----
In short: when i do not place checkbox inside "group" it works properly and handles user input. But when it is placed inside "group" (as in this sample) it fails to change it's own state when i click on it, i.e nothing happens with checkbox bound to 't' when i click on it and rather checkbox bound to 'a' changes it's own state.

So here is the question: is this bug or feature? Is it possible to place checkbox inside group? Or, probably, i am the only one with such trouble?
----
Serge

Re: [Adobe-source-devel] Infinite recursion

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

Hmm... that's odd. It compiled okay on MSVC (with the #ifdef
ADOBE_PLATFORM_MAC stuff commented out). I was planning on changing
that line anyway (to create a window_server instead), but I'm more
curious about the infinite recursion error -- I've been able to use
window_server_t (which uses make_view) with both files and streams
without troubles, although I haven't been using Begin... can you give
any more information on the recursion problem? I'll look at replacing
that line, too.

Thanks,
 Ralph

On 4/28/05, David Catmull <unc...@un...> wrote:
> I made this change in express_viewer.cpp (starting at line 131):
>=20
>         static std::ifstream editor_stream_s(editor_eve.c_str());
>         static adobe::auto_ptr<eve_client::eve_client_holder> editor_view=
_s(
>                 eve_client::make_view( editor_eve.c_str(),
>                         editor_stream_s,//std::ifstream(editor_eve.c_str(=
)),
>                         editor_sheet_s,
>                         [snip]
>=20
> to fix this:
>=20
> /Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/
> sources/express_viewer.cpp:141: error: could not convert
> `ifstream((&editor_eve)->std::basic_string<_CharT, _Traits,
> _Alloc>::c_str() const [with _CharT =3D char, _Traits =3D
> std::char_traits<char>, _Alloc =3D std::allocator<char>](),
> (std::_Ios_Openmode)8)' to `std::istream&'
>=20
> ...but that gets me an infinite recursion situation in Begin that has
> been difficult to track down. But maybe I won't have to if there's a
> different fix for the above error :)
>=20
> --
> David Catmull
> unc...@un...
> http://www.uncommonplace.com/
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=3D105hix
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

[Adobe-source-devel] Infinite recursion

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

I made this change in express_viewer.cpp (starting at line 131):

	static std::ifstream editor_stream_s(editor_eve.c_str());
	static adobe::auto_ptr<eve_client::eve_client_holder> editor_view_s(
		eve_client::make_view( editor_eve.c_str(),
			editor_stream_s,//std::ifstream(editor_eve.c_str()),
			editor_sheet_s,
			[snip]

to fix this:

/Users/uncommon/Developer/ASL/sandbox/adobe-source/adobe/test/visual/ 
sources/express_viewer.cpp:141: error: could not convert  
`ifstream((&editor_eve)->std::basic_string<_CharT, _Traits,  
_Alloc>::c_str() const [with _CharT = char, _Traits =  
std::char_traits<char>, _Alloc = std::allocator<char>](),  
(std::_Ios_Openmode)8)' to `std::istream&'

...but that gets me an infinite recursion situation in Begin that has  
been difficult to track down. But maybe I won't have to if there's a  
different fix for the above error :)

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

Re: [Adobe-source-devel] Can't figure out why controls are behave differently

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

Foster's previous explanation is correct. I just wanted to add one item 
for clarification -

>> 	no_options_params : false;
>
> This means simply that the default value for the cell is false, and 
> the state of the cell changes only in accordance with any controls 
> that are connected to it.

This is equivalent to:

no_options_params : false <== no_options_params;

The default relationship in Adam is the identity relationship - this 
default relationship "connects" the input to the output (note that 
unlink in this case would have no effect).

Sean

Re: [Adobe-source-devel] value.hpp errors

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

On Apr 27, 2005, at 2:25 PM, Sean Parent wrote:
> Could you try the following fix:
>
> in adobe/algorithm.hpp move do_swap into another namespace - wrapping 
> it down one level would be sufficient:

I'm afraid that didn't work.

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

Re: [Adobe-source-devel] Can't figure out why controls are behave differently

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

Serge,

After taking a look at your Adam and Eve definitions I think the answer 
to your question lies in the details of the Adam definition. The 
Resample Image checkbox is bound to the no_options_params cell, which 
is defined in Adam as:

> 	no_options_params : false;

This means simply that the default value for the cell is false, and the 
state of the cell changes only in accordance with any controls that are 
connected to it. In this case, only checkboxes are connected to the 
cell, so this cell's values will toggle when any of the checkboxes 
connected to it are toggled. Keep in mind that all the controls bound 
to this cell will change state at the same time this cell does- all the 
controls bound to this cell are in sync with one another.

Now let's take a look at the Constrain Proportions control, which is 
bound to the constrain cell, defined in Adam as:

> 	unlink constrain : false <== no_options_params ? constrain : true;

Let us break this apart a bit. We will get to the 'unlink' keyword 
later. For starters the value of the cell initializes to false. Unlike 
the no_options_params cell however, this cell has a relationship 
defined for it with the <== operator. In this case Adam will test the 
output value of no_options_params in order to figure out what the 
output value of this cell will be.

For this to work, note that there are two parts to the value of an 
interface cell: the input value and the output value. The input value 
is the value driven by the control: check a checkbox, and the checkbox 
will set the input value for the cell it is bound to. The output cell 
is the value Adam reports as the value of the cell to other cells and 
any callbacks that care about this cell's value. Sometimes the output 
value of the cell is driven by the input value, sometimes not: it all 
depends on the relationship defined for the cell in the Adam 
definition. In our case, the constrain cell's output value is dependent 
upon the output value of no_options_params.

If no_options_params is false, then the output value of constrain will 
be forced to true. Note here that Adam knows what the output value of 
constrain should be in this case without considering the input value of 
the constrain cell. When Adam doesn't consider the input value of a 
cell, the controls that handle the inputs to that cell are disabled - 
that is why when the no_options_params cell is false (i.e., when the 
Resample Image checkbox is unchecked) the Constrain Proportions 
checkbox is disabled in a checked state.

If no_options_params is true, however, the output value of constrain 
will be whatever the input value of constrain is.

Normally, the input and output values of a cell are always the same 
value - they are 'linked' together. In the linked case, whenever the 
output value of the cell changes it is reapplied as the input value of 
the cell also. In the above case, however, that is not the user 
experience that we are shooting for: what we want is for the 
Constrained Proportions checkbox to "remember" its non-forced value 
(i.e., the value the user set it to), so that when the forced state is 
removed, the value of the checkbox reverts to the value to which the 
user set it. This is what the 'unlink' keyword is for.

'unlink' separates the input value (the value manipulated by the 
controls bound to this cell) and the output value (the value reported 
by Adam as the resultant value of the cell) of the cell, preventing 
reapplication of the output value of the cell to the input. In the 
above relationship defined for constrain, it is possible for the value 
of the cell to be something other than the input value of the cell: 
namely 'true' when no_options_params is set to 'false'. In that case, 
we do not want 'true' to get back-propagated to the input value of the 
constrain cell, as this would override the value set by the user. 
Instead, we want the input value to stay as the value set by the 
control/user. The net effect of 'unlink' is a cell that 'remembers' the 
value the user set for it, while the output value of the cell changes 
in accordance with the relationship defined for the cell in the Adam 
definition. When the relationship permits Adam to use the input value 
of the cell as the output value, the cell's output value becomes the 
value set by the user.

So there are a lot of differences between the Adam definitions of these 
two cells: one is manipulated solely by the controls that are bound to 
it (no_options_params), while the other is manipulated by either the 
controls bound to it or in accordance with the constraint placed on it 
in the Adam definition (constrain).

I hope this helped tackle some of the questions you are having. If you 
have any more questions (or if I made the situation worse), please keep 
posting your questions to this mailing list, and we'll try to get them 
answered for you. Thanks for taking a look at the Adobe Source 
Libraries!

Blessings,
Foster


On Apr 28, 2005, at 08:11a, serge fukanchik wrote:

> Hi,
> experimenting with Adam&Eve i can not find out why does checkbox 
> entitled "Resample image" works and changes it's own value along with 
> other checkbox's which is bound to the same adam variable. But that 
> very other checkbox ignores clicks and does not chagne it's value?
>
> Thank you in advance.
>
> Here is the code:
> dialog(name: "Specialized Resource Point", placement: place_column)
> {
> 	group(name: "SSFFeam", indent: 10)
> 	{
> /*		edit_text(name: "Listen address", indent: 10);
> 		group(name: "Optional parameters")
> 		{
> */
> 			column()
> 			{
> 				checkbox(bind: @no_options_params, name: "Do not use optional 
> parameters");
> 			}
> /*			group(name: "Numbers count", indent: 20)
> 			{
> 				column()
> 				{
> 					edit_number(name: "Call number", digits: 10, bind: @call_number);
> 					edit_number(name: "CorrelationID", digits: 10, bind: 
> @correlation_id);
> 					edit_number(name: "SCFID", digits: 10, bind: @scf_id);
> 				}
> 			}
> 		}
> 		group(name: "Send answer")
> 		{
> 			checkbox(bind: @send_answer, name: "Send answer");
> 			edit_text(name: "Phone mask", value: "~");
> 		}
> */	}
> 	group(name: "[ SSF ]")
> 	{
> 		static_text ( wrap: false, name: "     Handles connection to ASSP as 
> CCAFE with ACCP     " );
> 	}
> 	column()
> 	{
> 		row()
> 		{
> 			button(name: "Ok", default: true, action: @cancel, horizontal: 
> align_right);
> 			button(name: "Cancel", default: false, action: @cancel, horizontal: 
> align_right);
> 		}
> 	}
>
> 	column()
> 	{
> 		checkbox(bind: @scale_styles, name: "Scale Styles");
> 		checkbox(bind: @constrain, name: "Constrain Proportions");
>
> 		checkbox(bind: @no_options_params, name: "Resample Image:");
> 	}
> }
> ---------------
> sheet distance_calculator
> {
> interface:
> 	unlink	constrain	: false <== no_options_params ? constrain : true;
> 	unlink	scale_styles	: false <== no_options_params && constrain ? 
> scale_styles : false;
>
>
> 	no_options_params 	: false;
> /*	send_answer		: false;
> 	call_number		: 2 <== (no_options_params) ? call_number : empty;
> 	correlation_id  	: 2 <== (no_options_params) ? correlation_id : empty;
> 	scf_id			: 2 <== (no_options_params) ? scf_id : empty;*/
> }
> ---
> Serge
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> 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] Can't figure out why controls are behave differently

[serge f. <fu...@ma...>]

Hi,
experimenting with Adam&Eve i can not find out why does checkbox entitled "Resample image" works and changes it's own value along with other checkbox's which is bound to the same adam variable. But that very other checkbox ignores clicks and does not chagne it's value?

Thank you in advance.

Here is the code:
dialog(name: "Specialized Resource Point", placement: place_column)
{
	group(name: "SSFFeam", indent: 10)
	{
/*		edit_text(name: "Listen address", indent: 10);
		group(name: "Optional parameters")
		{
*/
			column()
			{
				checkbox(bind: @no_options_params, name: "Do not use optional parameters");
			}
/*			group(name: "Numbers count", indent: 20)
			{
				column()
				{
					edit_number(name: "Call number", digits: 10, bind: @call_number);
					edit_number(name: "CorrelationID", digits: 10, bind: @correlation_id);
					edit_number(name: "SCFID", digits: 10, bind: @scf_id);
				}
			}
		}
		group(name: "Send answer")
		{
			checkbox(bind: @send_answer, name: "Send answer");
			edit_text(name: "Phone mask", value: "~");
		}
*/	}
	group(name: "[ SSF ]")
	{
		static_text ( wrap: false, name: "     Handles connection to ASSP as CCAFE with ACCP     " );
	}
	column()
	{
		row()
		{
			button(name: "Ok", default: true, action: @cancel, horizontal: align_right);
			button(name: "Cancel", default: false, action: @cancel, horizontal: align_right);
		}
	}

	column()
	{
		checkbox(bind: @scale_styles, name: "Scale Styles");
		checkbox(bind: @constrain, name: "Constrain Proportions");

		checkbox(bind: @no_options_params, name: "Resample Image:");
	}
}
---------------
sheet distance_calculator
{
interface:
	unlink	constrain	: false <== no_options_params ? constrain : true;
	unlink	scale_styles	: false <== no_options_params && constrain ? scale_styles : false;


	no_options_params 	: false;
/*	send_answer		: false;
	call_number		: 2 <== (no_options_params) ? call_number : empty;
	correlation_id  	: 2 <== (no_options_params) ? correlation_id : empty;
	scf_id			: 2 <== (no_options_params) ? scf_id : empty;*/
}
---
Serge