adobe-source-devel — ASL development topic discussion

Re: [Adobe-source-devel] The possible overflow of priority_high_m in sheet

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

Hey,

I've opened an issue and ...

When trying the way of "rewriting the priorities* after the sort() in flow"
I found it needs to rewrite priorities of all interface cells, instead
of those have relations attached and unresolved.

So the following code snippet:
"""
    // Generate the set of cells connected to unresolved relations
    vector<cell_t*> cells;
    for (relation_cell_set_t::iterator f(relation_cell_set_m.begin()),
l(relation_cell_set_m.end());
         f != l; ++f) {
        if (!f->resolved_m)
            cells.insert(cells.end(), f->edges_m.begin(), f->edges_m.end());
    }

    sort(cells);
    cells.erase(unique(cells), cells.end());
"""

Is replaced with:

"""
    // Generate the set of (output) interface cells
    vector<cell_t*> cells;
    for (index_t::iterator f(output_index_m.begin()), l(output_index_m.end());
         f != l; ++f) {
        if ((*f)->specifier_m == access_interface_output)
            cells.insert(cells.end(), *f);
    }
"""

Now **cells** contain all interface cells(output part), and the
priority_accessed bits is set as follows:
"""
for (vector<cell_t*>::iterator f = cells.begin(), l = cells.end(); f
!= l; ++f) {
        if ((*f)->relation_count_m != 0)
            priority_accessed.set((*f)->interface_input_m->cell_set_pos_m);
"""

Any idea? Did I miss something?



BTW, I found name_t is actually a mapping from a `hash code' to a
`pointer of where the string is stored'.

"""            name_t() in adobe/name.hpp   →   map_string() in
source/name.cpp

typedef std::unordered_map<std::size_t, const char*> map_t;
...
static map_t map_s;
...

return found == map_s.end() ? map_s.emplace(hash,
pool_s.add(str)).first->second : found->second;
"""

It seems to me above code is incorrect when a hash collision happens -
different strings with the same `hash code' share a single `pointer',
right?



2016-01-22 12:47 GMT+08:00 Sean Parent <sea...@ma...>:
> Hi cee1,
> You might move this to an issue on github. Manipulating a list would require
> an index or search and a fair amount of machinery.
>
> Two simpler fixes -
> 1) Declare priority_t as int64_t. At 60 transactions per/second that gives
> you 4 billion years before overflow.
> 2) Rewrite the priorities and priority_high_m and _low_m after the sort() in
> flow
>
> (2) could be done only if high or low exceeds some threshold but I don't
> think I'd include that optimization without some measurements to show value.
>
> You could also not increment high or low if the cell be set is already at
> the limit - but that seems like an unnecessary pessimization for only
> theoretical safety,
>
> Send me a PR for either!
>
> Sean
>
> On Thu, Jan 21, 2016 at 6:32 PM, cee1 <fy...@gm...> wrote:
>>
>> Hi all,
>>
>> I notice each time touch/set a cell, priority_high_m is increased and
>> its value is assigned to
>> cell's priority_m field.
>>
>> So theoretically, it's possible to overflow priority_high_m, right? E.g.
>>
>> Considering in an automated UI test, (only) a text entry is frequently
>> updated, the priority_m of the backed cell is continuously increased,
>> and will finally overflow.
>>
>> The priority_m is (only) used in flow(): to sort the cells, and
>> process the relations attached to a cell one by one, right?
>> In other words, only the sequence is cared, not the distance.
>>
>>
>> So what about maintaining a `priority list', if a cell is touched/set,
>> move to .begin() ?
>>
>> Moreover, it may change type of the priority_m to a pointer of `link
>> node of the list', then if a cell is touched/set, it will be unlinked,
>> and reinserted to .begin() quickly.
>>
>>
>>
>> --
>> Regards,
>>
>> - cee1
>>
>>
>> ------------------------------------------------------------------------------
>> Site24x7 APM Insight: Get Deep Visibility into Application Performance
>> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>> Monitor end-to-end web transactions and take corrective actions now
>> Troubleshoot faster and improve end-user experience. Signup Now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
>



-- 
Regards,

- cee1

Re: [Adobe-source-devel] The possible overflow of priority_high_m in sheet

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

Hi cee1,
You might move this to an issue on github. Manipulating a list would
require an index or search and a fair amount of machinery.

Two simpler fixes -
1) Declare priority_t as int64_t. At 60 transactions per/second that gives
you 4 billion years before overflow.
2) Rewrite the priorities and priority_high_m and _low_m after the sort()
in flow

(2) could be done only if high or low exceeds some threshold but I don't
think I'd include that optimization without some measurements to show value.

You could also not increment high or low if the cell be set is already at
the limit - but that seems like an unnecessary pessimization for only
theoretical safety,

Send me a PR for either!

Sean

On Thu, Jan 21, 2016 at 6:32 PM, cee1 <fy...@gm...> wrote:

> Hi all,
>
> I notice each time touch/set a cell, priority_high_m is increased and
> its value is assigned to
> cell's priority_m field.
>
> So theoretically, it's possible to overflow priority_high_m, right? E.g.
>
> Considering in an automated UI test, (only) a text entry is frequently
> updated, the priority_m of the backed cell is continuously increased,
> and will finally overflow.
>
> The priority_m is (only) used in flow(): to sort the cells, and
> process the relations attached to a cell one by one, right?
> In other words, only the sequence is cared, not the distance.
>
>
> So what about maintaining a `priority list', if a cell is touched/set,
> move to .begin() ?
>
> Moreover, it may change type of the priority_m to a pointer of `link
> node of the list', then if a cell is touched/set, it will be unlinked,
> and reinserted to .begin() quickly.
>
>
>
> --
> Regards,
>
> - cee1
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

[Adobe-source-devel] The possible overflow of priority_high_m in sheet

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

Hi all,

I notice each time touch/set a cell, priority_high_m is increased and
its value is assigned to
cell's priority_m field.

So theoretically, it's possible to overflow priority_high_m, right? E.g.

Considering in an automated UI test, (only) a text entry is frequently
updated, the priority_m of the backed cell is continuously increased,
and will finally overflow.

The priority_m is (only) used in flow(): to sort the cells, and
process the relations attached to a cell one by one, right?
In other words, only the sequence is cared, not the distance.


So what about maintaining a `priority list', if a cell is touched/set,
move to .begin() ?

Moreover, it may change type of the priority_m to a pointer of `link
node of the list', then if a cell is touched/set, it will be unlinked,
and reinserted to .begin() quickly.



-- 
Regards,

- cee1

Re: [Adobe-source-devel] Getting started

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

Hi,

Last time I tried Visual Studio could not compile ASL. Even 2015 version. 
I add to use MinGW and GCC 5.1 to get something running, using boost build files. 

By the way,

I pushed a pull request with CMake build two days ago. Tested on Linux but you might be interested. 
https://github.com/stlab/adobe_source_libraries/pull/35
I will test it on Windows today. 

Regards,
Ivan

Le 9 juil. 2015 1:43 AM, Danny deSousa <dan...@gm...> a écrit :
>
> The read_me.html suggests that there are msvc9 solution and project files available however a search of the source files shows only msvc8 project and prop files.
>
> ---------- beginning snippet from read_me.html -------------
> Build Option 2: Using an IDE
> Building with MSVC 9
>
> There are MSVC 9 .sln and .vcproj files available for use at
>
>  C:\adobe_root\adobe_platform_librariesmsvc_ide\
>
> Opening the begin.sln file and building the 'begin' project will build all the necessary library dependencies (including the needed Boost libraries.)
>
> ----------- end of snipper from read_me.html ------------
>
> Are these still available?
>
> -Danny
>
> On Wed, Jul 8, 2015 at 4:10 PM Foster Brereton <fbr...@ad...> wrote:
>>
>> Hi Danny,
>>
>> You've got it right - the ASL sources are hosted on GitHub. What you see
>> there is up to date. Keep the thread going if you have any questions, etc.
>>
>> -foster
>>
>> --
>> Foster T. Brereton | Photoshop Engineering | Adobe | @phostershop
>>
>>
>>
>>
>>
>> On 7/8/15, 4:07p, "Danny deSousa" <dan...@gm...> wrote:
>>
>> >Hi,
>> >
>> >
>> >I'm interested in studying the property model implementation that is in
>> >the ASL however the content at http://stlab.adobe.com/ appears to be a
>> >little out-dated and so leading me to not trust it to tell me the current
>> > state of ASL.
>> >
>> >
>> >It appears that the ASL source resided, at some point, on SourceForge and
>> >then, later on, on some Perforce servers, presumably hosted by Adobe, and
>> >now, possibly, on github?
>> >
>> >
>> >Is the latest ASL source being hosted by github,
>> >https://github.com/stlab/adobe_source_libraries
>> ><https://github.com/stlab/adobe_source_libraries>,  now?
>> >
>> >
>> >Any help would be greatly appreciated.
>> >
>> >
>> >Thanks,
>> >
>> >
>> >-Danny
>> >
>>

Re: [Adobe-source-devel] Getting started

[Danny d. <dan...@gm...>]

The read_me.html suggests that there are msvc9 solution and project files
available however a search of the source files shows only msvc8 project and
prop files.

---------- beginning snippet from read_me.html -------------
Build Option 2: Using an IDEBuilding with MSVC 9

There are MSVC 9 .sln and .vcproj files available for use at

 C:\adobe_root\adobe_platform_librariesmsvc_ide\

Opening the begin.sln file and building the 'begin' project will build all
the necessary library dependencies (including the needed Boost libraries.)
----------- end of snipper from read_me.html ------------

Are these still available?

-Danny

On Wed, Jul 8, 2015 at 4:10 PM Foster Brereton <fbr...@ad...> wrote:

> Hi Danny,
>
> You've got it right - the ASL sources are hosted on GitHub. What you see
> there is up to date. Keep the thread going if you have any questions, etc.
>
> -foster
>
> --
> Foster T. Brereton | Photoshop Engineering | Adobe | @phostershop
>
>
>
>
>
> On 7/8/15, 4:07p, "Danny deSousa" <dan...@gm...> wrote:
>
> >Hi,
> >
> >
> >I'm interested in studying the property model implementation that is in
> >the ASL however the content at http://stlab.adobe.com/ appears to be a
> >little out-dated and so leading me to not trust it to tell me the current
> > state of ASL.
> >
> >
> >It appears that the ASL source resided, at some point, on SourceForge and
> >then, later on, on some Perforce servers, presumably hosted by Adobe, and
> >now, possibly, on github?
> >
> >
> >Is the latest ASL source being hosted by github,
> >https://github.com/stlab/adobe_source_libraries
> ><https://github.com/stlab/adobe_source_libraries>,  now?
> >
> >
> >Any help would be greatly appreciated.
> >
> >
> >Thanks,
> >
> >
> >-Danny
> >
>
>

Re: [Adobe-source-devel] Getting started

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

Hi Danny,

You've got it right - the ASL sources are hosted on GitHub. What you see
there is up to date. Keep the thread going if you have any questions, etc.

-foster

--
Foster T. Brereton | Photoshop Engineering | Adobe | @phostershop





On 7/8/15, 4:07p, "Danny deSousa" <dan...@gm...> wrote:

>Hi,
>
>
>I'm interested in studying the property model implementation that is in
>the ASL however the content at http://stlab.adobe.com/ appears to be a
>little out-dated and so leading me to not trust it to tell me the current
> state of ASL. 
>
>
>It appears that the ASL source resided, at some point, on SourceForge and
>then, later on, on some Perforce servers, presumably hosted by Adobe, and
>now, possibly, on github?
>
>
>Is the latest ASL source being hosted by github,
>https://github.com/stlab/adobe_source_libraries
><https://github.com/stlab/adobe_source_libraries>,  now?
>
>
>Any help would be greatly appreciated.
>
>
>Thanks,
>
>
>-Danny
>

[Adobe-source-devel] Getting started

[Danny d. <dan...@gm...>]

Hi,

I'm interested in studying the property model implementation that is in the
ASL however the content at http://stlab.adobe.com/ appears to be a little
out-dated and so leading me to not trust it to tell me the current state of
ASL.

It appears that the ASL source resided, at some point, on SourceForge and
then, later on, on some Perforce servers, presumably hosted by Adobe, and
now, possibly, on github?

Is the latest ASL source being hosted by github,
https://github.com/stlab/adobe_source_libraries,  now?

Any help would be greatly appreciated.

Thanks,

-Danny

Re: [Adobe-source-devel] Failures with latest asl code and gcc

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

Thanks for finding this, Ivan. Please keep us posted.

-foster




On 11/13/13 7:16a, "Ivan Le Lann" <iva...@fr...> wrote:

>And also name_test fails :
>
>adobe::name_t test("test");
>adobe::check_null(test);
>
>-> 
>   ./adobe/test/check_null.hpp(23): error in "name_test": operator bool
>   ./adobe/test/check_null.hpp(24): error in "name_test": operator!
>
>Maybe because there are multiple "empty_string_s" declared and it's
>testing pointers.
> source/string_pool.cpp
> source/name.cpp
>
>Fixing this might fix the runtime name/smoke.cpp errors I had.
>I will try to issue a pull request soon.
>
>Regards,
>Ivan
>
>
>----- Mail original -----
>> De: "Ivan Le Lann" <iva...@fr...>
>> À: ado...@li...
>> Envoyé: Mercredi 13 Novembre 2013 11:06:04
>> Objet: [Adobe-source-devel] Failures with latest asl code and gcc
>> 
>> FYI,
>> 
>> On GCC/Linux, I see two test failures in latest asl code.
>> I attached full output of ../boost_libraries/b2.
>> gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1)
>> 
>> 
>> 1) Compilation error in smoke32 (gcc message is in french and
>> translates to : large integer implicitly truncated to unsigned type)
>> 
>> gcc.compile.c++
>> 
>>/home/ivan/src/adobe/built_artifacts/test/unit_tests/name/gcc-4.8.2/debug
>>/address-model-32/architecture-x86/cpp11-on/instruction-set-native/link-s
>>tatic/threading-multi/smoke.o
>> test/unit_tests/name/smoke.cpp: In member function ‘void
>> name_smoke::test_method()’:
>> test/unit_tests/name/smoke.cpp:71:46: erreur: grand entier
>> implicitement tronqué pour un type non signé [-Werror=overflow]
>>      constexpr std::size_t hello_world_hash = 0x38d1334144987bf4;
>> 
>> 
>> 2) Runtime failure of unit_tests/name/smoke
>> 
>> 
>> Running 1 test case...
>> dump: {
>>    str: 'Hello, world!'
>>      n: 13
>>   hash: 0x38d1334144987bf4
>> };
>> dump: {
>>    str: 'Red Sox'
>>      n: 7
>>   hash: 0xc5746070bacfea32
>> };
>> dump: {
>>    str: 'Cardinals'
>>      n: 9
>>   hash: 0xa3dc334207638b4e
>> };
>> dump: {
>>    str: ''
>>      n: 0
>>   hash: 0xcbf29ce484222325
>> };
>> test/unit_tests/name/smoke.cpp(110): error in "name_smoke": check
>> !static_cast<bool>(static_null) failed
>> test/unit_tests/name/smoke.cpp(112): error in "name_smoke": check
>> !static_cast<bool>(nullname) failed
>> 0x47d180
>> 14
>> 38d1334144987bf4
>> 
>> *** 2 failures detected in test suite "Master Test Suite"
>> 
>> Regards,
>> Ivan
>> 
>> 
>> 
>> 
>>-------------------------------------------------------------------------
>>-----
>> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
>> Apps
>> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>> Free app hosting. Or install the open source package on any LAMP
>> server.
>> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
>> Native!
>> 
>>http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clkt
>>rk
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>> 
>
>--------------------------------------------------------------------------
>----
>DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
>OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
>Free app hosting. Or install the open source package on any LAMP server.
>Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
>http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktr
>k
>_______________________________________________
>Adobe-source-devel mailing list
>Ado...@li...
>https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] Failures with latest asl code and gcc

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

And also name_test fails :

adobe::name_t test("test");
adobe::check_null(test);

-> 
   ./adobe/test/check_null.hpp(23): error in "name_test": operator bool
   ./adobe/test/check_null.hpp(24): error in "name_test": operator!

Maybe because there are multiple "empty_string_s" declared and it's testing pointers.
 source/string_pool.cpp
 source/name.cpp

Fixing this might fix the runtime name/smoke.cpp errors I had.
I will try to issue a pull request soon.

Regards,
Ivan


----- Mail original -----
> De: "Ivan Le Lann" <iva...@fr...>
> À: ado...@li...
> Envoyé: Mercredi 13 Novembre 2013 11:06:04
> Objet: [Adobe-source-devel] Failures with latest asl code and gcc
> 
> FYI,
> 
> On GCC/Linux, I see two test failures in latest asl code.
> I attached full output of ../boost_libraries/b2.
> gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1)
> 
> 
> 1) Compilation error in smoke32 (gcc message is in french and
> translates to : large integer implicitly truncated to unsigned type)
> 
> gcc.compile.c++
> /home/ivan/src/adobe/built_artifacts/test/unit_tests/name/gcc-4.8.2/debug/address-model-32/architecture-x86/cpp11-on/instruction-set-native/link-static/threading-multi/smoke.o
> test/unit_tests/name/smoke.cpp: In member function ‘void
> name_smoke::test_method()’:
> test/unit_tests/name/smoke.cpp:71:46: erreur: grand entier
> implicitement tronqué pour un type non signé [-Werror=overflow]
>      constexpr std::size_t hello_world_hash = 0x38d1334144987bf4;
> 
> 
> 2) Runtime failure of unit_tests/name/smoke
> 
> 
> Running 1 test case...
> dump: {
>    str: 'Hello, world!'
>      n: 13
>   hash: 0x38d1334144987bf4
> };
> dump: {
>    str: 'Red Sox'
>      n: 7
>   hash: 0xc5746070bacfea32
> };
> dump: {
>    str: 'Cardinals'
>      n: 9
>   hash: 0xa3dc334207638b4e
> };
> dump: {
>    str: ''
>      n: 0
>   hash: 0xcbf29ce484222325
> };
> test/unit_tests/name/smoke.cpp(110): error in "name_smoke": check
> !static_cast<bool>(static_null) failed
> test/unit_tests/name/smoke.cpp(112): error in "name_smoke": check
> !static_cast<bool>(nullname) failed
> 0x47d180
> 14
> 38d1334144987bf4
> 
> *** 2 failures detected in test suite "Master Test Suite"
> 
> Regards,
> Ivan
> 
> 
> 
> ------------------------------------------------------------------------------
> DreamFactory - Open Source REST & JSON Services for HTML5 & Native
> Apps
> OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
> Free app hosting. Or install the open source package on any LAMP
> server.
> Sign up and see examples for AngularJS, jQuery, Sencha Touch and
> Native!
> http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
> 

[Adobe-source-devel] Failures with latest asl code and gcc

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

FYI,

On GCC/Linux, I see two test failures in latest asl code.
I attached full output of ../boost_libraries/b2.
gcc (GCC) 4.8.2 20131017 (Red Hat 4.8.2-1)


1) Compilation error in smoke32 (gcc message is in french and translates to : large integer implicitly truncated to unsigned type)

gcc.compile.c++ /home/ivan/src/adobe/built_artifacts/test/unit_tests/name/gcc-4.8.2/debug/address-model-32/architecture-x86/cpp11-on/instruction-set-native/link-static/threading-multi/smoke.o
test/unit_tests/name/smoke.cpp: In member function ‘void name_smoke::test_method()’:
test/unit_tests/name/smoke.cpp:71:46: erreur: grand entier implicitement tronqué pour un type non signé [-Werror=overflow]
     constexpr std::size_t hello_world_hash = 0x38d1334144987bf4;


2) Runtime failure of unit_tests/name/smoke


Running 1 test case...
dump: {
   str: 'Hello, world!'
     n: 13
  hash: 0x38d1334144987bf4
};
dump: {
   str: 'Red Sox'
     n: 7
  hash: 0xc5746070bacfea32
};
dump: {
   str: 'Cardinals'
     n: 9
  hash: 0xa3dc334207638b4e
};
dump: {
   str: ''
     n: 0
  hash: 0xcbf29ce484222325
};
test/unit_tests/name/smoke.cpp(110): error in "name_smoke": check !static_cast<bool>(static_null) failed
test/unit_tests/name/smoke.cpp(112): error in "name_smoke": check !static_cast<bool>(nullname) failed
0x47d180
14
38d1334144987bf4

*** 2 failures detected in test suite "Master Test Suite"

Regards,
Ivan

Re: [Adobe-source-devel] stlab's SHA on github

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

On Thu, Dec 13, 2012 at 5:03 PM, Foster Brereton <fbr...@ad...> wrote:

> I'll add the patch to the legacy development branch then. The unit test is
> relatively comprehensive though I don't think every API is quite covered
> yet. That can be resolved as well. As for documentation I'll look at the
> header and see what I can clean up.
>
> For both the doxygen docs and tests there is a lot of cruft currently in
> the repository. Are we willing to break a lot of what's in there in favor
> of the new world order, or is it worth creating a development branch in
> the adobe source libraries depot and build from scratch?
>

What is there is already broken to the point of not being usable, so feel
free to rebuild in place or build from scratch in
adobe_source_libraries/development.

Sean


>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
> Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe
>
>
>
>
>
>
> On 12/13/12 4:25p, "Sean Parent" <sp...@ad...> wrote:
>
> >
> >On Dec 13, 2012, at 4:05 PM, Foster Brereton <fbr...@ad...> wrote:
> >
> >
> >I have a patch to make to the sha.hpp header in ASL and figure it would be
> >a good time for me to dip my toes in ASL on github. I'm thinking it would
> >be a good place to start the module style on github as its a single header
> >file that depends only on adobe/config.hpp and three boost headers.
> >
> >What's the process of "promoting" an ASL component to the github module
> >structure?
> >
> >git modules aside and based on what Boost is doing, I'm thinking a sha/
> >repo with:
> >
> > - sha/include/adobe/sha.hpp
> > - sha/test/jamfile.jam
> > - sha/test/main.cpp
> >
> >
> >
> >The boost module structure isn't quite usable yet (at least I wasn't able
> >to get it going). I decided to hold off a bit here. What I'd like to do
> >is to start migrating files out of the legacy repo into the
> >adobe_source_libraries repo.
> >
> >Basically, rebuild things in the form of boost 1.52.0 for now - but I
> >only want files going into adobe_source_libraries that have:
> >
> >1) A good unit test (I'd like to ensure full code coverage - but haven't
> >yet setup tooling for that).
> >2) Clean docs (the current docs aren't even close to building with latest
> >doxygen).
> >
> >Let's _not_ submit built docs to this repo -  we should do that to a
> >pages repo but that isn't setup yet.
> >
> >I'm in the process of cleaning up unicode.hpp cause imagecore/video needs
> >this (I'd like to just redo it to use the C++11 unicode support but
> >imagecore still needs to support C++03 for a bit longer). I'm doing the
> >work in /legacy/development and then planning to move it into
> >/adobe_source_libraries when it is cleaned up.
> >
> >Any suggestions to bend this to be more forward looking is welcome as
> >well.
> >
> >Sean
> >
> >
> >
> >(SHA already has its own ASL test.)
> >
> >A couple questions:
> > - I could add a docs folder but it'd be empty - maybe a placeholder .md
> >or .html in there?
> > - I'm guessing config.hpp needs to go into its own module? 'common' with
> >just the include?
> > - How are dependencies established between submodules? The jamfiles will
> >have to be updated to include each dependency module's include path
> >separately, which will immediately break if/when ASL is glommed back
> >together again a la the official boost releases. How is the disparity
> >between module folder structure and distribution folder structure handled?
> >
> >Blessings,
> >Foster
> >
> >
> >--
> >Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
> >Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe
> >
> >
> >
> >
> >
> >
> >
> >
> >Sean Parent
> >sp...@ad...
> >
> >“Simplicity and elegance are unpopular because they require hard work and
> >discipline to achieve and education to be appreciated.” - Edsger W.
> >Dijkstra
> >
> >
> >
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

Re: [Adobe-source-devel] stlab's SHA on github

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

I'll add the patch to the legacy development branch then. The unit test is
relatively comprehensive though I don't think every API is quite covered
yet. That can be resolved as well. As for documentation I'll look at the
header and see what I can clean up.

For both the doxygen docs and tests there is a lot of cruft currently in
the repository. Are we willing to break a lot of what's in there in favor
of the new world order, or is it worth creating a development branch in
the adobe source libraries depot and build from scratch?

Blessings,
Foster


--
Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe






On 12/13/12 4:25p, "Sean Parent" <sp...@ad...> wrote:

>
>On Dec 13, 2012, at 4:05 PM, Foster Brereton <fbr...@ad...> wrote:
>
>
>I have a patch to make to the sha.hpp header in ASL and figure it would be
>a good time for me to dip my toes in ASL on github. I'm thinking it would
>be a good place to start the module style on github as its a single header
>file that depends only on adobe/config.hpp and three boost headers.
>
>What's the process of "promoting" an ASL component to the github module
>structure?
>
>git modules aside and based on what Boost is doing, I'm thinking a sha/
>repo with:
>
> - sha/include/adobe/sha.hpp
> - sha/test/jamfile.jam
> - sha/test/main.cpp
>
>
>
>The boost module structure isn't quite usable yet (at least I wasn't able
>to get it going). I decided to hold off a bit here. What I'd like to do
>is to start migrating files out of the legacy repo into the
>adobe_source_libraries repo.
>
>Basically, rebuild things in the form of boost 1.52.0 for now - but I
>only want files going into adobe_source_libraries that have:
>
>1) A good unit test (I'd like to ensure full code coverage - but haven't
>yet setup tooling for that).
>2) Clean docs (the current docs aren't even close to building with latest
>doxygen).
>
>Let's _not_ submit built docs to this repo -  we should do that to a
>pages repo but that isn't setup yet.
>
>I'm in the process of cleaning up unicode.hpp cause imagecore/video needs
>this (I'd like to just redo it to use the C++11 unicode support but
>imagecore still needs to support C++03 for a bit longer). I'm doing the
>work in /legacy/development and then planning to move it into
>/adobe_source_libraries when it is cleaned up.
>
>Any suggestions to bend this to be more forward looking is welcome as
>well.
>
>Sean
>
>
>
>(SHA already has its own ASL test.)
>
>A couple questions:
> - I could add a docs folder but it'd be empty - maybe a placeholder .md
>or .html in there?
> - I'm guessing config.hpp needs to go into its own module? 'common' with
>just the include?
> - How are dependencies established between submodules? The jamfiles will
>have to be updated to include each dependency module's include path
>separately, which will immediately break if/when ASL is glommed back
>together again a la the official boost releases. How is the disparity
>between module folder structure and distribution folder structure handled?
>
>Blessings,
>Foster
>
>
>--
>Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
>Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe
>
>
>
>
>
>
>
>
>Sean Parent
>sp...@ad...
>
>“Simplicity and elegance are unpopular because they require hard work and
>discipline to achieve and education to be appreciated.” - Edsger W.
>Dijkstra
>
>
>
>
>
>
>

Re: [Adobe-source-devel] Moving ASL to github

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

I have taken a stab at this and made notes in the legacy/development
branch accordingly.

The BOOST_NO_CXX11_NUMERIC_LIMITS macro not being defined seems to be a
Clang support issue within boost/config. It's being defined appropriately
when the toolset is darwin (gcc-4.2.1)

Note: Using Apple's dev tools using clang is now a requirement given the
use of c++11 features that only exist in gcc versions 4.4 or later. Xcode
4.5.2 uses a flavor of gcc 4.2.1. I'm sure Sean and Mat are aware of this,
but I wanted to call it out explicitly. Of course if you're building with
a version of gcc that supports the c++11 features used, you're in the
clear.

With bjam I haven't been able to figure out a way to force the entire code
base of Begin to build with the x86 architecture. The command line I've
been using is:

    bjam -a release -j8 address-model=32

Note: -a is a force-rebuild of all sources and is optional. -j8 specifies
8 concurrent compilation processes for my 8-core machine; YMMV.

Blessings,
Foster


--
Foster T. Brereton                  ΙΧΘΥΣ                  Ro.3:21-26
Senior Computer Scientist   ---   Photoshop Engineering   ---   Adobe






On 11/8/12 8:51p, "Sean Parent" <sea...@ma...> wrote:

>I've move the migration page on the wiki
><http://stlab.adobe.com/wiki/index.php/GitHub_Migration_and_Status> and
>updated the status.
>
>Assistance from anyone with experience in bjam and/or cmake would be
>greately appreciated at this point (see the status).
>
>Sean
>
>
>On Wed, Nov 7, 2012 at 3:02 PM, Sean Parent <sea...@ma...> wrote:
>
>Feel free to fork - splitting into modules is going to take some time.
>-----
>
>First up is any_regular.hpp
>   Issues with the current implementation to be addressed:
>       1) reliance on promote<> - promote<> seemed like a good idea but
>it has bit me a number of times, currently longs promote to double, which
>is just wrong. It also means that the interface needs to be value based
>in many locations where it could have been reference based. Will add a
>build flag to tag places where promote would have kicked in to help with
>migration.
>       2) needs to be updated to C++11 move, and remove dependency on
>move library.
>       3) assignment - currently requires assignment, this is an issue
>because I'd like to make function objects and lambda's first class (or as
>close as possible) but equality is very useful. I have been playing with
>ways to write a has_equal_to<> that seems to work good enough.
>       4) implementation and interface complicated by ABI stability. ABI
>stability to be removed (but I will be moving to using inlined
>namespaces).
>       5) implementation complicated by use of poly<> - plan to remove
>that.
>       6) rename to adobe::any
>       7) make constructor implicit
>       8) rename explicit_cast and runtime_cast to static_cast_ and
>dynamic_cast_ to make them easier to remember.
>
>
>Open issues:
>       1) Match boost::any api including broken any_cast interface?
>(differs from boost::any by support small object optimization, optional
>equal_to, and unsafe static cast). boost::any has been proposed to the
>standard - and the broken any_cast has already been discussed to be fixed.
>       2) Add support for other operators - such as index by std::size_t
>or const char* (useful for dictionaries and arrays), arithmetic operators
>for numeric types?
>
>Suggestions? Comments?
>Sean
>
>
>
>On Wed, Nov 7, 2012 at 2:01 PM, Ivan Le Lann <iva...@fr...> wrote:
>
>
>
>________________________________________
>
>De: "Sean Parent" <sea...@ma...>
>À: ado...@li..., "Mat Marcus"
><mm...@em...>, "Foster Brereton" <fbr...@ad...>
>Envoyé: Mercredi 7 Novembre 2012 01:37:03
>Objet: Re: [Adobe-source-devel] Moving ASL to github
>
>I setup a section on our wiki to document the transition to github. That
>can be found here:
>
>http://stlab.adobe.com/wiki/index.php/Github_migration
>
>
>Not a lot there at the moment - but should be enough to get people
>started.
>
>
>
>
>Thank you for doing this.
>I will definitely base my (utterly slow) work on ASL on this repository.
>
>As I do not understand anything to Perforce, merging with .43 release has
>been somewhat painful.
>
>
>
>
>
>As modules are split out and cleaned up I plan to propose them for
>inclusion in boost as appropriate.
>
>
>
>
>
>
>
>
>
>
>Does that mean that forking is not recommended at the moment and until
>modules are split ?
>
>Regards,
>Ivan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [Adobe-source-devel] Moving ASL to github

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

I've move the migration page on the wiki <
http://stlab.adobe.com/wiki/index.php/GitHub_Migration_and_Status> and
updated the status.

Assistance from anyone with experience in bjam and/or cmake would be
greately appreciated at this point (see the status).

Sean


On Wed, Nov 7, 2012 at 3:02 PM, Sean Parent <sea...@ma...> wrote:

> Feel free to fork - splitting into modules is going to take some time.
>
> -----
>
> First up is any_regular.hpp
>    Issues with the current implementation to be addressed:
>        1) reliance on promote<> - promote<> seemed like a good idea but it
> has bit me a number of times, currently longs promote to double, which is
> just wrong. It also means that the interface needs to be value based in
> many locations where it could have been reference based. Will add a build
> flag to tag places where promote would have kicked in to help with
> migration.
>        2) needs to be updated to C++11 move, and remove dependency on move
> library.
>        3) assignment - currently requires assignment, this is an issue
> because I'd like to make function objects and lambda's first class (or as
> close as possible) but equality is very useful. I have been playing with
> ways to write a has_equal_to<> that seems to work good enough.
>        4) implementation and interface complicated by ABI stability. ABI
> stability to be removed (but I will be moving to using inlined namespaces).
>        5) implementation complicated by use of poly<> - plan to remove
> that.
>        6) rename to adobe::any
>        7) make constructor implicit
>        8) rename explicit_cast and runtime_cast to static_cast_ and
> dynamic_cast_ to make them easier to remember.
>
> Open issues:
>        1) Match boost::any api including broken any_cast interface?
> (differs from boost::any by support small object optimization, optional
> equal_to, and unsafe static cast). boost::any has been proposed to the
> standard - and the broken any_cast has already been discussed to be fixed.
>        2) Add support for other operators - such as index by std::size_t
> or const char* (useful for dictionaries and arrays), arithmetic operators
> for numeric types?
>
> Suggestions? Comments?
> Sean
>
>
> On Wed, Nov 7, 2012 at 2:01 PM, Ivan Le Lann <iva...@fr...> wrote:
>
>>
>>
>> ------------------------------
>>
>> *De: *"Sean Parent" <sea...@ma...>
>> *À: *ado...@li..., "Mat Marcus" <
>> mm...@em...>, "Foster Brereton" <fbr...@ad...>
>> *Envoyé: *Mercredi 7 Novembre 2012 01:37:03
>> *Objet: *Re: [Adobe-source-devel] Moving ASL to github
>>
>>
>> I setup a section on our wiki to document the transition to github. That
>> can be found here:
>>
>> http://stlab.adobe.com/wiki/index.php/Github_migration
>>
>> Not a lot there at the moment - but should be enough to get people
>> started.
>>
>>
>> Thank you for doing this.
>> I will definitely base my (utterly slow) work on ASL on this repository.
>> As I do not understand anything to Perforce, merging with .43 release has
>> been somewhat painful.
>>
>>
>>
>>
>>> As modules are split out and cleaned up I plan to propose them for
>>> inclusion in boost as appropriate.
>>>
>>>
>>
>> Does that mean that forking is not recommended at the moment and until
>> modules are split ?
>>
>> Regards,
>> Ivan
>>
>>
>>
>

Re: [Adobe-source-devel] Moving ASL to github

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

Feel free to fork - splitting into modules is going to take some time.

-----

First up is any_regular.hpp
   Issues with the current implementation to be addressed:
       1) reliance on promote<> - promote<> seemed like a good idea but it
has bit me a number of times, currently longs promote to double, which is
just wrong. It also means that the interface needs to be value based in
many locations where it could have been reference based. Will add a build
flag to tag places where promote would have kicked in to help with
migration.
       2) needs to be updated to C++11 move, and remove dependency on move
library.
       3) assignment - currently requires assignment, this is an issue
because I'd like to make function objects and lambda's first class (or as
close as possible) but equality is very useful. I have been playing with
ways to write a has_equal_to<> that seems to work good enough.
       4) implementation and interface complicated by ABI stability. ABI
stability to be removed (but I will be moving to using inlined namespaces).
       5) implementation complicated by use of poly<> - plan to remove that.
       6) rename to adobe::any
       7) make constructor implicit
       8) rename explicit_cast and runtime_cast to static_cast_ and
dynamic_cast_ to make them easier to remember.

Open issues:
       1) Match boost::any api including broken any_cast interface?
(differs from boost::any by support small object optimization, optional
equal_to, and unsafe static cast). boost::any has been proposed to the
standard - and the broken any_cast has already been discussed to be fixed.
       2) Add support for other operators - such as index by std::size_t or
const char* (useful for dictionaries and arrays), arithmetic operators for
numeric types?

Suggestions? Comments?
Sean


On Wed, Nov 7, 2012 at 2:01 PM, Ivan Le Lann <iva...@fr...> wrote:

>
>
> ------------------------------
>
> *De: *"Sean Parent" <sea...@ma...>
> *À: *ado...@li..., "Mat Marcus" <
> mm...@em...>, "Foster Brereton" <fbr...@ad...>
> *Envoyé: *Mercredi 7 Novembre 2012 01:37:03
> *Objet: *Re: [Adobe-source-devel] Moving ASL to github
>
>
> I setup a section on our wiki to document the transition to github. That
> can be found here:
>
> http://stlab.adobe.com/wiki/index.php/Github_migration
>
> Not a lot there at the moment - but should be enough to get people started.
>
>
> Thank you for doing this.
> I will definitely base my (utterly slow) work on ASL on this repository.
> As I do not understand anything to Perforce, merging with .43 release has
> been somewhat painful.
>
>
>
>
>> As modules are split out and cleaned up I plan to propose them for
>> inclusion in boost as appropriate.
>>
>>
>
> Does that mean that forking is not recommended at the moment and until
> modules are split ?
>
> Regards,
> Ivan
>
>
>

Re: [Adobe-source-devel] Moving ASL to github

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

----- Mail original -----

> De: "Sean Parent" <sea...@ma...>
> À: ado...@li..., "Mat Marcus"
> <mm...@em...>, "Foster Brereton" <fbr...@ad...>
> Envoyé: Mercredi 7 Novembre 2012 01:37:03
> Objet: Re: [Adobe-source-devel] Moving ASL to github

> I setup a section on our wiki to document the transition to github.
> That can be found here:

> http://stlab.adobe.com/wiki/index.php/Github_migration

> Not a lot there at the moment - but should be enough to get people
> started.
Thank you for doing this. 
I will definitely base my (utterly slow) work on ASL on this repository. 
As I do not understand anything to Perforce, merging with .43 release has been somewhat painful. 

> > As modules are split out and cleaned up I plan to propose them for
> > inclusion in boost as appropriate.
> 

Does that mean that forking is not recommended at the moment and until modules are split ? 

Regards, 
Ivan 

Re: [Adobe-source-devel] Moving ASL to github

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

I setup a section on our wiki to document the transition to github. That
can be found here:

http://stlab.adobe.com/wiki/index.php/Github_migration

Not a lot there at the moment - but should be enough to get people started.

Sean


On Tue, Nov 6, 2012 at 3:15 PM, Sean Parent <sea...@ma...> wrote:

> I've started what is planned to be a long migration of ASL to github. The
> ASL perforce database is now locked.
>
> You can find the current ASL mainline sources at:
>
> github/stlab/legacy
>
> The reason why they are in the legacy repo is that I plan to move the
> libraries to a structure conforming with the boost modular libraries
> (github/boost-lib).
>
> I will be starting with some of the libraries I've been using in a product
> I've been working on at Adobe (currently these are forked from ASL, so I'm
> doing this as part of upstreaming that work).
>
> Beside moving to github and module based libraries, I'm also working on:
>
> Updating ASL to C++11, removing unnecessary dependencies from boost (where
> C++11 libraries suffice) and removing overlap with newer boost libraries.
>
> Simplifying ASL by removing the ABI stable support for those libraries
> that use it, and taking a more pragmatic approach to the libraries (many
> were done as experiments where the complexity is unwarranted given the
> results).
>
> As modules are split out and cleaned up I plan to propose them for
> inclusion in boost as appropriate.
>
> I'd also like to consolidate as much of the remaining
> ASL infrastructure (we currently have mailing lists and issue tracking on
> source forge, website and wiki hosted by Adobe, and now source code moving
> to github). Suggestions and recommendations welcome.
>
> I'm hoping that moving to github will make it easier to collaborate with
> others on ASL. If you would like to help, let me know. If you have
> suggestions, let me know.
>
> Thanks,
> Sean
>

[Adobe-source-devel] Moving ASL to github

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

I've started what is planned to be a long migration of ASL to github. The
ASL perforce database is now locked.

You can find the current ASL mainline sources at:

github/stlab/legacy

The reason why they are in the legacy repo is that I plan to move the
libraries to a structure conforming with the boost modular libraries
(github/boost-lib).

I will be starting with some of the libraries I've been using in a product
I've been working on at Adobe (currently these are forked from ASL, so I'm
doing this as part of upstreaming that work).

Beside moving to github and module based libraries, I'm also working on:

Updating ASL to C++11, removing unnecessary dependencies from boost (where
C++11 libraries suffice) and removing overlap with newer boost libraries.

Simplifying ASL by removing the ABI stable support for those libraries that
use it, and taking a more pragmatic approach to the libraries (many were
done as experiments where the complexity is unwarranted given the results).

As modules are split out and cleaned up I plan to propose them for
inclusion in boost as appropriate.

I'd also like to consolidate as much of the remaining
ASL infrastructure (we currently have mailing lists and issue tracking on
source forge, website and wiki hosted by Adobe, and now source code moving
to github). Suggestions and recommendations welcome.

I'm hoping that moving to github will make it easier to collaborate with
others on ASL. If you would like to help, let me know. If you have
suggestions, let me know.

Thanks,
Sean

Re: [Adobe-source-devel] Message via your Google Profile: Looking for ASL mailing lists...

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

Hi Tim,
The sourceforge mailing lists are still the ones to use (cc'ed here) -
not much traffic these days. Nobody is working on ASL fulltime however
at C++ Now we started the processes of moving libraries from ASL to
boost - hopefully that will progress. I'm also doing some work now
that will likely find it's way into ASL - so hopefully well get an
update posted before the end of summer.

Sean

On Sun, Jun 24, 2012 at 3:47 PM, Tim Finer <tim...@gm...> wrote:
> Hello Sean, I tracked you down from your code comments in the Adobe Software
> Labs code that I'm rebuilding using clang. You mentioned a couple of years
> ago on Stack Overflow a mailing list? The Sourceforge ones look pretty dead.
> Best Regards, Tim
>
>
>
>
> -------------------------------------------------------------
>
> This message was sent to you from your Google profile. The sender does not
> have your email address.
>
> If you no longer wish to receive messages from your Google profile, you may
> edit your settings.

[Adobe-source-devel] More: Changes for boost 1.46.1 compatibility

[Marshall C. <mcl...@gm...>]

The file "adobe_source_libraries/tools/boost_1_44_0_patches.txt" contains patches to update boost for use with ASL.

It contains patches for two files in boost:
	* boost/filesystem/v2/operations.hpp	-- this patch is no longer necessary
	* tools/build/v2/tools/msvc.jam 		-- this patch needs to be reworked, since the jam file has been extensively modified to support MSVC v10.

Also, an additional file needs to be patched to remove an "unused variable" warning/error:

boost_libraries/boost/thread/pthread/condition_variable.hpp
54c54
<         BOOST_ASSERT(!res); (void) res;
---
>        BOOST_ASSERT(!res);

I have also submitted the following changelists:
	4133 -- Update install.sh to find the new location for the bjam sources
	4134 -- Update calls to boost::filesystem::path () 

With these changes, ASL now compiles correctly with boost 1.46.1 (on darwin; I don't have access to a windows machine at home).

-- Marshall

[Adobe-source-devel] Changes for boost 1.46.1 compatibility

[Marshall C. <mcl...@gm...>]

I had to make a change to "install.sh" because the location of the bjam sources has moved.
Changelist to follow.

Also, the following files do not compile vs. Boost 1.46.1, apparently because of changes to Boost.Filesystem:

The common error pattern:

error: invalid conversion from 'bool (*)(const std::string&)' to 'void*'
error:   initializing argument 2 of 'boost::filesystem3::path::path(const Source&, typename boost::enable_if<boost::filesystem3::path_traits::is_pathable<typename boost::decay<T>::type>, void>::type*) [with Source = char [14]]'

found on:
	future/source/platform_cursor.mm:29
	future/widgets/sources/virtual_machine_extension.cpp:65
	future/widgets/sources/virtual_machine_extension.cpp:83
	future/widgets/sources/platform_widget_utils.cpp:642
	future/source/macintosh_filesystem.cpp:48
	future/widgets/sources/platform_presets.cpp:49
	test/xstr_test/main.cpp:77
	test/begin/sources/express_viewer.cpp:313
	test/begin/sources/express_viewer.cpp:322
	test/begin/sources/express_viewer.cpp:323
	test/begin/sources/express_viewer.cpp:675

More as I figure it out ;-)

-- Marshall

Marshall Clow     Idio Software   <mailto:mcl...@gm...>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

[Adobe-source-devel] ASL 1.0.43 released

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

[Resend]

Novermber 2, 2010: Version 1.0.43 of the Adobe Source Libraries has
been released.

(Note: The .bat version of asl_net_setup is not currently
supported. Contributions to that script with valid links to pre-compiled
binaries for curl, etc. are welcome. Pre-compiled Mac OS X versions of
Adobe Begin are also not supported in this release)


Highlights of this release include:

2010/11/02 : 1.0.43
    ASL:
        - Updated projects to support Boost 1.44.0
        - Updated boost 1.44.0 patches
            - Add back security-theater setting to boost build
            - Addressing filesystem v2 compilation errors on windows
        - Simplified move library. Removed move_sink and copy_sink in favor of
            always using RVO.
        - Added the "to" token ("->") to the lexer
        - Removed gil from ASL (clients can use boost version instead)
        - Added support for gcc 4.5.0 with -std=C++0x.
        - Updated to Visual Studio 2010, older versions not supported.
        - Renamed jamfiles to jamfile.jam
        - Added support for hexadecimal numbers to the lexer (0xDEADBEEF,
            0xffe0, etc.)
        - Extended the dancing links algorithm to include colorized nodes;
            updated test cases as well.
        - gcc 4.2 and OS X 10.5 SDK support (deprecated function warnings
            selectively disabled).
        - Replaced of basic_sheet_t with sheet_t in layouts and associated Eve
            grammar updates.
        - New external_model_t with support for cell creation in Adam parser.
        - once.hpp fix (Thanks John (Eljay) Love-Jensen)
        - Added support for overriding the index operator in the
virtual machine.

        - Property model library

            Added support for multi-out relate terms. For example:
            ---
            logic:
                relate {
                    x, y <== [a, b];
                    a, b <== [x, y];
                }
            ---
            The rhs value must be an array with the same arity as the number of
            cells named on the left. A cell can appear more than once on the
            left so long as the term can be uniquely selected.

            Fixed bugs in flow algorithm that cuased cells to resolve
out of order.
            Fixed enablement bug in initial call to monitor_enabled.

    User supported libs (APL):
        - Fixed platform_slider on windows: now works to use scroll bar ranges
            different from 0 to 100 in eve
        - Binary file format debugger (bffd) submitted

Distribution files can be downloaded from here:
http://sourceforge.net/project/showfiles.php?group_id=132417

 - Mat

[Adobe-source-devel] Fwd: ASL 1.43 released

[Marshall C. <mcl...@gm...>]

I saw this on http://stlab.adobe.com/, but I don't think it was posted to this mailing list....

-- Marshall

> 
> 
> November 4, 2010 ASL - 1.0.43 Release
> I've recently returned to Adobe as architect for mobile imaging applications. The Software Technology Lab remains a "virtual group." We have a collection of improvements, fixes, updates, and additions that we've gathered over the last year and a half since the last release. My hope is to simplify the process and the libraries to something more managable and to get back to more frequent releases. Suggestions welcome.
> 
> A huge thanks to Foster and Mat who have continued to contribute to the libraries. Thanks much for your continued support!
> 
> Sean
> 
> Highlights of this release include: ASL:
> 
> 	• Updated projects to support Boost 1.44.0
> 	• Simplified move library. Removed move_sink and copy_sink in favor of always using RVO.
> 	• Added the "to" token ("->") to the lexer
> 	• Added support for hexadecimal numbers to the lexer (0xDEADBEEF, 0xffe0, etc.)
> 	• Removed gil from ASL (clients can use boost version instead)
> 	• Added support for gcc 4.5.0 with -std=C++0x.
> 	• Updated to Visual Studio 2010, older versions not supported.
> 	• Extended the dancing links algorithm to include colorized nodes; updated test cases as well.
> 	• gcc 4.2 and OS X 10.5 SDK support (deprecated function warnings selectively disabled).
> 	• Replaced of basic_sheet_t with sheet_t in layouts and associated Eve grammar updates.
> 	• New external_model_t with support for cell creation in Adam parser.
> 	• once.hpp fix (Thanks John (Eljay) Love-Jensen)
> 	• Added support for overriding the index operator in the virtual machine.
> 	• Miscellaneous bug fixes.
> 	• Property model library
> Added support for multi-out relate terms. For example: --- logic: relate { x, y <== [a, b]; a, b <== [x, y]; } --- The rhs value must be an array with the same arity as the number of cells named on the left. A cell can appear more than once on the left so long as the term can be uniquely selected.
> 
> User supported libs (APL):
> 
> 	• Binary file format debugger (bffd) submitted
> 

Re: [Adobe-source-devel] expression_filter.cpp, GCC_UNROLL_LOOPS and armv7

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

Update: Turning off thumb support seems to resolve the issue. For armv7 my understanding of Thumb is that it is more of a benefit than it is under armv6, so it's a toss-up as to which optimization might be preferred... I want both :)

Blessings,
Foster


On Oct 6, 2010, at 1:53 PM, Foster Brereton wrote:

> I am trying to compile ASL's expression_filter.cpp for armv7 and am getting the following (rather cryptic) error:
> 
>> {standard input}:43975:offset out of range
>> {standard input}:39770:offset out of range
>> {standard input}:39673:offset out of range
>> {standard input}:39576:offset out of range
>> {standard input}:35351:offset out of range
>> {standard input}:35274:offset out of range
>> {standard input}:35178:offset out of range
>> {standard input}:83731:offset out of range
>> {standard input}:83708:offset out of range
>> {standard input}:83685:offset out of range
>> {standard input}:83662:offset out of range
>> {standard input}:83639:offset out of range
>> {standard input}:83616:offset out of range
>> {standard input}:83593:offset out of range
>> {standard input}:83570:offset out of range
>> {standard input}:83549:offset out of range
>> {standard input}:83526:offset out of range
>> {standard input}:83503:offset out of range
>> {standard input}:83480:offset out of range
>> {standard input}:83457:offset out of range
> 
> 
> I am building with Xcode 3.2.4, GCC 4.2. I have discovered setting GCC_UNROLL_LOOPS to NO eliminates the error. When it is YES the above is printed. Note I get no error when compiling for the i386 or armv6 architectures.
> 
> Has anyone else seen this or is it just my build environment?
> 
> 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
> 
> 

-- 
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] expression_filter.cpp, GCC_UNROLL_LOOPS and armv7

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

Thumb support is on. I'll note to turn it off and see what happens.

Good to hear from you again, Ralph.

Blessings,
Foster


On Oct 6, 2010, at 2:42 PM, Ralph Thomas wrote:

> Compiler bug, looks like the assembler is getting overwhelmed (or
> maybe those are jump offsets; they're all larger than 2^14). Are you
> targeting Thumb2 (-mthumb with -march=armv7)? Maybe you could try
> compiling it in ARM mode if so...
> 
> Ralph
> 
> On Wed, Oct 6, 2010 at 1:53 PM, Foster Brereton <fbr...@ad...> wrote:
>> I am trying to compile ASL's expression_filter.cpp for armv7 and am getting the following (rather cryptic) error:
>> 
>>> {standard input}:43975:offset out of range
>>> {standard input}:39770:offset out of range
>>> {standard input}:39673:offset out of range
>>> {standard input}:39576:offset out of range
>>> {standard input}:35351:offset out of range
>>> {standard input}:35274:offset out of range
>>> {standard input}:35178:offset out of range
>>> {standard input}:83731:offset out of range
>>> {standard input}:83708:offset out of range
>>> {standard input}:83685:offset out of range
>>> {standard input}:83662:offset out of range
>>> {standard input}:83639:offset out of range
>>> {standard input}:83616:offset out of range
>>> {standard input}:83593:offset out of range
>>> {standard input}:83570:offset out of range
>>> {standard input}:83549:offset out of range
>>> {standard input}:83526:offset out of range
>>> {standard input}:83503:offset out of range
>>> {standard input}:83480:offset out of range
>>> {standard input}:83457:offset out of range
>> 
>> 
>> I am building with Xcode 3.2.4, GCC 4.2. I have discovered setting GCC_UNROLL_LOOPS to NO eliminates the error. When it is YES the above is printed. Note I get no error when compiling for the i386 or armv6 architectures.
>> 
>> Has anyone else seen this or is it just my build environment?
>> 
>> 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
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today.
>> http://p.sf.net/sfu/beautyoftheweb
>> _______________________________________________
>> 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