adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] CMake support: Work in Progress

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

Hi Robert,

I'd be happy to set you up with a developer account on our perforce  
server. Before accepting a CMake system I'd want to know what  
complexity it adds and what benefits it provides.

Currently we use bjam because it works with boost, and allows us to  
construct and execute unit tests with a fairly simply, unit tests can  
be specified to compile or fail to compile, or run or fail to run. The  
ability to do both positive and negative test cases are important. We  
minimally maintain the IDE projects largely because I prefer to  
develop in an IDE.

If you're willing to maintain a CMake environment and it provides some  
benefit to the community without too much complexity then we can roll  
it in.

Thanks,
Sean

On May 17, 2009, at 8:47 PM, Robert Dailey wrote:

> Hey guys,
>
> Just letting you know that I have a first pass complete on my CMake  
> build system for Adobe's ASL/APL libraries. Currently, I can  
> successfully generate a visual studio 2008 project using CMake. This  
> project will build a static library of ASL only. I'm currently in  
> the process of writing the logic for APL, which is going to be  
> nearly identical. After that, I need to support the begin app. My  
> goal is to keep the "look and feel" the same as with the checked in  
> visual studio project in msvc_ide.
>
> I'm flying though this pretty quickly, as there really hasn't been  
> much work to do so far. I can compile the library successfully so  
> far with an unpatched version of Boost 1.39 and TBB.
>
> I would like to be able to commit my work to Perforce, but from the  
> little reading I did, contributions are a rather complex process at  
> Adobe. I would rather one of the developers let me know how to  
> contribute my work, if you even want it.
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects_______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] CMake support: Work in Progress

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

Hey guys,
Just letting you know that I have a first pass complete on my CMake build
system for Adobe's ASL/APL libraries. Currently, I can successfully generate
a visual studio 2008 project using CMake. This project will build a static
library of ASL only. I'm currently in the process of writing the logic for
APL, which is going to be nearly identical. After that, I need to support
the begin app. My goal is to keep the "look and feel" the same as with the
checked in visual studio project in msvc_ide.

I'm flying though this pretty quickly, as there really hasn't been much work
to do so far. I can compile the library successfully so far with an
unpatched version of Boost 1.39 and TBB.

I would like to be able to commit my work to Perforce, but from the little
reading I did, contributions are a rather complex process at Adobe. I would
rather one of the developers let me know how to contribute my work, if you
even want it.

Re: [Adobe-source-devel] Interest in ASL

[Mat M. <mat...@em...>]

On Sun, May 10, 2009 at 7:34 PM, Robert Dailey <rcd...@gm...> wrote:
> On Sat, May 9, 2009 at 8:14 PM, Robert Dailey <rcd...@gm...> wrote:
>>
>> On Sat, May 9, 2009 at 10:01 AM, Marshall Clow <mar...@id...> wrote:
>>>
>>> Guys --
>>> I'm really enjoying this conversation, but it's hard to follow only one
>>> side.
>>> Only Sean's posts are showing up on the "Adobe-source-devel" list.
>>
>> Sorry, I was unsubscribed from the list for some reason.
>
> So everything we've discussed so far seems to make sense, and now I need to
> get around to writing a prototype of my own. So far I have two main
> roadblocks:
> First, I need to figure out layouts. I need to figure out things like what
> are all of the parameters possible for every single type of widget you can
> create, as well as any other layout-related functions like "column" and
> "row". I did find a wiki article that seems to discuss this, but the
> formatting of the documentation there is rather weird and doesn't seem very
> thorough. What's the best way to figure out all of this information? In a
> way, layouts and sheets are like their own API's in a different language
> from C++, and having a good reference documentation for these APIs would be
> helpful.
> Secondly, I need to start writing some C++ eventually. I need to figure out
> where the boundary between the Expression language and C++ is, as well as
> the responsibilities of both. Can you recommend some good tutorials or
> example applications that contain both layout, sheets, and C++?
> I expect to
> see small programs that implement things like a simple calculator and can be
> compiled from visual studio and executed for testing.
> Thanks.

Some notes about the tests, examples:

The Adobe Begin application, part of the APL test suite, and also
available as a pre-built binary on sourceforge, comes equipped with a
folder of example layouts/sheet pairs. It supports live editing and
offers a simple peek/poke facility.

There is also an (under-documented) command line application called
property_model_evaluator in the ASL test suite that is meant to
support property model exploration/regression entirely from the
command line. It serves another role too: it is a first step towards a
demonstration of how an application using property models can be
structured. The design involves a parser for an extended property
model expression language together with an associated parser
adam_test_parser.cpp/hpp/_impl.hpp, and a 'queryable' wrapper to the
sheet_t data structure, queryable_sheet.hpp/cpp. It also comes with a
simple, executable property model tutorial pm_tut.pme. Some of the
relevant files can be viewed here:

<http://stlab.adobe.com:8080/@md=d&cd=//adobe_source_libraries/test/&c=wi7@//adobe_source_libraries/test/property_model_eval/?ac=83>

I also had it up and running as a public cgi app, but it's down at the moment.

 - Mat

Re: [Adobe-source-devel] Question about building ASL

[Mat M. <mat...@em...>]

On Sat, May 16, 2009 at 5:00 PM, Robert Dailey <rcd...@gm...> wrote:

> According to the instructions for building ASL, one must restructure the
> libraries in a certain way in order for everything to build correctly. I
> personally am very opposed to this, as it requires renaming and moving my
> other libraries, such as TBB and Boost. If this is currently the only way
> things can be done, then I plan to take the time to configure CMake to build
> ASL and APL.

One should be able to do this with appropriate modifications to the
boost-buildv2 Jamfile.v2s. I spent a little moving n this direction
some time back, but the effort was driven more from a desire for
theoretical path independence than from an actual client request.

My goals/desires are:
>
> Be able to build ASL independently of APL.

This is already the case for the normal developer scenario when
building from the command line.

> When building APL, ASL is a required dependency (if I am understanding
> correctly).

Yes, APL depends on ASL. Under the boost-build system, applications
that depend on APL automatically depend on ASL. I believe this is true
of library artifacts as well as include paths (via the bbv2
usage_requirements facility).


> CMake will configure ASL to build first, and then APL will build after.
> Third party libraries such as boost and TBB (And ASL for APL) are not
> required to be in any specific relative position from the library that
> depends on them.

It was not boost-build that requires TBB and boost to be in a specific
position relative to ASL/APL. It was my limited time/knowledge of how
to write the appropriate Jamfile.v2s.

> They may be in any location on the filesystem. A minor bit
> of configuration will be required in order to tell CMake where to find these
> paths. This configuration can be done on the command-line, which is
> especially useful for automated builds.

For the Adobe use cases, it was important to keep initial
configuration to a minimum. I believe that both sets of use cases can
be accommodated, perhaps by assuming certain relative paths by
default, while also allowing user-configuration/overrides.

> Once such a system is set up, I would expect the ASL and APL root
> directories to contain names consistent with linux library naming
> conventions. For example, a library with a tarfile like this:
>
> fubar_1.0.41.tar.gz
>
> would extract into a directory like this:
>
> fubar_1.0.41
>
> Currently, asl_1.0.41.tgz extracts into "source_release", which is
> unsatisfactory

Yes, it would be good to improve the current naming conventions--they
are an unfortunate artifact of the brittleness of the current
net-install scripts.

>
> I will await word back from someone on the ASL/APL project (more
> specifically, Sean) before delving into this work. I want to make sure that
> the build method for ASL/APL is more flexible than it appears.
It sounds like most of what  you want can be accomadated under the
develpoer scenario by improving the boost-build Jamfile.v2s for the
project. This is not to say that a port from bbv2 to CMake wouldn't be
an eventual improvement to ASL. But I expect that I won't want to make
that switch until boost officially does.

> Thanks for reading. Please respond back soon!

Thanks for your interest and questions.

 - Mat

Re: [Adobe-source-devel] Question about building ASL

[Mat M. <mat...@em...>]

On Fri, May 15, 2009 at 7:17 PM, Robert Dailey <rcd...@gm...> wrote:
> Hey guys,
> First of all I just want to say that I'm currently in the process of writing
> a Python 3.0 script that will download and build ASL and all of its
> dependencies. There are 2 reasons why I am doing this. First, this is a
> great learning experience for me and will allow me to learn about how ASL is
> built. Secondly, there is no true portable solution to automating the build
> and installation of ASL (There is a batch file for windows and shell script
> for linux, but this is a maintenance burden and still not portable enough).

Thanks for your interest in contributing to ASL. You are correct that
there is currently not portable way to download and build ASL/APL. The
shell scripts for mac/linux/win were cobbled together to give a one
step "build it once" solution for those who only want to try out the
demo applications, or perhaps look over the source code, while
requiring minimal tool support (e.g. tar not even required). The
current solution for developers is somewhat different--developers are
expected to grab sources from perforce, then to issue a command to the
cross-platform boost-build-v2 system.  While it might make sense to
work on the python script you suggest, it would probably be easiest if
you spent some time building using the boost-build files for this
project first.

> Before I get started too deep into this, I want to make sure that the
> documentation for building ASL is up-to-date and fully and accurately
> explains how to build ASL. If there are any instructions that are out of
> date and incorrect, please let me know. Second of all, I need to make sure
> that I can use TBB without any patches. I've already verified that I can use
> Boost without patching it.

 It's good to hear that the bug reports and patches that we submitted
to boost are getting folded in to updated versions of boost.

> I am very opposed to patching third party
> libraries for the sake of ASL.

The only reasons for patching either TBB or boost version were to
correct bugs or compiler errors that were causing those libraries to
fail. The patches were in no way ASL-specific.

> Help is appreciated. Thank you.

Thanks for your interest.

[Adobe-source-devel] Problem with perforce updates

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

Hey guys,
I'm currently using P4V to do checkouts of the source libraries, and when I
do an update I get the following errors:

*p4 sync //guest_stlab.adobe.com_10666_1/...#head*
*    4 files added*
*    4 errors reported*
*    Librarian checkout
review/adobe/adobe/future/source/win32/number_formatter_platform_data.cpp
failed.*
*    open for read:
review/adobe/adobe/future/source/win32/number_formatter_platform_data.cpp,v:
No such file or directory*
*    Librarian checkout
review/adobe/adobe/future/source/win32/number_formatter_platform_data.cpp
failed.*
*    open for read:
review/adobe/adobe/future/source/win32/number_formatter_platform_data.cpp,v:
No such file or directory*
*    Librarian checkout
review/adobe/adobe/future/source/win32/number_formatter_platform_data.cpp
failed.*
*    open for read:
review/adobe/adobe/future/source/win32/number_formatter_platform_data.cpp,v:
No such file or directory*
*    can't create directory for
D:/IT/perforce/asl/guest_stlab.adobe.com_10666_1\spec\client\C:\Users\Chris\Documents\AdobeGallery.p4s
*
*    mkdir: D:/IT/perforce/asl/guest_stlab.adobe.com_10666_1\spec\client\C::
The filename, directory name, or volume label syntax is incorrect.*

I'm not sure what to do about this. It looks like someone has absolute paths
checked in for a few things.

Re: [Adobe-source-devel] Question about building ASL

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

On Fri, May 15, 2009 at 9:17 PM, Robert Dailey <rcd...@gm...> wrote:

> Hey guys,
> First of all I just want to say that I'm currently in the process of
> writing a Python 3.0 script that will download and build ASL and all of its
> dependencies. There are 2 reasons why I am doing this. First, this is a
> great learning experience for me and will allow me to learn about how ASL is
> built. Secondly, there is no true portable solution to automating the build
> and installation of ASL (There is a batch file for windows and shell script
> for linux, but this is a maintenance burden and still not portable enough).
>
> Before I get started too deep into this, I want to make sure that the
> documentation for building ASL is up-to-date and fully and accurately
> explains how to build ASL. If there are any instructions that are out of
> date and incorrect, please let me know. Second of all, I need to make sure
> that I can use TBB without any patches. I've already verified that I can use
> Boost without patching it. I am very opposed to patching third party
> libraries for the sake of ASL.
>
> Help is appreciated. Thank you.
>

According to the instructions for building ASL, one must restructure the
libraries in a certain way in order for everything to build correctly. I
personally am very opposed to this, as it requires renaming and moving my
other libraries, such as TBB and Boost. If this is currently the only way
things can be done, then I plan to take the time to configure CMake to build
ASL and APL. My goals/desires are:

   - Be able to build ASL independently of APL.
   - When building APL, ASL is a required dependency (if I am understanding
   correctly). CMake will configure ASL to build first, and then APL will build
   after.
   - Third party libraries such as boost and TBB (And ASL for APL) are not
   required to be in any specific relative position from the library that
   depends on them. They may be in any location on the filesystem. A minor bit
   of configuration will be required in order to tell CMake where to find these
   paths. This configuration can be done on the command-line, which is
   especially useful for automated builds.
   - Once such a system is set up, I would expect the ASL and APL root
   directories to contain names consistent with linux library naming
   conventions. For example, a library with a tarfile like this:

   fubar_1.0.41.tar.gz

   would extract into a directory like this:

   fubar_1.0.41

   Currently, asl_1.0.41.tgz extracts into "source_release", which is
   unsatisfactory

I will await word back from someone on the ASL/APL project (more
specifically, Sean) before delving into this work. I want to make sure that
the build method for ASL/APL is more flexible than it appears.

Thanks for reading. Please respond back soon!

[Adobe-source-devel] Question about building ASL

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

Hey guys,
First of all I just want to say that I'm currently in the process of writing
a Python 3.0 script that will download and build ASL and all of its
dependencies. There are 2 reasons why I am doing this. First, this is a
great learning experience for me and will allow me to learn about how ASL is
built. Secondly, there is no true portable solution to automating the build
and installation of ASL (There is a batch file for windows and shell script
for linux, but this is a maintenance burden and still not portable enough).

Before I get started too deep into this, I want to make sure that the
documentation for building ASL is up-to-date and fully and accurately
explains how to build ASL. If there are any instructions that are out of
date and incorrect, please let me know. Second of all, I need to make sure
that I can use TBB without any patches. I've already verified that I can use
Boost without patching it. I am very opposed to patching third party
libraries for the sake of ASL.

Help is appreciated. Thank you.

Re: [Adobe-source-devel] Subversion

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

Hi Robert,

We have considered Subversion. The reason we use Perforce is much the  
same as why you want subversion. Adobe uses Perforce internally, and  
we have over 50 projects internally using ASL - we're able to setup  
the stlab server as a remote to an internal server.

Last I looked, there just weren't decent p4<->svn tools. Initially we  
were using cvs externally but managing the integrations was too time  
consuming. If you know of any good tools, let us know. I think using  
svn would raise our external visibility and adoption.

Sean

On May 13, 2009, at 5:14 PM, Robert Dailey wrote:

> Have you guys given any thought to using Subversion 1.6.2 (Current  
> version as of this writing) instead of Perforce for version control?  
> There are several reasons why I ask, some having to do with my  
> personal bias towards SVN, but mostly because it would be helpful to  
> create an external link to the ASL repository from my own subversion  
> repository. This way I can always make sure I have the latest  
> version of ASL when I update my own project.

[Adobe-source-devel] Subversion

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

Have you guys given any thought to using Subversion 1.6.2 (Current version
as of this writing) instead of Perforce for version control? There are
several reasons why I ask, some having to do with my personal bias towards
SVN, but mostly because it would be helpful to create an external link to
the ASL repository from my own subversion repository. This way I can always
make sure I have the latest version of ASL when I update my own project.

Re: [Adobe-source-devel] Interest in ASL

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

On Sunday, May 10, 2009, at 07:34PM, "Robert Dailey"  
<rcd...@gm...> wrote:

> First, I need to figure out layouts. I need to figure out things  
> like what
> are all of the parameters possible for every single type of widget  
> you can
> create, as well as any other layout-related functions like "column"  
> and
> "row". I did find a wiki
> article<http://stlab.adobe.com/wiki/index.php/Layout_Terminology>that
> seems to discuss this, but the formatting of the documentation there
> is
> rather weird and doesn't seem very thorough. What's the best way to  
> figure
> out all of this information? In a way, layouts and sheets are like  
> their own
> API's in a different language from C++, and having a good reference
> documentation for these APIs would be helpful.

That document should be reasonably complete. The layout language has  
very few built in constructs (it doesn't know what a button is) - the  
terminology comes from the binding to the widget set. The layout  
terminology page is intended to keep the clients of the layout library  
consistent.

> Secondly, I need to start writing some C++ eventually. I need to  
> figure out
> where the boundary between the Expression language and C++ is, as  
> well as
> the responsibilities of both. Can you recommend some good tutorials or
> example applications that contain both layout, sheets, and C++? I  
> expect to
> see small programs that implement things like a simple calculator  
> and can be
> compiled from visual studio and executed for testing.

We have lots of test cases - but except for Begin I think they are all  
UI-less. The simplest way to create a working app is to call  
handle_dialog(),

http://stlab.adobe.com/group__modal__dialog__kit.html

Sean


>
> Thanks.

Re: [Adobe-source-devel] ASL & Boost

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

We have various internal departments still building with 1.38 and even 1.37.
In both cases there are some warnings but nothing significant.

Blessings,
Foster 


On 10/05/09 3:48 PM, "Sean Parent" <sea...@ma...> wrote:

> I'm currently running with boost 1.39 - without patches there is a single
> warning (a minor problem with the boost file system). This is on Mac OS.
> 
> <http://stlab.adobe.com/wiki/index.php/About_Boost_Patches>
> 
> Sean
> 
> On Sunday, May 10, 2009, at 11:19AM, "Robert Dailey" <rcd...@gm...>
> wrote:
>> Hi,
>> Is it possible to use ASL with either Boost 1.38 or Boost 1.39? I would like
>> to avoid using a patched version of boost, because that complicates my
>> project. Currently I use Boost 1.38, and if ASL uses its own patched
>> version, that means I have to keep 2 versions of boost around, and that is a
>> bit error prone.
>> 
> 
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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] List View / Tree View with ASL

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

APL is a place to vet libraries for ASL.

All the widget code is in APL. APL depends on ASL but ASL has no dependencies on APL.


--
Sent from my Centro.
sea...@ma...
-----Original Message-----
From: Robert Dailey <rcd...@gm...>
Date: Monday, May 11, 2009 8:40 am
Subject: Re: [Adobe-source-devel] List View / Tree View with ASL
To: Sean Parent <sea...@ma...>
CC: ado...@li...

On Mon, May 11, 2009 at 10:23 AM, Sean Parent <sea...@ma...> wrote:
> The seperation between the two libraries is somewhat arbitrary. When Foster moved on from STLab to work on Photoshop, Mat and I decided to reduce the scope of the project. ASL is loosly everything needed for the property model and layout libraries and a small number of other items that where finished or nearly so. APL is everything else - though the bulk of it is the platform widget library (hence the name). The plan has been to focus on completing ASL (good docs, test cases, tutorials). If items in APL get completed we'll roll them into ASL - and we may still kick a library or two back to APL in the nterest of making ASL a completed body of work. 
>
>
>So it sounds like APL is a test-bed for ASL? The widget implementations, such as buttons and static text, are only in APL, right? I didn't see any widget implementations in ASL. So they must share source code between each other. I'm assuming ASL has a dependency on some of APL's source code for this reason.  

Re: [Adobe-source-devel] List View / Tree View with ASL

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

On Mon, May 11, 2009 at 10:23 AM, Sean Parent <sea...@ma...> wrote:

> The seperation between the two libraries is somewhat arbitrary. When Foster
> moved on from STLab to work on Photoshop, Mat and I decided to reduce the
> scope of the project. ASL is loosly everything needed for the property model
> and layout libraries and a small number of other items that where finished
> or nearly so. APL is everything else - though the bulk of it is the platform
> widget library (hence the name). The plan has been to focus on completing
> ASL (good docs, test cases, tutorials). If items in APL get completed we'll
> roll them into ASL - and we may still kick a library or two back to APL in
> the nterest of making ASL a completed body of work.


So it sounds like APL is a test-bed for ASL? The widget implementations,
such as buttons and static text, are only in APL, right? I didn't see any
widget implementations in ASL. So they must share source code between each
other. I'm assuming ASL has a dependency on some of APL's source code for
this reason.

Re: [Adobe-source-devel] List View / Tree View with ASL

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

The seperation between the two libraries is somewhat arbitrary. When Foster moved on from STLab to work on Photoshop, Mat and I decided to reduce the scope of the project. ASL is loosly everything needed for the property model and layout libraries and a small number of other items that where finished or nearly so. APL is everything else - though the bulk of it is the platform widget library (hence the name). The plan has been to focus on completing ASL (good docs, test cases, tutorials). If items in APL get completed we'll roll them into ASL - and we may still kick a library or two back to APL in the nterest of making ASL a completed body of work.

Sean

Sent from my Centro.
sea...@ma...
-----Original Message-----
From: Robert Dailey <rcd...@gm...>
Date: Monday, May 11, 2009 7:14 am
Subject: Re: [Adobe-source-devel] List View / Tree View with ASL
To: Sean Parent <sea...@ma...>
CC: "asl [dev]" <ado...@li...>

On Sun, May 10, 2009 at 5:58 PM, Sean Parent <sea...@ma...> wrote:
> Here is the history of the widgets in the platform library:
>
> They started life as part of the Begin test app - just a thin shim between ASL and the Mac OS Carbon platform widgets.
> One of our contributors ported Begin to Windows and we decided to go through the effort to clean up the widgets and make them 'real.'
> Then Apple dropped Carbon for 64 bit, and Microsoft moved away from Win32 in favor of WPF. Adobe decided not to follow either and invest in our own framework (you can see it in our video products).
>
> None of the Adobe contributors can afford the bandwidth to really do a good job with the widgets, so we just keep them alive for testing.
>
> You are correct that there is no list/tree view. The property model library (Adam) doesn't deal with sequence manipulation so it wasn't needed for that. Foster has been doing work on a sequence model library (which is in APL) and is getting some use with our internal list widget. He may be able to comment further.
>
> The 'future' directory was created when we were looking to make the widgets 'real' and before we split the library into ASL and APL. I'd love to clean up the directory structure in APL but haven't had the time (my time, when I have it, is on the ASL side). Feel free to jump in an help! 
>
>
>Thanks for taking the time to explain this. It really makes sense now. Once I get more familiar with ASL/APL and how to build it/use it, I will most certainly want to help contribute. This is unrelated, but what is the difference between the Adobe Platform Libraries and the Adobe Source Libraries? Right now it seems like ASL contains the abstractions, and APL contains the implementations for those abstractions for each platform. Correct me if I am wrong.   

Re: [Adobe-source-devel] List View / Tree View with ASL

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

On Sun, May 10, 2009 at 5:58 PM, Sean Parent <sea...@ma...> wrote:

> Here is the history of the widgets in the platform library:
>
> They started life as part of the Begin test app - just a thin shim between
> ASL and the Mac OS Carbon platform widgets.
> One of our contributors ported Begin to Windows and we decided to go
> through the effort to clean up the widgets and make them "real."
> Then Apple dropped Carbon for 64 bit, and Microsoft moved away from Win32
> in favor of WPF. Adobe decided not to follow either and invest in our own
> framework (you can see it in our video products).
>
> None of the Adobe contributors can afford the bandwidth to really do a good
> job with the widgets, so we just keep them alive for testing.
>
> You are correct that there is no list/tree view. The property model library
> (Adam) doesn't deal with sequence manipulation so it wasn't needed for that.
> Foster has been doing work on a sequence model library (which is in APL) and
> is getting some use with our internal list widget. He may be able to comment
> further.
>
> The "future" directory was created when we were looking to make the widgets
> "real" and before we split the library into ASL and APL. I'd love to clean
> up the directory structure in APL but haven't had the time (my time, when I
> have it, is on the ASL side). Feel free to jump in an help!


Thanks for taking the time to explain this. It really makes sense now. Once
I get more familiar with ASL/APL and how to build it/use it, I will most
certainly want to help contribute. This is unrelated, but what is the
difference between the Adobe Platform Libraries and the Adobe Source
Libraries? Right now it seems like ASL contains the abstractions, and APL
contains the implementations for those abstractions for each platform.
Correct me if I am wrong.

Re: [Adobe-source-devel] Interest in ASL

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

On Sat, May 9, 2009 at 8:14 PM, Robert Dailey <rcd...@gm...> wrote:

> On Sat, May 9, 2009 at 10:01 AM, Marshall Clow <mar...@id...> wrote:
>
>> Guys --
>>
>> I'm really enjoying this conversation, but it's hard to follow only one
>> side.
>> Only Sean's posts are showing up on the "Adobe-source-devel" list.
>
>
> Sorry, I was unsubscribed from the list for some reason.
>

So everything we've discussed so far seems to make sense, and now I need to
get around to writing a prototype of my own. So far I have two main
roadblocks:

First, I need to figure out layouts. I need to figure out things like what
are all of the parameters possible for every single type of widget you can
create, as well as any other layout-related functions like "column" and
"row". I did find a wiki
article<http://stlab.adobe.com/wiki/index.php/Layout_Terminology>that
seems to discuss this, but the formatting of the documentation there
is
rather weird and doesn't seem very thorough. What's the best way to figure
out all of this information? In a way, layouts and sheets are like their own
API's in a different language from C++, and having a good reference
documentation for these APIs would be helpful.

Secondly, I need to start writing some C++ eventually. I need to figure out
where the boundary between the Expression language and C++ is, as well as
the responsibilities of both. Can you recommend some good tutorials or
example applications that contain both layout, sheets, and C++? I expect to
see small programs that implement things like a simple calculator and can be
compiled from visual studio and executed for testing.

Thanks.

Re: [Adobe-source-devel] List View / Tree View with ASL

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

Here is the history of the widgets in the platform library:

They started life as part of the Begin test app - just a thin shim between ASL and the Mac OS Carbon platform widgets.
One of our contributors ported Begin to Windows and we decided to go through the effort to clean up the widgets and make them "real."
Then Apple dropped Carbon for 64 bit, and Microsoft moved away from Win32 in favor of WPF. Adobe decided not to follow either and invest in our own framework (you can see it in our video products).

None of the Adobe contributors can afford the bandwidth to really do a good job with the widgets, so we just keep them alive for testing.

You are correct that there is no list/tree view. The property model library (Adam) doesn't deal with sequence manipulation so it wasn't needed for that. Foster has been doing work on a sequence model library (which is in APL) and is getting some use with our internal list widget. He may be able to comment further.

The "future" directory was created when we were looking to make the widgets "real" and before we split the library into ASL and APL. I'd love to clean up the directory structure in APL but haven't had the time (my time, when I have it, is on the ASL side). Feel free to jump in an help!

Sean

 
On Sunday, May 10, 2009, at 11:18AM, "Robert Dailey" <rcd...@gm...> wrote:
>I've been reading through the documentation and I've found various widget
>types under the platform library. I don't fully understand ASL yet nor how
>widgets are created and accessed from C++, but I didn't see a List/Tree view
>widget. Unfortunately, I'm pretty confused because the same widgets (Button,
>for example) seem to be in different locations in the Perforce repository.
>There's one for each platform, which is fine, but then there's some under
>'future', and other confusingly named directories.
>
>What I would like to know is if ASL currently has support for a list/tree
>view widget on the Windows platform. If so, where can I read more about this
>widget? Secondly, what does the 'future' directory mean? Why are there so
>many copies of the same widget source files scattered around the place? Some
>copies don't even seem to be related to a specific platform.
>
>Thanks.
>

Re: [Adobe-source-devel] ASL & Boost

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

I'm currently running with boost 1.39 - without patches there is a single warning (a minor problem with the boost file system). This is on Mac OS.

<http://stlab.adobe.com/wiki/index.php/About_Boost_Patches>

Sean
 
On Sunday, May 10, 2009, at 11:19AM, "Robert Dailey" <rcd...@gm...> wrote:
>Hi,
>Is it possible to use ASL with either Boost 1.38 or Boost 1.39? I would like
>to avoid using a patched version of boost, because that complicates my
>project. Currently I use Boost 1.38, and if ASL uses its own patched
>version, that means I have to keep 2 versions of boost around, and that is a
>bit error prone.
>

[Adobe-source-devel] ASL & Boost

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

Hi,
Is it possible to use ASL with either Boost 1.38 or Boost 1.39? I would like
to avoid using a patched version of boost, because that complicates my
project. Currently I use Boost 1.38, and if ASL uses its own patched
version, that means I have to keep 2 versions of boost around, and that is a
bit error prone.

[Adobe-source-devel] List View / Tree View with ASL

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

I've been reading through the documentation and I've found various widget
types under the platform library. I don't fully understand ASL yet nor how
widgets are created and accessed from C++, but I didn't see a List/Tree view
widget. Unfortunately, I'm pretty confused because the same widgets (Button,
for example) seem to be in different locations in the Perforce repository.
There's one for each platform, which is fine, but then there's some under
'future', and other confusingly named directories.

What I would like to know is if ASL currently has support for a list/tree
view widget on the Windows platform. If so, where can I read more about this
widget? Secondly, what does the 'future' directory mean? Why are there so
many copies of the same widget source files scattered around the place? Some
copies don't even seem to be related to a specific platform.

Thanks.

Re: [Adobe-source-devel] Interest in ASL

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

On Sat, May 9, 2009 at 10:01 AM, Marshall Clow <mar...@id...> wrote:

> Guys --
>
> I'm really enjoying this conversation, but it's hard to follow only one
> side.
> Only Sean's posts are showing up on the "Adobe-source-devel" list.


Sorry, I was unsubscribed from the list for some reason.

Re: [Adobe-source-devel] Interest in ASL

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

[sorry for the ugly quoting - struggling with webmail for a bit.]

>>>
I'm struggling with this, but let me see if I have this down. It seems like a relate clause requires all variables inside of it to be infinitely recursive. For example, if I have 4 variables in my relate clause, then each variable must have a define expression that uses the other 3. So I couldn't do something like this:

relate
{
  a <== b + 1
  b <== a
}

Correct?
<<<

You could say that (with semi-colons) - but I don't know what the relationship means. Normally the functions are some form of an inverse of the other functions - so if you wanted to express "a = b + 1" it would be:

relate {
  a <== b + 1;
  b <== a - 1;
}

>>>
In the above example, if 'a' is prioritized because 'b' changed, then the value of 'b' will be 'out of date', because B should always equal A. In order for the above to be true, you would have to change 'b', have the relate clause update 'a' (because 'b' changed), and then it would have to update 'b' again with the new value of a (which should be one greater than its previous value).
<<<

Your example restated in english would be "there is a relationship between a and be which is satisfied if a = b + 1 or a = b"

>>>
I'm also assuming you *must* use define expressions in a relate clause. I don't see the point of using initializers, like this:

relate
{
  a : 90;
  b : 40;
}
<<<

That would be a syntax error. Yes - you must use define expressions.

>>>
I think if you gave me a more practical example then I would understand the purpose of the relate clause. So far we've been giving overly simple logical examples, but I've not really seen a case where it makes sense to use a relate clause. It would help to see a case that would otherwise not be possible to implement without the existence of the relate clause.
<<<

Generally what you describe in a sheet are the arguments to some function (or command) which are being represented in the UI. You build a model of the function, capturing the pre-condition to the function (so the user can't invoke the function with bad arguments), you can also model properties of the post condition, so the user can describe the desired result (I want my compressed file to fit on a CD, you figure out the compression ratio), and values which are defined in terms of the argument (for example, a function takes a "force" argument, the definition of force is force = mass * acceleration, so you can model this definition and the user can then provide the force argument directly, or in terms of mass and acceleration).

The relationship "width_in_inches = width_in_pixels / pixels_per_inch" is expressed as:

relate {
    width_in_inches <== width_in_pixels / pixels_per_inch;
    pixels_per_inch <== width_in_pixels / width_in_inches;
    width_in_pixels <== width_in_inches * pixels_per_inch;
}

You could attach a UI to this with 3 numbers, edit any two and the third is derived. If the resolution where fixed, then simply drop the second term in the relationship. Then you have a two way relationship between width_in_inches and width_in_pixels.

The most common relationships are just linear scalings of each other. The example with rotation (a,b and x,y) was developed as an example of how to express relationships between different colorspaces (RGB, CMYK, Lab, etc...).

Let's say you want to write a video compression app and you want to build a UI to express all the dials, you might let the user select a desired final size, a frame rate, a frame size, video length, and a compression ration. If you can write the expressions to relate these variables, then you can specify the relate clause and attach your UI to it. Let's say we only let the user adjust the compression ratio or the final size. The relationship might be:

relate {
    final_size <== frame_rate * frame_size * video_length * compression_ratio;
    compression_ratio <== final_size / (frame_rate * frame_size * video_length);
}

Often times you end up with relate clauses that overlap. For example, in the image size example you have width and hight related to a percentage of the original document width and height, and you have a conditional relation to constrain proportions which ensures that these percentages are equal - so you have:

relate {
     width_percent <== width / width_original;
     width <== width_percent * width_original;
}

relate {
     height_percent <== height / height_original;
     height<== height_percent * height_original;
}

when (constrain) relate {
     height_percent <== width_percent;
     width_percent <== height_percent;
}

I hope those examples help...

Sean

Re: [Adobe-source-devel] Interest in ASL

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

On May 8, 2009, at 3:18 PM, Robert Dailey wrote:
>
>
> I understand the while() part, but what about when the condition for  
> the relate clause is left out? For example, just relate { ... }. I  
> guess this:
>
> relate
> {
>    ...
> }
>
> Is the same as saying:
>
> while (true) relate
> {
>    ....
> }
>
> Is this correct?

Yes.

> Also, is the "most recently set" factor the only thing that  
> determines priority?

Initialization determines initial priority - cells declared later with  
initializers have higher priority then those declared earlier.

> The whole priority system doesn't make full sense to me. What if you  
> try to access the variable 'y', when only X has been updated? In  
> your example, Y would be exactly the same, but what if Y had a more  
> complex define expression? I can see cases where Y would not have to  
> equal X in a relate clause.

Give an example? relate clauses can capture fairly complex  
relationships. Some examples. The relation x = y * z is:

relate {
	x <== y * z;
	y <== x / z;
	z <== x / y;
}

You can express in-equalities using min and max. For example, the  
relation x <= y is:

relate {
	x <== min(x, y);
	y <== max(x, y);
}

If you need to handle relationships that require simultaneous  
solutions for multiple variables, you can do this by first relating  
the single variable to an array, and then relating the arrays  
(eventually there will be a notation to do this without first doing  
the grouping). For example,  the relationship [a, b] and [x, y] are  
coordinates where [a, b] = rotate([x, y], 45 deg) is:

  /*
     We need to relate the individual cells to the pairs.
  */

	relate {
		a  <== ab[0];
		ab <== [a, ab[1]];
	}
	relate {
		b  <== ab[1];
		ab <== [ab[0], b];
	}
	relate {
		x  <== xy[0];
		xy <== [x, xy[1]];
	}
	relate {
		y  <== xy[1];
		xy <== [xy[0], y];
	}
	
   /*
     Finally, we have a relationship which specifies the rotation.
   */
	relate {
	    ab <== [x * 0.71 - y * 0.71, x * 0.71 + y * 0.71];
	    xy <== [a * 0.71 + b * 0.71, b * 0.71 - a * 0.71];
	}

---

> I guess you can't really execute all expressions at once inside of  
> the relate clause or else you run into the infinite recursion issue  
> you talked about.

Correct - a relate clause will always execute exactly one term - if  
the priorities are not unique (usually they are) then which term is  
executed is undefined.
>
> Thanks for all of your help. I think my next step is to tackle the  
> examples. I'll post back with any questions I have after I review  
> the examples for a while.

Sean

Re: [Adobe-source-devel] Interest in ASL

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

On May 7, 2009, at 8:11 PM, Robert Dailey wrote:

> By default, if you don't provide an defines operator on an interface  
> cell, it is defined to be the identity - the above is equivalent to:
>
> interface_cell : input_cell <== interface_cell;
>
> So by your explanation, an interface cell can be both set with  
> sheet_t::set() and obtained via sheet_t::monitor_value()? Since the  
> value of the interface cell is controlled by the equation that is  
> bound to it, wouldn't setting the value be overriding the value of  
> the equation? Could you explain how an interface cell can be mutated  
> via the set() call? What happens to the equation when it is set from  
> outside the sheet?

Consider a UI where you have a number, x, and a checkbox associated  
with a bool, p,  that when set. When p is true, that implies x is 27.

---
interface:
	p : false;
	x : 0 <== p ? 27 : x;
---

The system is initialized with false and 0 for p and x. If p is set to  
true (by a checkbox bound to it), then x will become 27 (the  
edit_number field bound to x will also be disabled, because the value  
can't be changed from 27). If p goes back to false, the  value will  
becomes editable again and stays with whatever it is. The define  
expression on an interface cell is also referred to as a filter.

>
> You stated:
>
> "the idea with a relate clause is that for any state of the system,  
> one of the defines holds"

a relate clause represents a single constraint between multiple  
values. To satisfy the constraint, exactly one of the define  
expressions is executed for any given state of the system.

Let's say that I have two numbers, x and y, and a bool p. When p is  
true, x and y are equal - otherwise they are not. The constraint "x  
and y are equal" is expressed with the relate clause in the following  
sheet:

---
interface:
	p : false;
	x : 0;
	y : 0;
logic:
	when (p) relate {
		x <== y;
		y <== x;
	}
---

The relate clause can be read as "when p is true, either x is defined  
to be y, or y to be x.". The solver uses priorities on the values to  
determine which rule to use, but exactly one must be executed when p  
is true. The system tries to preserve higher priority values which  
usually corresponds to values most recently changed. So if y is most  
recently set, and p is true, the x will be defined to be y.

>
> I'm having a bit of difficulty understanding the purpose of a relate  
> clause. How is this:
>
> relate
> {
>     interface_cell <== another_interface_cell + 3;
>     another_interface_cell <== interface_cell - 3;
> }
>
> any different from this:
>
> interface_cell <== another_interface_cell + 3;
> another_interface_cell <== interface_cell - 3;

The later is circular - if both execute it is an infinite recursion  
and will give an error about cyclic relationships.
>
> In the latter case, the relate clause is not used but should still  
> be well-formed, correct?

Nope - not well formed.

> An interface cell can appear in more than one relate clause, and  
> relates can have an optional predicate - for example if you want  
> width and height to be the same when some predicate p is true it  
> would be expressed as:
>
> when (p) relate {
>        width <== height;
>        height <== width;
> }
>
> If you look at the Image Size example you can see how powerful the  
> relate clause is.
>
> Well in this example a "predicate" is undefined. Do predicates have  
> a special syntax in the script? What would 'p' be in this example?  
> Could you extend the example to show the definition of 'p'?

p here is any boolean value. A predicate is simply an expression which  
yields a bool. No special syntax. x == y is a predicate.

>
> Play with the examples and with the Begin app and ask lots of  
> questions - that's currently the best way to learn. Please also  
> point out specific holes in the docs (I know there are _many_),  
> knowing what people are struggling with helps me to prioritize the  
> work.
>
> Which examples are you referring to? The only code I've found that  
> is remotely useful for learning purposes is under  
> adobe_source_libraries/test. If there are other examples I am  
> supposed to be looking at, please let me know.

adobe_platform_libraries/test/begin/examples.

The begin.app lets you execute sheets and layouts. The examples  
directory contains many examples of sheets and layouts. the  
image_size.adm/.eve example is a complete implementation of the  
Photoshop Image Size dialog which contains many relationships.

>
> Right now the documentation (as-is) is very good for a reference  
> manual. It also adequately explains your design philosophies.  
> However, I think the biggest weakness is the lack of tutorials and  
> examples. I think our conversation via email has been a good example  
> of what needs to be addressed in the documentation. When I reference  
> the documentation, one of my main goals is to learn the details  
> about each individual operator. For example, the <== operator was  
> not given much attention in the documentation. There was also no  
> detailed sections covering constant, input, output, logic, and  
> interface cells. Detailed articles covering predicates and relate  
> clauses would also have been useful.
>
> From the main Wiki for ASL, I would expect to see a "Walkthrough"  
> guide. This walkthrough would cover basic concepts, then introduce  
> the expression syntax slowly by providing examples. The same example  
> would be used and as discussions become more advanced, you would  
> build onto the same example to make it more complex and introduce  
> newer concepts into it (Much like you did with the 2 minute tutorial  
> in your first email).
>
> Pages might look like this:
> "Step 1: Define your sheet"
> "Step 2: Define constant cells"
> "Step 3: Define input cells"
> "Step 4: Define logic cells"
> "Step 5: Define output cells"
> "Step 6: The relate clause"
> "Step 7: Predicates"
> "Step 8: A complete script (A functional layout & model)"
> "Step 9: Integrating into C++" (You would start with the main()  
> function, and loading the script we created in steps 1-8)
> "Step 10: Loading the sheet in C++"
> "Step 11: Creating/accessing widgets"
> .... etc ....
>
> This is how I envision the "tutorial" process working. Each "step"  
> would be its own page with fairly lengthy, detailed, and redundant  
> descriptions of the expression syntax. After the expression syntax  
> is covered, I would start introducing the C++ integration parts.  
> Show how to load a sheet, how to work with widgets, and modify  
> widgets. How to handle widget events (Like button clicks).
>
> I hope I've provided enough advice on the documentation side. I  
> think if you provided such a lengthy yet detailed and valuable  
> tutorial/walkthrough, you would not have to tutor me through the  
> mailing list. Additionally, while I do appreciate your help, it does  
> take quite a while to ask questions and then wait for responses. If  
> I could read a complete walkthrough (as I described above), I would  
> be able to learn about ASL much much quicker. Everybody wins.


Thanks for the input! I'll try and put something like this together.

Sean