Menu
▾
▴
adobe-source-devel — ASL development topic discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(70) |
Apr
(101) |
May
(24) |
Jun
(15) |
Jul
(1) |
Aug
(2) |
Sep
(1) |
Oct
(5) |
Nov
(5) |
Dec
(30) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(58) |
Feb
(29) |
Mar
(4) |
Apr
(5) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
(6) |
Sep
(32) |
Oct
(29) |
Nov
(7) |
Dec
(8) |
| 2007 |
Jan
(11) |
Feb
(12) |
Mar
(6) |
Apr
(19) |
May
(26) |
Jun
(7) |
Jul
|
Aug
(1) |
Sep
(4) |
Oct
|
Nov
(1) |
Dec
(3) |
| 2008 |
Jan
(6) |
Feb
(1) |
Mar
(24) |
Apr
(8) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
(4) |
Mar
(3) |
Apr
(1) |
May
(52) |
Jun
(11) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(3) |
Dec
(4) |
| 2010 |
Jan
(2) |
Feb
(6) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(3) |
Nov
(2) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(2) |
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Niki S. <nik...@gm...> - 2005-06-27 10:39:18
|
When i run "begin.exe test.adm test.eve" all panels are empty. When i type some text in first panel and hit update - text goes to test.adm file overwriting original content. After that panels show proper text and all seems to work. begin.exe does not work on Win2000 until i set WS_EX_COMPOSITE to zero. Niki Spahiev |
|
From: Niki S. <nik...@gm...> - 2005-06-27 10:32:46
|
Hello, After long battle with boost.build V2 i have first working version of python interface. So far just bits of value_t and dictionary_t. In order to compile with boost 1.32.0 set PYTHON_PATH. Any comments on naming, directory structure, etc. are welcome. There is not way to tell value_t(int) from value_t(double) right? Niki Spahiev |
|
From: Sean P. <sp...@ad...> - 2005-06-25 02:38:11
|
Any luck hunting this down? Sean On Jun 8, 2005, at 11:38 PM, Ralph Thomas wrote: > Hi List, > > I've finally had a chance to look at ASL some more. I decided to add > resizable windows to the FLTK implementation. I now have > layout_m->adjust being called with appropriate values, at the right > time, however none of the widgets move (they are all moved to the > place they were before). > > This happens for the resizable examples (like slider_suite) as well > as my own GUI... What's going wrong? > > Thanks, > Ralph > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can > you shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: Foster T. B. <fbr...@ad...> - 2005-06-21 20:53:37
|
Hi, That was my mistake. They shouldn't have been reverted. If you could put them back, that would be great. Thanks for the catch! Blessings, Foster On Jun 21, 2005, at 08:38a, Jamie Gadd wrote: > Hi, > > I uploaded a couple of minor fixes to CVS and they were recently > reverted. The changes were: > > http://cvs.sourceforge.net/viewcvs.py/adobe-source/sandbox/adobe- > source/adobe/test/adam_tutorial/main.cpp?r1=1.5&r2=1.6 > http://cvs.sourceforge.net/viewcvs.py/adobe-source/sandbox/adobe- > source/adobe/test/xstr_test/main.cpp?r1=1.1&r2=1.2 > > Any objections if I re-add these fixes? > > Thanks > Jamie > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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 |
|
From: Sean P. <sp...@ad...> - 2005-06-21 20:48:46
|
None - Foster, can you look into why these were lost? Sean On Jun 21, 2005, at 8:38 AM, Jamie Gadd wrote: > Hi, > > I uploaded a couple of minor fixes to CVS and they were recently > reverted. The changes were: > > http://cvs.sourceforge.net/viewcvs.py/adobe-source/sandbox/adobe- > source/adobe/test/adam_tutorial/main.cpp?r1=1.5&r2=1.6 > http://cvs.sourceforge.net/viewcvs.py/adobe-source/sandbox/adobe- > source/adobe/test/xstr_test/main.cpp?r1=1.1&r2=1.2 > > Any objections if I re-add these fixes? > > Thanks > Jamie > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > |
|
From: Jamie G. <jr...@cs...> - 2005-06-21 19:30:26
|
Hi, I uploaded a couple of minor fixes to CVS and they were recently reverted. The changes were: http://cvs.sourceforge.net/viewcvs.py/adobe-source/sandbox/adobe-source/adobe/test/adam_tutorial/main.cpp?r1=1.5&r2=1.6 http://cvs.sourceforge.net/viewcvs.py/adobe-source/sandbox/adobe-source/adobe/test/xstr_test/main.cpp?r1=1.1&r2=1.2 Any objections if I re-add these fixes? Thanks Jamie |
|
From: Foster T. B. <fbr...@ad...> - 2005-06-20 20:31:07
|
Hey David, This project escaped a little sooner than we had intended. You're is free to look at it, but we have already changed it to build a "universal" version (i386 + ppc). At some point soon we might want to make things require XCode/gcc4, since the Jamfiles will want to build fat artifacts by default. As for the renaming of the project, it'll most likely get named visual when it's ready for a more official release (1.0.6). Blessings, Foster On Jun 20, 2005, at 09:51a, David Catmull wrote: > Why is the XCode 2.1 version of the visual project called visual2? > If it was to try to avoid a name conflict with the old project, > that's not an issue because the extension is different. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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 |
|
From: David C. <unc...@un...> - 2005-06-20 16:51:50
|
Why is the XCode 2.1 version of the visual project called visual2? If it was to try to avoid a name conflict with the old project, that's not an issue because the extension is different. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Sean P. <sp...@ad...> - 2005-06-14 22:36:03
|
>>> >>> >>>> std::istream::int_type c_int(stream_m->get()); >>>> char c(0); >>>> >>>> c = std::use_facet<std::ctype<wchar_t> >(std::locale()).narrow >>>> (c_int, '?'); >>>> >>>> >>>> >>>> >>> >>> In the cygwin gcc that I have (gcc 3.4.4) I get the following >>> error in the above line of code: >>> >>> >>> >> >> I'm not sure where wchar_t is coming into play given that c is of >> type char. >> >> > > The reason I have to use wchar_t is because narrow's argument is of > type char_type, which in every case but the wchar_t one is just a > char, so narrow is a no-op (it would require a static_cast to fit > the parameter to the argument, at which point narrow is moot). > I understand - this is simply some confusion about how istream::get() works - It returns either a character c or traits::eof() - the reason it returns an int_type is because traits::eof is always out-of-band for the character type (int_type is always larger than char_type). To recover the character use traits::to_char_type(). Sean > > > >> >> >> >>> >>> >>> >>> >>> >>>> Exception: St8bad_cast >>>> >>>> >>>> >>>> >>> >>> Has anyone seen this before? Any ideas of a possible workaround? >>> Anyone know of an easier (yet equally portable) means of >>> narrowing an int_type value from a stream::get()? >>> >>> >>> >> >> char c (stream_m->narrow(c_int, '?')); >> >> > > See above. > > > >> 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 >>> "What 99 percent of programmers need to know is not how to build >>> components but how to use them." -- Alexander Stepanov >>> >>> >>> >>> ------------------------------------------------------- >>> SF.Net email is sponsored by: Discover Easy Linux Migration >>> Strategies >>> from IBM. Find simple to follow Roadmaps, straightforward articles, >>> informative Webcasts and more! Get everything you need to get up to >>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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 > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > |
|
From: Foster T. B. <fbr...@ad...> - 2005-06-14 22:02:16
|
On Jun 14, 2005, at 02:57p, Sean Parent wrote: > > On Jun 14, 2005, at 2:45 PM, Foster T. Brereton wrote: > > >> Hey all, >> >> I have a cygwin-gcc-specific issue with the following chunk of code: >> >> >> >>> std::istream::int_type c_int(stream_m->get()); >>> char c(0); >>> >>> c = std::use_facet<std::ctype<wchar_t> >>> >(std::locale()).narrow(c_int, '?'); >>> >>> >> >> In the cygwin gcc that I have (gcc 3.4.4) I get the following error >> in the above line of code: >> > > I'm not sure where wchar_t is coming into play given that c is of type > char. The reason I have to use wchar_t is because narrow's argument is of type char_type, which in every case but the wchar_t one is just a char, so narrow is a no-op (it would require a static_cast to fit the parameter to the argument, at which point narrow is moot). > >> >> >> >>> Exception: St8bad_cast >>> >>> >> >> Has anyone seen this before? Any ideas of a possible workaround? >> Anyone know of an easier (yet equally portable) means of narrowing an >> int_type value from a stream::get()? >> > > char c (stream_m->narrow(c_int, '?')); See above. > 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 >> "What 99 percent of programmers need to know is not how to build >> components but how to use them." -- Alexander Stepanov >> >> >> >> ------------------------------------------------------- >> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >> from IBM. Find simple to follow Roadmaps, straightforward articles, >> informative Webcasts and more! Get everything you need to get up to >> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&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 |
|
From: Sean P. <sp...@ad...> - 2005-06-14 21:57:26
|
On Jun 14, 2005, at 2:45 PM, Foster T. Brereton wrote: > Hey all, > > I have a cygwin-gcc-specific issue with the following chunk of code: > > > >> std::istream::int_type c_int(stream_m->get()); >> char c(0); >> >> c = std::use_facet<std::ctype<wchar_t> >(std::locale()).narrow >> (c_int, '?'); >> >> > > In the cygwin gcc that I have (gcc 3.4.4) I get the following error > in the above line of code: > I'm not sure where wchar_t is coming into play given that c is of type char. > > > >> Exception: St8bad_cast >> >> > > Has anyone seen this before? Any ideas of a possible workaround? > Anyone know of an easier (yet equally portable) means of narrowing > an int_type value from a stream::get()? > char c (stream_m->narrow(c_int, '?')); 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 > "What 99 percent of programmers need to know is not how to build > components but how to use them." -- Alexander Stepanov > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > |
|
From: Foster T. B. <fbr...@ad...> - 2005-06-14 21:46:05
|
Hey all, I have a cygwin-gcc-specific issue with the following chunk of code: > std::istream::int_type c_int(stream_m->get()); > char c(0); > > c = std::use_facet<std::ctype<wchar_t> >(std::locale()).narrow(c_int, > '?'); In the cygwin gcc that I have (gcc 3.4.4) I get the following error in the above line of code: > Exception: St8bad_cast Has anyone seen this before? Any ideas of a possible workaround? Anyone know of an easier (yet equally portable) means of narrowing an int_type value from a stream::get()? 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 |
|
From: Ralph T. <ra...@gm...> - 2005-06-09 06:38:58
|
Hi List, I've finally had a chance to look at ASL some more. I decided to add resizable windows to the FLTK implementation. I now have layout_m->adjust being called with appropriate values, at the right time, however none of the widgets move (they are all moved to the place they were before). This happens for the resizable examples (like slider_suite) as well as my own GUI... What's going wrong? Thanks, Ralph |
|
From: Sean P. <sp...@ad...> - 2005-06-03 23:54:16
|
I wasn't planning on attending but my calendar is open Monday and Tuesday - so if you want to set something up either of those day's I'll drive up to attend (or take the train!). Sean On Jun 3, 2005, at 4:22 PM, David Catmull wrote: > Anyone going to WWDC? I think it would be interesting to have an > ASL lunch or something. > > -- > David Catmull > unc...@un... > http://www.uncommonplace.com/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can > you shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > |
|
From: David C. <unc...@un...> - 2005-06-03 23:22:54
|
Anyone going to WWDC? I think it would be interesting to have an ASL lunch or something. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Sean P. <sp...@ad...> - 2005-05-31 18:25:50
|
The 1.0.4 release should go out this Thursday, June 2nd. Please take some time this week to clean and polish, address any minor issues you know of that are outstanding. Foster is out today, but I'd like him to compile release notes for this release when he returns, so please send him anything you believe is worth a mention. For anyone who hasn't noticed, the stats are back up on SF - ASL has been consistently in the top 1000 and close to 1000 downloads a month - so I suspect we have quite a few lurkers and silent users out there - if anyone has ideas on how we can do a better job reaching out, I'd love to hear it. We aren't exactly drowning in feedback at the moment - so more would be good. For the developers - if you could drop me a note on why you're interested in ASL, what your plans our, and maybe a little about yourself, it would help me in building the case for Adobe to do more with open source. Thanks! Sean |
|
From: Mat M. <mm...@ad...> - 2005-05-24 18:18:29
|
Some of the issues with char_traits weren't related to the build tools. We fixed a bug where the libraries tried to instantiate a string of unsigned chars. This didn't cause any problems for the compilers whose char is unsigned by default. But for gcc, whose chars are unsigned by default, this caused a link error, since vendors only provide the necessary char_traits explicit specializations for (at most) char and wchar_t. - Mat --On Tuesday, May 24, 2005 7:57 PM +0200 Tobias Schwinger <tsc...@ne...> wrote: > Hello David, > > is this still an issue ? > > Usually, the gcc tools "just know" where to find their default > libraries, unless explicitly told to "forget" (command line option). > AFAIK the "Zero Link" feature of XCode can cause strange errors > like these - are you sure it's entirely disabled ? > > Regards, > > Tobias > > 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 >> >> > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using > Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > > |
|
From: David C. <unc...@un...> - 2005-05-24 18:07:46
|
On May 24, 2005, at 10:57 AM, Tobias Schwinger wrote: > Hello David, > > is this still an issue ? No, it's working now. In the past few days I've been verifying that all new code still builds in XCode, and I haven't had any issues. I still need to make a project for adam_smoke. -- David Catmull unc...@un... http://www.uncommonplace.com/ |
|
From: Tobias S. <tsc...@ne...> - 2005-05-24 17:57:33
|
Hello David, is this still an issue ? Usually, the gcc tools "just know" where to find their default libraries, unless explicitly told to "forget" (command line option). AFAIK the "Zero Link" feature of XCode can cause strange errors like these - are you sure it's entirely disabled ? Regards, Tobias 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 > > |
|
From: Sean P. <sp...@ad...> - 2005-05-17 04:46:43
|
The intension is to move the pieces out to asl as they are ready, alternatively we could move pieces to /future a little sooner. I don't know of anything in visual where the API is quite clean enough that I want it in ASL proper yet (getting there though!). Sean On May 16, 2005, at 5:57 PM, Ralph Thomas wrote: > Is the adobe/test/visual stuff moving? IMO it would be nice to move > libvisual out of test -- it's working well enough in my own code. I > guess we'd probably have to decide on what is public API and what is > private (and ui_core could be private, only accessible through the > factory functions). > > Thanks, > Ralph > > On 5/16/05, Mat Marcus <mm...@ad...> wrote: >> I submitted some substantial changes to the Jamfiles. Some work still >> needs to be done, but the files seem to triggering the right actions >> for visual/test md5/test and all of their dependents. A good test is >> to cd to adove/visual and issue a bjam command--this should cause a >> build of asl_lib_dev, boost_thread, boost_signal, boost_filesystem, >> libvisual and the visual app. >> >> Some of the changes: >> >> 1) Added new Boost Build feature: <asl> with value none or dev. >> Right now <asl>dev simply causes ADOBE_SERIALIZATION to be defined. >> But by setting this to a feature libraries get built in separate >> directories so the adobe/build/Jamfile has been greatly simplified. >> >> 2) Fixed the Jamfile.v2 for boost threads. I am attaching the >> patched file here since it didn't make it into the latest drop. >> >> 3) All targets are built with static linking at the moment. This >> can be fixed, but boost_thread has some complicated requirements in >> this area. >> >> 4) Added a new Jamfile to adobe directory to hold common settings. >> >> >> Projects build successfully with msvc compiler. Some work is needed >> for gcc 3.3 on mac and windows. Other platforms untested. >> Suggestions/improvements very welcome. >> >> > > > ------------------------------------------------------- > 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_idt12&alloc_id344&op=click > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel |
|
From: Sean P. <sp...@ad...> - 2005-05-17 04:44:38
|
These are all STL functions - not sure why they would be missing Rb_tree would be coming from a use of map or multimap (probably the multimap index for xstrings) - list_node would either be std::list or map/multimap. And of course, char_traits would be coming in for basic_string<>. I can't see how you would be missing these - Sean On May 16, 2005, at 5:16 PM, David Catmull wrote: > 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/ > > > > > ------------------------------------------------------- > 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 |
|
From: Sean P. <sp...@ad...> - 2005-05-17 04:38:40
|
Checked in a fairly significant set of mods - it _will_ fix all of these problems (because at least one of each of the conflicting routines here is gone!) - I'm hoping it fixes everything. Foster should roll to CVS soon. Sean On May 16, 2005, at 12:44 PM, David Catmull wrote: > 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/ > > > > ------------------------------------------------------- > 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 |
|
From: Ralph T. <ra...@gm...> - 2005-05-17 02:32:14
|
It looks like it's missing some of boost and the STL (!). Are your XCode projects including Boost.Thread? I don't know why you would be missing STL's char_traits... perhaps you're missing a specialization to a specific character type (GCC's STL only includes char and wchar_t, so if you have a std::basic_string<> of something else then you need to provide a new specialization). Sorry I can't be more help! Ralph On 5/16/05, David Catmull <unc...@un...> wrote: > I get these link errors when I try to build the visual app. With the =20 > way the names are mangled, I can't tell what files I should be =20 > looking for to add to the projects. >=20 > __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 >=20 >=20 > --=20 > David Catmull > unc...@un... > http://www.uncommonplace.com/ >=20 >=20 >=20 > ------------------------------------------------------- > 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=3D7412&alloc_id=3D16344&op=3Dclick > _______________________________________________ > Adobe-source-devel mailing list > Ado...@li... > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel > |
|
From: Ralph T. <ra...@gm...> - 2005-05-17 00:58:13
|
Is the adobe/test/visual stuff moving? IMO it would be nice to move libvisual out of test -- it's working well enough in my own code. I guess we'd probably have to decide on what is public API and what is private (and ui_core could be private, only accessible through the factory functions). Thanks, Ralph On 5/16/05, Mat Marcus <mm...@ad...> wrote: > I submitted some substantial changes to the Jamfiles. Some work still > needs to be done, but the files seem to triggering the right actions > for visual/test md5/test and all of their dependents. A good test is > to cd to adove/visual and issue a bjam command--this should cause a > build of asl_lib_dev, boost_thread, boost_signal, boost_filesystem, > libvisual and the visual app.=20 >=20 > Some of the changes: >=20 > 1) Added new Boost Build feature: <asl> with value none or dev. > Right now <asl>dev simply causes ADOBE_SERIALIZATION to be defined. > But by setting this to a feature libraries get built in separate > directories so the adobe/build/Jamfile has been greatly simplified. >=20 > 2) Fixed the Jamfile.v2 for boost threads. I am attaching the > patched file here since it didn't make it into the latest drop. >=20 > 3) All targets are built with static linking at the moment. This > can be fixed, but boost_thread has some complicated requirements in > this area. >=20 > 4) Added a new Jamfile to adobe directory to hold common settings. >=20 > =20 > Projects build successfully with msvc compiler. Some work is needed > for gcc 3.3 on mac and windows. Other platforms untested. > Suggestions/improvements very welcome. >=20 > |
|
From: Mat M. <mm...@ad...> - 2005-05-17 00:19:02
|
I submitted some substantial changes to the Jamfiles. Some work still needs to be done, but the files seem to triggering the right actions for visual/test md5/test and all of their dependents. A good test is to cd to adove/visual and issue a bjam command--this should cause a build of asl_lib_dev, boost_thread, boost_signal, boost_filesystem, libvisual and the visual app. Some of the changes: 1) Added new Boost Build feature: <asl> with value none or dev. Right now <asl>dev simply causes ADOBE_SERIALIZATION to be defined. But by setting this to a feature libraries get built in separate directories so the adobe/build/Jamfile has been greatly simplified. 2) Fixed the Jamfile.v2 for boost threads. I am attaching the patched file here since it didn't make it into the latest drop. 3) All targets are built with static linking at the moment. This can be fixed, but boost_thread has some complicated requirements in this area. 4) Added a new Jamfile to adobe directory to hold common settings. Projects build successfully with msvc compiler. Some work is needed for gcc 3.3 on mac and windows. Other platforms untested. Suggestions/improvements very welcome. |
2 messages has been excluded from this view by a project administrator.
