adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] Questions about sheet_t::implementation::get

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

Hi cee1,

Welcome! Questions on ASL are always appreciated. I'm not sure which  
version of the code you're referring too, the line numbers don't match  
up with the current release. I'm going to use the latest code from my  
sanbox here:

http://stlab.adobe.com:8080/@lno=y@//sandbox/sparent/adobe_source_libraries/source/adam.cpp?ac=64&rev1=28

On Dec 13, 2009, at 5:17 AM, cee1 wrote:

> Hi all,
> I'm reading the code of adam.cpp, and get totally lost.

It is a bit twisty - I've been slowing working on a rewrite using  
Boost Graph Library - but no ETA on when that will appear.

> In the function sheet_t::implementation_t::get:
> (adam.cpp 1387) "if (initialize_mode_m) { ..."
> I've found initialize_mode_m is false when instantiates  
> sheet_t::implementation_t, and will be true when calls add_constant,  
> add_input or add_interface. So the following assert should always  
> fail:

(line 1435 in my copy) When a sheet is constructed, initializers are  
evaluated as  the cells are added. the get() function is called by the  
expression evaluator to look up variables. The expressions on a sheet  
initializer can only refer to cells that have been previously declared  
(added to the sheet) and the initializers don't attempt to follow  
relationships, they only pick up the cell value of previously  
initialized cells.

> (adam.cpp 1428) assert(cell.interface_input_m && ...),
> Because when this line is reached, the initialize_mode_m is false,  
> then we should not have called add_constant, add_input or  
> add_interface, so the cell is not an interface cell, assert failed.

(line 1476) - there is a return statement on line 1449 so this line is  
not going to be reached if initialize_mode_m is true.
>
> Also, I find some code that makes no sense to me, like:
> (adam.cpp 1267) sheet_t::implementation_t::initialize_one
> accumulate_contributing_m.reset();
> ...
> cell.init_contributing_m |= accumulate_contributing_m;

(1315) accumulate_contributing_m is a member variable that holds a bit  
field corresponding to cells. Executing calculate_m() on line 1323 is  
going to set the bits for the cells that are read as part of that  
expression in accumulate_contributing_m. Then on line 1325 that bit  
set is or'ed with the other bits contributing to the initializer on  
that cell.

>
> or
>
> (adam.cpp  1173) in function sheet_t::implementation_t::update
> if (cell.specifier_m == access_interface_output)  
> get_stack_m.push_back(std::make_pair(cell.name_m, false));

(1221) The get_stack_m is used to detect self-referential expressions  
in get() (which is called as part of calculating an expression for  
variable lookup). For example, if you have a rule like:

a <== max(a, b);

Then the lookup of "a" is self referential, and must refer to the  
initial value of "a", but "b" is not self referential and will refer  
to the final value of "b".

See line 1475 for where this is used.

> ...
> if (cell.specifier_m == access_interface_output)  
> get_stack_m.pop_back();
>
>
> Sorry for this mass mail, but I feel lost in adam.cpp. Could someone  
> show me the global picture of how these functions in  
> sheet_t::implementation work?

No problem - keep the questions coming.

Sean

>
>
> Regards,
> - cee1
> ------------------------------------------------------------------------------
> Return on Information:
> Google Enterprise Search pays you back
> Get the facts.
> http://p.sf.net/sfu/google-dev2dev
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Questions about sheet_t::implementation::get

[cee1 <fy...@gm...>]

Hi all,
I'm reading the code of adam.cpp, and get totally lost.

In the function sheet_t::implementation_t::get:
(adam.cpp 1387) "if (initialize_mode_m) { ..."
I've found initialize_mode_m is false when instantiates
sheet_t::implementation_t, and will be true when calls add_constant,
add_input or add_interface. So the following assert should always fail:
(adam.cpp 1428) assert(cell.interface_input_m && ...),
Because when this line is reached, the initialize_mode_m is false, then we
should not have called add_constant, add_input or add_interface, so the cell
is not an interface cell, assert failed.

Also, I find some code that makes no sense to me, like:
(adam.cpp 1267) sheet_t::implementation_t::initialize_one
accumulate_contributing_m.reset();
...
cell.init_contributing_m |= accumulate_contributing_m;

or

(adam.cpp  1173) in function sheet_t::implementation_t::update
if (cell.specifier_m == access_interface_output)
get_stack_m.push_back(std::make_pair(cell.name_m, false));
...
if (cell.specifier_m == access_interface_output) get_stack_m.pop_back();


Sorry for this mass mail, but I feel lost in adam.cpp. Could someone show me
the global picture of how these functions in sheet_t::implementation work?


Regards,
- cee1

Re: [Adobe-source-devel] Question about code snippet of hash_index

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

The default arguments are defined in the _fwd header. The last  
argument defaults to the capture allocator:

http://stlab.adobe.com:8080/adobe_source_libraries/adobe/closed_hash_fwd.hpp?ac=64&rev1=6

Sean

On Nov 25, 2009, at 5:33 AM, cee1 wrote:

> Hi all,
> I'm trying to learn source code of ASL(1.0.42), and find something  
> strange to me: (I'm not quiet familiar with c++):
>
> (adobe/table_index.hpp, line 555)  typedef closed_hash_set<pointer,  
> indirect_key_function_type, hasher, key_equal>  index_type;
> provide 4 type arguments to template class closed_hash_set, but  
> closed_hash_set(adobe/closed_hash.hpp, line 152) needs 5 type  
> arguments.
>
> Any idea?
>
> Thanks
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Question about code snippet of hash_index

[cee1 <fy...@gm...>]

Hi all,
I'm trying to learn source code of ASL(1.0.42), and find something strange
to me: (I'm not quiet familiar with c++):

(*adobe/table_index.hpp, line 555*)  *typedef closed_hash_set<pointer,
indirect_key_function_type, hasher, key_equal>  index_type;*
provide 4 type arguments to template class closed_hash_set,
but closed_hash_set(*adobe/closed_hash.hpp, line 152*) needs 5 type
arguments.

Any idea?

Thanks

Re: [Adobe-source-devel] What is the status of ASL?

[Ivan Le L. <iva...@fr...>]

> Glad to hear it! I'd like to hear from others on this list - are you
> using ASL? For what?
>
>    

Hello,

I discovered ASL a few months ago.
I'm already using copy_on_write at my job.

Since I discovered ASL, I'm mostly playing with Adam & Eve, which are 
stunning.
I will certainly offer a contribution about Eve and Linux in a few weeks 
(or months ... :-)

By the way, at home, I use premake to build and use the 
"source_libraries" part, under Linux.
It took me something like ten words to integrate it into my personal 
workspace. If ever someone is interested ...

If my experience with A&E remains as enjoyable as it is so far, I will 
strongly consider pushing it at my job next year.
We'll need to rewrite a heavy client. Turning it into a lightweight 
"kind of web-based" app using A&E seems a perfect move.


Well, nothing more than a "hello world, stay tuned" actually, but I did 
not want to miss the draft :-)

Regards,
Ivan.

Re: [Adobe-source-devel] What is the status of ASL?

[Est <es...@fu...>]

Hi Sean

In my case, I'm now using ASL in an open source
node based video compositor.
It's here: http://ramenhdr.sourceforge.net/

I currently use any_regular, the algorithms, dictionary,
copy on write and some others.
I'm learning to use Eve (it's amazing) and poly.

I'd be happy to contribute! I can work on ASL - Qt integration.
My current Qt assemblage is a hack for learning, but I'll rewrite it.

The impressions I had from people regarding ASL were that it was
difficult to build, patching boost, using bjam, ...
I think switching to CMake would be a good idea.

And for gcc 4.3, in closed_hash_map.hpp, at the end of the file, in

mapped_type& operator[](const Key& x)
{
    typename set_type::iterator i = this->find(x);
    if (i == this->end())
	return set_type::insert(adobe::make_pair(x, mapped_type())).first->second;

    return i->second;
}

I had to qualify the call to insert with set_type::, otherwise, gcc 
couldn't find it.

Est.

Re: [Adobe-source-devel] What is the status of ASL?

[Mike M. <mik...@gm...>]

>
> The Adobe Software Technology Lab has been disbanded. Foster is still
> at Adobe, working on Ps. Alex and Paul are also still at Adobe but had
> little direct involvement in ASL (but you might be interested in their
> book, Elements of Programming). Mat left some time ago but still pops
> in to the conversation on occasion. I'm now at Google working on
> ChromeOS.
>
>
That really is a shame. Still I'm glad the project isn't completely
deserted. I've followed it for a long time now and I still feel it has great
potential and would love to see it polished (mostly documentation I think).


- Michael Marcin

Re: [Adobe-source-devel] What is the status of ASL?

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

On Oct 27, 2009, at 5:05 AM, est wrote:

> Hi All!
>
> I've been using ASL for my projects for the last year
> and I'm very happy with it. The libraries are very useful
> and also a great source of inspiration for my own coding.

Glad to hear it! I'd like to hear from others on this list - are you  
using ASL? For what?

>
> I'd like to know what is the status of ASL. The last
> release was some months ago and there is little traffic
> in the mailing lists.

The Adobe Software Technology Lab has been disbanded. Foster is still  
at Adobe, working on Ps. Alex and Paul are also still at Adobe but had  
little direct involvement in ASL (but you might be interested in their  
book, Elements of Programming). Mat left some time ago but still pops  
in to the conversation on occasion. I'm now at Google working on  
ChromeOS.

The Google style guide (adhered to by most of Google) has made it a  
bit difficult for me to spend too much time on ASL.

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Some of the more challenging parts are - limited use of Boost, no  
exception handling, and discouraged copy and assignment. Right now I  
feel like I'm coding with one hand behind my back (I'm also doing a  
lot more on linux these days and bad ergonomic habits for hitting  
command key only with my left thumb have translated to hitting the  
control key with my left thumb and has sparked a carpal tunnel flare  
that makes it painful to type. I'm trying hard now to break 25 years  
of bad habits!)

That said - I have been doing a little work on ASL. If you look in my  
sandbox I just submitted the start of some work for an ABI safe  
function<> and there is some work to clean up some stuff in functional  
as well. I'm also still talking with Jaakko Jarvi about continuing our  
collaboration on property models - there are a number of features in  
for the property model library (Adam) that I think we could get in  
(distribution in relate clauses and even better dependency tracking).

Google lets me pick a project to spend 20% of my time on and whatever  
I choose will likely be ASL related in some form (there are several  
ideas I'm kicking around here, the problem isn't finding an idea it is  
choosing from the many options). I also haven't given up on working  
ASL into my 80% job yet.

> In addition, the library doesn't build
> in linux, gcc 4.3.2 with some trivial changes in closed_map_hash
> and any_regular.

Please contribute! ASL was the most active as a community when Foster  
was able to spend time, umm, fostering the community relationships.  
Community building isn't my suit though I'm looking for ways to re- 
spark interest (like attempting to keep a blog going again). Another  
way to spark ASL development may be to part it out into Boost - I've  
always been supportive of such work it just was never important to the  
STLab charter.

Other suggestions?

> Thank you!

Thank you for your support. The importance of ASL are the ideas behind  
it, without a community those ideas will die and I believe the work is  
too important to let that happen.


>
> Est.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] What is the status of ASL?

[est <es...@fu...>]

Hi All!

I've been using ASL for my projects for the last year
and I'm very happy with it. The libraries are very useful
and also a great source of inspiration for my own coding.

I'd like to know what is the status of ASL. The last
release was some months ago and there is little traffic
in the mailing lists. In addition, the library doesn't build
in linux, gcc 4.3.2 with some trivial changes in closed_map_hash
and any_regular.

Thank you!

Est.

[Adobe-source-devel] asl_1.0.42_net_setup.bat broken

[Mike M. <mik...@gm...>]

It appears that ftp://gd.tuwien.ac.at removed their utils/archivers/curl
directory. This breaks asl_1.0.42_net_setup.bat.
Thanks,

Michael Marcin

Re: [Adobe-source-devel] FW: ASL crash

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

Radar bug is 7082435
(I need to contact someone at at Apple, I still have a wacky set of  
privileges with radar that seem to have me as both an Apple and Adobe  
employee - I can close bugs but only file bugs against special Adobe  
components).

Sean

On Jul 22, 2009, at 10:33 AM, Foster Brereton wrote:

> Excellent -- thanks!
>
> Blessings,
> Foster
>
>
> On 22/07/09 10:05 AM, "Sean Parent" <sea...@ma...> wrote:
>
>> I narrowed it down to the following - clearly a compiler bug. I'll  
>> file a
>> Radar report.
>>
>> Sean
>>
>> ----
>> #include <cassert>
>>
>> namespace {
>>
>> struct empty_base_t { };
>> struct empty_t : empty_base_t { };
>>
>> struct pair_t : empty_t {
>>  empty_t& first() { return *this; }
>>  int& second() { return second_m; }
>>
>>  int second_m;
>> };
>>
>> } // namespace
>>
>> int main () {
>>  pair_t x;
>>
>>  x.second() = 0;
>>  x.first() = empty_t();
>>  assert(x.second() == 0);
>>
>>  return 0;
>> }
>> ----
>> On Jul 21, 2009, at 2:10 PM, Foster Brereton wrote:
>>
>>> FYI -- Sean, any interest in taking a look at this?
>>>
>>> Blessings,
>>> Foster
>>>
>>> ------ Forwarded Message
>>> I have the ASL crash in its own project, 20 lines, crashes in the  
>>> same way -
>>> when stuffing the fourth element into 'aDict':
>>>
>>> #include <adobe/dictionary.hpp>
>>> #include <adobe/name.hpp>
>>>
>>> int main (int argc, char * const argv[]) {
>>>
>>> adobe::dictionary_t aDict;
>>>
>>> adobe::version_1::static_name_t one("one");
>>> adobe::version_1::static_name_t two("two");
>>> adobe::version_1::static_name_t three("three");
>>> adobe::version_1::static_name_t four("four");
>>>
>>> aDict[one].assign((adobe::any_regular_t((double)1.0)));
>>> aDict[two].assign(adobe::any_regular_t((double)2.0));
>>> aDict[three].assign(adobe::any_regular_t((double)3.0));
>>> aDict[four].assign(adobe::any_regular_t((double)4.0));
>>>
>>>
>>>    return 0;
>>> }
>>>
>>> ------ End of Forwarded Message
>>>
>>>
>>>
> -----------------------------------------------------------------------------> 
> >
> -
>>> _______________________________________________
>>> Adobe-source-devel mailing list
>>> Ado...@li...
>>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>>
>
> -- 
> Foster T. Brereton                <ἰχθύς><                Ro  
> 3:21-26
>  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
> "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] FW: ASL crash

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

I narrowed it down to the following - clearly a compiler bug. I'll  
file a Radar report.

Sean

----
#include <cassert>

namespace {

struct empty_base_t { };
struct empty_t : empty_base_t { };

struct pair_t : empty_t {
   empty_t& first() { return *this; }
   int& second() { return second_m; }

   int second_m;
};

} // namespace

int main () {
   pair_t x;

   x.second() = 0;
   x.first() = empty_t();
   assert(x.second() == 0);

   return 0;
}
----
On Jul 21, 2009, at 2:10 PM, Foster Brereton wrote:

> FYI -- Sean, any interest in taking a look at this?
>
> Blessings,
> Foster
>
> ------ Forwarded Message
> I have the ASL crash in its own project, 20 lines, crashes in the  
> same way -
> when stuffing the fourth element into 'aDict':
>
> #include <adobe/dictionary.hpp>
> #include <adobe/name.hpp>
>
> int main (int argc, char * const argv[]) {
>
> adobe::dictionary_t aDict;
>
> adobe::version_1::static_name_t one("one");
> adobe::version_1::static_name_t two("two");
> adobe::version_1::static_name_t three("three");
> adobe::version_1::static_name_t four("four");
>
> aDict[one].assign((adobe::any_regular_t((double)1.0)));
> aDict[two].assign(adobe::any_regular_t((double)2.0));
> aDict[three].assign(adobe::any_regular_t((double)3.0));
> aDict[four].assign(adobe::any_regular_t((double)4.0));
>
>
>    return 0;
> }
>
> ------ End of Forwarded Message
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] FW: ASL crash

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

The failure is in boost::compressed_pair. I was able to reduce the  
test to this:

---
#include <boost/compressed_pair.hpp>

namespace {

struct empty_base_t { };
struct empty_t : empty_base_t { };

typedef boost::compressed_pair<empty_t, int> data_t;

} // namespace

int main () {
   data_t x;

   x.second() = 0;
   x.first() = empty_t();
   assert(x.second() == 0);

   return 0;
}
---

I haven't yet figured out why compressed_pair is failing - but it  
appears to be  a compiler bug.

Sean

On Jul 21, 2009, at 2:10 PM, Foster Brereton wrote:

> FYI -- Sean, any interest in taking a look at this?
>
> Blessings,
> Foster
>
> ------ Forwarded Message
> I have the ASL crash in its own project, 20 lines, crashes in the  
> same way -
> when stuffing the fourth element into 'aDict':
>
> #include <adobe/dictionary.hpp>
> #include <adobe/name.hpp>
>
> int main (int argc, char * const argv[]) {
>
> adobe::dictionary_t aDict;
>
> adobe::version_1::static_name_t one("one");
> adobe::version_1::static_name_t two("two");
> adobe::version_1::static_name_t three("three");
> adobe::version_1::static_name_t four("four");
>
> aDict[one].assign((adobe::any_regular_t((double)1.0)));
> aDict[two].assign(adobe::any_regular_t((double)2.0));
> aDict[three].assign(adobe::any_regular_t((double)3.0));
> aDict[four].assign(adobe::any_regular_t((double)4.0));
>
>
>    return 0;
> }
>
> ------ End of Forwarded Message
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] FW: ASL crash

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

[Update: This works with gcc 4.0 and 4.2; it crashes with llvm-gcc-4.2]

Blessings,
Foster


On 21/07/09 2:10 PM, "Foster Brereton" <fbr...@ad...> wrote:

> FYI -- Sean, any interest in taking a look at this?
> 
> Blessings,
> Foster
> 
> ------ Forwarded Message
> I have the ASL crash in its own project, 20 lines, crashes in the same way -
> when stuffing the fourth element into 'aDict':
> 
> #include <adobe/dictionary.hpp>
> #include <adobe/name.hpp>
> 
> int main (int argc, char * const argv[]) {
> 
> adobe::dictionary_t aDict;
> 
> adobe::version_1::static_name_t one("one");
> adobe::version_1::static_name_t two("two");
> adobe::version_1::static_name_t three("three");
> adobe::version_1::static_name_t four("four");
> 
> aDict[one].assign((adobe::any_regular_t((double)1.0)));
> aDict[two].assign(adobe::any_regular_t((double)2.0));
> aDict[three].assign(adobe::any_regular_t((double)3.0));
> aDict[four].assign(adobe::any_regular_t((double)4.0));
> 
> 
>     return 0;
> }
> 
> ------ End of Forwarded Message
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

-- 
Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] FW: ASL crash

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

FYI -- Sean, any interest in taking a look at this?

Blessings,
Foster

------ Forwarded Message
I have the ASL crash in its own project, 20 lines, crashes in the same way -
when stuffing the fourth element into 'aDict':

#include <adobe/dictionary.hpp>
#include <adobe/name.hpp>

int main (int argc, char * const argv[]) {

adobe::dictionary_t aDict;

adobe::version_1::static_name_t one("one");
adobe::version_1::static_name_t two("two");
adobe::version_1::static_name_t three("three");
adobe::version_1::static_name_t four("four");

aDict[one].assign((adobe::any_regular_t((double)1.0)));
aDict[two].assign(adobe::any_regular_t((double)2.0));
aDict[three].assign(adobe::any_regular_t((double)3.0));
aDict[four].assign(adobe::any_regular_t((double)4.0));


    return 0;
}

------ End of Forwarded Message

[Adobe-source-devel] OSS Usability Evaluation

[Arif R. <ar...@uw...>]

Hi there
 
Please find below a link  to a survey related to my PhD research work to evaluate OSS usability improvement from OSS developer's point of view.
It shall not not take more than 5 minutes of your precious time. 
Your identity is neither required nor recorded. The participation is highly valued and appreciated.
 
http://www.kwiksurveys.com/online-survey.php?surveyID=ILJEM_ba6da4db
 
Thank you and Best Regards
 
Arif Raza

Re: [Adobe-source-devel] Finding resources

[Robert D. <rcd...@gm...>]

On Wed, Jun 3, 2009 at 8:33 PM, Sean Parent <sea...@me...> wrote:

> There certainly needs to be some client code to integrate ASL into a widget
> set - but that could be Win32, WPF, Cocoa, Carbon, GTK, Qt, Flash, HTML, or
> whatever framework you happen to be using. Adobe has their own widget set
> (if you lookup screenshots of our video apps you'll see it in existing
> applications). The layout library and property model libraries are intended
> to be generic components that can be integrated with whatever you are using.
> Kind of like std::vector<> isn't useful unless you supply a type to it.
>
> I hope that folks will share their integrations (maybe Adobe will open
> source their widget library at some point? ).
>
> We backed off from supporting the Win32 and Carbon APIs because MS is
> pushing WPF, Apple is pushing Cocoa, and Adobe chose neither.
>

So you mean to say that out of the box, ASL won't create any widgets? I have
to implement the widgets myself? That could take months, and isn't very
practical. I thought the whole idea behind ASL was to be an alternative to
frameworks like Qt and wxWidgets and provide a way, through a library, to
create GUI applications portably. I'm either still confused or I'm just in a
state of shock.

So just to make sure I get this straight... basically, you're saying that I
do the following to get an app up and running:

   - Download ASL
   - Create a button widget class, and implement it using Win32.
   - Now I can create a button in ASL

If this is true, then ASL's only purpose in that example is to be a
scripting language for widget layout.

And correct me if I'm wrong, but WPF doesn't support C++. So I don't know
what good bringing it up is. Since ASL is in C++, it kind of has to use
Win32 if it plans on supporting Windows UI. I don't see any other choice.

Re: [Adobe-source-devel] Finding resources

[Robert D. <rcd...@gm...>]

On Wed, Jun 3, 2009 at 7:34 PM, Robert Dailey <rcd...@gm...> wrote:

> On Wed, Jun 3, 2009 at 6:58 PM, Sean Parent <sea...@me...> wrote:
>
>> I would object to putting in support for searching above the folder
>> containing the executable - this is a potential security risk (a resource
>> can be replaced/overwritten without write access to the application
>> directory).
>>
>> Copying application resources into a "package" is a good thing.
>
>
>
> Good point. I had always agreed with this, it's just an interesting way of looking at my suggestion. I never thought of how it could be exploited for the worst.
>
>
> I think there is some miscommunication here. When I called the begin app a unit test, that's because I'm referring to the one in //adobe_platform_libraries/test/begin. When I ran this app, it was merely a dialog with a slider and an edit field. Nothing more. It didn't look like a "GUI
> front-end and editor for property model and layout library files
> ". Is there another begin app somewhere I am missing out on? Apologies for my confusion.
>
> There's also another thing I'm fairly confused about. And again, I do
> apologize, as this is getting slightly off topic, but bear with me if you
> would. Let's say that APL goes away, since that essentially seems like what
> it will do eventually. With just ASL around, how can it possibly be
> functional without any widget implementations? For example, if I have an
> interface for a Button widget, but no implementation for it for Windows, no
> button can be created. There needs to be Win32 code at *some level* in order
> for ASL to be even remotely useful. Either that, or the design philosophies
> I've been reading are completely misleading. Some detailed insight into this
> would be really helpful for me. If there are articles I can read, by all
> means please point me in the right direction.
>
> Thanks again to everyone for helping.
>

Update:

I just downloaded the v1.0.42 release of ASL with the begin app for Windows,
and I actually see all of the dialogs now. I understand what you mean now. I
just find it odd that it is in the /test/ directory. I simply assumed those
were for unit/integration tests.

Re: [Adobe-source-devel] Building with BJAM

[Robert D. <rcd...@gm...>]

This is a pretty good idea.
I tried using BOOST_PATH, but BJam didn't pick this up.

I don't want to make any contributions to the BJam scripts, because I'm
currently contributing CMake in hopes that it will replace it.

Thanks for the help guys.

On Wed, Jun 3, 2009 at 6:53 PM, Sean Parent <sea...@me...> wrote:

> I just use symlinks to make the libraries visible where I want if I don't
> want a copy.
>
> Sean
>
>
> On Jun 3, 2009, at 4:33 PM, Foster Brereton wrote:
>
>  Check out adobe_source_libraries/Jamfile.v2... I believe you can set the
>> BOOST_PATH environment variable and it'll use that value instead of the
>> default. I think the Jamfile may need a little tweaking to make the same
>> available for TBB; if you get it working let us know and we'll check it
>> in.
>>
>> Blessings,
>> Foster
>>
>>
>> On 3/06/09 6:49 AM, "Robert Dailey" <rcd...@gm...> wrote:
>>
>>  Hey guys, I can't figure out how to make bjam build ASL without
>>> boost_libraries existing in its typical location. I have boost, but it's
>>> in an
>>> unexpected directory. How can I tell BJAM where to find TBB and Boost
>>> without
>>> changing their location on the filesystem?
>>>
>>
>> --
>> Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
>>  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
>> "What 99 percent of programmers need to know is not how to build
>> components but how to use them." -- Alexander Stepanov
>>
>>
>>
>> ------------------------------------------------------------------------------
>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>> looking to deploy the next generation of Solaris that includes the latest
>> innovations from Sun and the OpenSource community. Download a copy and
>> enjoy capabilities such as Networking, Storage and Virtualization.
>> Go to: http://p.sf.net/sfu/opensolaris-get
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>>
>
>

Re: [Adobe-source-devel] Finding resources

[Robert D. <rcd...@gm...>]

On Wed, Jun 3, 2009 at 6:58 PM, Sean Parent <sea...@me...> wrote:

> I would object to putting in support for searching above the folder
> containing the executable - this is a potential security risk (a resource
> can be replaced/overwritten without write access to the application
> directory).
>
> Copying application resources into a "package" is a good thing.


Good point. I had always agreed with this, it's just an interesting
way of looking at my suggestion. I never thought of how it could be
exploited for the worst.

I think there is some miscommunication here. When I called the begin
app a unit test, that's because I'm referring to the one in
//adobe_platform_libraries/test/begin. When I ran this app, it was
merely a dialog with a slider and an edit field. Nothing more. It
didn't look like a "GUI
front-end and editor for property model and layout library files
". Is there another begin app somewhere I am missing out on? Apologies
for my confusion.

There's also another thing I'm fairly confused about. And again, I do
apologize, as this is getting slightly off topic, but bear with me if you
would. Let's say that APL goes away, since that essentially seems like what
it will do eventually. With just ASL around, how can it possibly be
functional without any widget implementations? For example, if I have an
interface for a Button widget, but no implementation for it for Windows, no
button can be created. There needs to be Win32 code at *some level* in order
for ASL to be even remotely useful. Either that, or the design philosophies
I've been reading are completely misleading. Some detailed insight into this
would be really helpful for me. If there are articles I can read, by all
means please point me in the right direction.

Thanks again to everyone for helping.

Re: [Adobe-source-devel] Building with BJAM

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

Check out adobe_source_libraries/Jamfile.v2... I believe you can set the
BOOST_PATH environment variable and it'll use that value instead of the
default. I think the Jamfile may need a little tweaking to make the same
available for TBB; if you get it working let us know and we'll check it in.

Blessings,
Foster


On 3/06/09 6:49 AM, "Robert Dailey" <rcd...@gm...> wrote:

> Hey guys, I can't figure out how to make bjam build ASL without
> boost_libraries existing in its typical location. I have boost, but it's in an
> unexpected directory. How can I tell BJAM where to find TBB and Boost without
> changing their location on the filesystem?

-- 
Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
"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] Finding resources

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

On 1/06/09 11:32 AM, "Robert Dailey" <rcd...@gm...> wrote:

> On Mon, Jun 1, 2009 at 11:51 AM, Foster Brereton <fbr...@ad...> wrote:
>> 
>> The resource system in APL definitely lacks a more robust design; that being
>> said, it is not used outside of Adobe Begin, so it's limited use has
>> prevented further development of it. If you would like to improve it to
>> better suit your needs, please feel free. How would you specify additional
>> resource directories at the command line for Adobe Begin? The idea is that
>> it's a double-clickable app, so I'm missing something here.
> 
> It is a unit test, correct? If so, it needs to be executed from the command
> line. Any other means of running the unit test, most usually, should be
> unsupported. This includes double-clicks. Unit testing, in my opinion, is
> normally automated through some form, and double clicking will never be
> necessary.

Adobe Begin isn't a unit-test; it is a GUI front-end and editor for property
model and layout library files. As such it doesn't meet the requirements of
a command-line unit test.

>> If the resource directories you are interested in finding (e.g., the working
>> directory or a common a preferences directory) can be derived from the OS
>> (even if it's an OS-specific routine) then I'd think it would be better for
>> the app to discover those directories automatically. There are
>> platform-specific source directories for both Mac and Windows that the
>> resource system would be able to tap into to solve this problem.
> 
> I completely agree. However, I apologize that I did not adequately explain
> what I was trying to say. Basically, this is why I called them "hints". In
> addition to typical assumptions you can make as far as where to search for
> resources (e.g. PATH, working directory, containing directory, etc) you would
> have another concept called "hints". These are user-specific paths that are
> not predictable and thus are specified manually to assist in finding
> resources. It simply gives the resource repository some extra places to look.

Gotcha. That does clear things up as to what you meant.

>> Can you describe a use case where one thread would want a different set of
>> resource directories than another? As for the thread safety issue, it
>> shouldn't be too hard to turn root_path into a threadsafe type.
> 
> It's not that two threads would need a different set of resource directories
> than the other. The issue is more specific than that. If one thread tries to
> update the root directory while another is accessing that, you have your
> classic race condition. It doesn't matter if this use case is practical or
> not, the issue should not exist in general. However, as you've already
> clarified, APL is deprecated and so is this area of code. I am no longer
> concerned with it having this new information.

OK.

>> As I said before, there's no concerted effort going on inside Adobe to
>> improve APL. Occasionally bug fixes will be made and utility code shuffled
>> around to make it more accessible to external sources, but most of it is
>> unused. You're welcome to work out ways of improving it.
> 
> Sorry, this has been a misunderstanding on my part. I was not aware that APL
> was essentially deprecated. I guess in that regard, I'm not really familiar
> with the roadmap for ASL/APL. The fact of the matter is, there will almost
> always be varying implementations for widgets between platforms. Having said
> that, I simply assumed APL represented those variations and would remain
> around for that reason. ASL seems like the abstractions to me (i.e. the widget
> concepts) and APL seems like the implementation of those concepts (i.e. how a
> widget is implemented on Windows or Linux). If this is not the case, I am
> interested in knowing where these implementations will be located in the long
> term.

APL isn't essentially deprecated; it's just that there's no continuing
development effort for the widget implementations therein. Internally Adobe
products have their own widget frameworks we're using instead of APL's set,
and externally there hasn't been any contributor who has stepped up to keep
the APL widget set up to date. The code is still useful as the example it
serves, but I wouldn't recommend relying upon the widget set as
production-level code.

That being said, there is still a lot of other utility code in APL that is
immensely useful, which both internal and external parties to Adobe rely
upon.

> The only reason why I was commenting on the find_resource() method is because
> I was not aware it was deprecated, as I said before. Now that I know, I do not
> feel the need to improve it, since it is moot. It will be removed later on
> anyway. For now, copying the resources will work until APL is completely
> eliminated and a better approach to finding resources becomes available.

The lack of development effort speaks more to the lack of volunteerism than
the quality or longevity of the code. It's not coming out of APL anytime
soon, it's just not being used. You're free to use it, and if you see
improvements you'd like to make to it you're welcome to do so. Our only
requirement at this point is that Adobe Begin and the APL unit tests
continue to compile and run with at least the same level of functionality as
they do now.

> What is the ideal way of locating resources? This seems like something outside
> of the scope of ASL. Is it up to the unit test as to how it wishes to access
> resources? Perhaps ASL asks for an EVE script through the means of an input
> stream? I have a lot to learn in this area. I jumped into CMake not thinking
> that I would have to become so familiar with ASL just yet.

For the unit tests any external information is provided to it via command
line. Adobe Begin is a different beast, as I mentioned before.

Blessings,
Foster


-- 
Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov

[Adobe-source-devel] Building with BJAM

[Robert D. <rcd...@gm...>]

Hey guys, I can't figure out how to make bjam build ASL without
boost_libraries existing in its typical location. I have boost, but it's in
an unexpected directory. How can I tell BJAM where to find TBB and Boost
without changing their location on the filesystem?

Re: [Adobe-source-devel] Finding resources

[Robert D. <rcd...@gm...>]

On Mon, Jun 1, 2009 at 11:51 AM, Foster Brereton <fbr...@ad...> wrote:

>
> The resource system in APL definitely lacks a more robust design; that
> being
> said, it is not used outside of Adobe Begin, so it's limited use has
> prevented further development of it. If you would like to improve it to
> better suit your needs, please feel free. How would you specify additional
> resource directories at the command line for Adobe Begin? The idea is that
> it's a double-clickable app, so I'm missing something here.


It is a unit test, correct? If so, it needs to be executed from the command
line. Any other means of running the unit test, most usually, should be
unsupported. This includes double-clicks. Unit testing, in my opinion, is
normally automated through some form, and double clicking will never be
necessary.


> If the resource directories you are interested in finding (e.g., the
> working
> directory or a common a preferences directory) can be derived from the OS
> (even if it's an OS-specific routine) then I'd think it would be better for
> the app to discover those directories automatically. There are
> platform-specific source directories for both Mac and Windows that the
> resource system would be able to tap into to solve this problem.


I completely agree. However, I apologize that I did not adequately explain
what I was trying to say. Basically, this is why I called them "hints". In
addition to typical assumptions you can make as far as where to search for
resources (e.g. PATH, working directory, containing directory, etc) you
would have another concept called "hints". These are user-specific paths
that are not predictable and thus are specified manually to assist in
finding resources. It simply gives the resource repository some extra places
to look.


> Can you describe a use case where one thread would want a different set of
> resource directories than another? As for the thread safety issue, it
> shouldn't be too hard to turn root_path into a threadsafe type.


It's not that two threads would need a different set of resource directories
than the other. The issue is more specific than that. If one thread tries to
update the root directory while another is accessing that, you have your
classic race condition. It doesn't matter if this use case is practical or
not, the issue should not exist in general. However, as you've already
clarified, APL is deprecated and so is this area of code. I am no longer
concerned with it having this new information.


> As I said before, there's no concerted effort going on inside Adobe to
> improve APL. Occasionally bug fixes will be made and utility code shuffled
> around to make it more accessible to external sources, but most of it is
> unused. You're welcome to work out ways of improving it.


Sorry, this has been a misunderstanding on my part. I was not aware that APL
was essentially deprecated. I guess in that regard, I'm not really familiar
with the roadmap for ASL/APL. The fact of the matter is, there will almost
always be varying implementations for widgets between platforms. Having said
that, I simply assumed APL represented those variations and would remain
around for that reason. ASL seems like the abstractions to me (i.e. the
widget concepts) and APL seems like the implementation of those concepts
(i.e. how a widget is implemented on Windows or Linux). If this is not the
case, I am interested in knowing where these implementations will be located
in the long term.

The only reason why I was commenting on the find_resource() method is
because I was not aware it was deprecated, as I said before. Now that I
know, I do not feel the need to improve it, since it is moot. It will be
removed later on anyway. For now, copying the resources will work until APL
is completely eliminated and a better approach to finding resources becomes
available.

What is the ideal way of locating resources? This seems like something
outside of the scope of ASL. Is it up to the unit test as to how it wishes
to access resources? Perhaps ASL asks for an EVE script through the means of
an input stream? I have a lot to learn in this area. I jumped into CMake not
thinking that I would have to become so familiar with ASL just yet.

Re: [Adobe-source-devel] CMake: Time to talk about requirements

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

On 30/05/09 8:25 PM, "Robert Dailey" <rcd...@gm...> wrote:

> Hey guys,
> 
> I've got a basic and functional first pass on my CMake implementation. I can
> successfully build, link, and run the Begin app, as well as ASL/APL. There's 2
> major steps we need to take from here.

Very cool!

> First, I need some of you guys to review my work so far. If this requires me
> moving my work to the review branch, I will do so. Please give me some
> detailed instruction on this if this is the path I am to take. I need you guys
> to try using CMake to generate the projects. None of you will need to become
> familiar with the CMake language at this point, you'll be working directly
> with the command-line client or the GUI interface (on windows). I want to
> gather opinions on the process, as well as potential suggestions for
> improvement.

Please add portions to the project's documentation regarding how to build
with the CMake scripts.

> Secondly, we need to figure out requirements. Improving the work I've already
> done is of course part of this, but we need to figure out long-term
> requirements, such as unit testing support and extensibility level of the
> scripts for future projects. There is also a particular topic we need to
> discuss. A typical approach to creating CMake scripts is to have a "root"
> CMakeLists.txt file that contains all of the inheritable, reusable code and
> other entities. For example, the root of the Perforce repository would look
> like this in a typical case:
> 
> //CMakeLists.txt
> //cmake/find_modules/FindTBB.cmake
> //adobe_source_libraries/CMakeLists.txt
> //adobe_platform_libraries/CMakeLists.txt
>
> Here, we define all of the reusable cmake functions, macros, and variables in
> CMakeLists.txt, and both ASL and APL CMakeLists.txt simply inherit those, and
> no explicit include() needs to be performed. However, the current structure I
> have is as follows:
> 
> //cmake/common.cmake
> //cmake/find_modules/FindTBB.cmake
> //adobe_source_libraries/CMakeLists.txt
> //adobe_platform_libraries/CMakeLists.txt
> 
> In this case, the root cmake directory still must exist. This cannot be
> removed. There is reusable CMake code that needs to be centralized in a
> location that both ASL and APL can get to, and one level above each of them is
> the best place for it that I know of. However, I've been told that no files
> can exist in the root (//), so I had to create //cmake/common.cmake that each
> of ASL and APL's CMakeLists.txt file must include, which increases the amount
> of boiler plate CMake code in each project-specific cmake script file.
> 
> This is one of the major issues we have to tackle. We, as a group, need to
> figure out what the best long-term hierarchical structure is for CMake. I also
> want to let you guys know that I do have a full time job. What that means to
> you is that I am most active on the weekends. However, this mailing list is
> extremely low traffic and my biggest bottle neck right now is getting feedback
> from the rest of the team. Not to rush, but if you guys could respond more
> often (especially on weekends), I would be able to get a little bit more done.
> I can only do so much work without thorough requirements.

Thanks for all the work you've done so far. I'm most active during the week
(indeed, I'm quite inactive on the weekends as far as work goes :-) ) and
while I can't speak for Sean or Mat I'm sure their situations are similar.
We're definitely not as high bandwidth as we'd like to be, so your patience
is definitely appreciated.

I agree that we need to figure out a good long-term hierarchical structure
for CMake. As I said before it's quite a bit of support to add another depot
for the cmake scripts. We've been successful in integrating the boost build
system into ASL/APL and I'm wondering if a similar solution can be
implemented for the CMake contributions.

Another idea that would be very helpful would be to see what Boost is doing
with CMake (they're developing a parallel build solution to bbv2) and try to
mimic their designs as reasonably as possible. Decisions made by precedent
(especially when the precedent is Boost) tend to have a lot of weight.

Blessings,
Foster


-- 
Foster T. Brereton                <ἰχθύς><                Ro 3:21-26
  Computer Scientist 2 --- Photoshop Engineering --- Adobe Systems
"What 99 percent of programmers need to know is not how to build
components but how to use them." -- Alexander Stepanov