adobe-source-devel — ASL development topic discussion

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

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

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

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

[Jaakko J. <ja...@cs...>]

Note: I sent this a few days ago, but for some reason it did not appear on the list. Retrying:

Hi Ralph, 

On Sep 2, 2010, at 7:19 PM, Ralph Thomas wrote:

> Nice! It would be pretty cool to use ASL to cook up HTML forms, and
> also to use ASL for forms Clutter & Mx.
> 
> An (unrelated but) fun project might be to port Adam to Javascript...
> Maybe it would be possible to write the adam rule definitions in JS
> and use custom getters for all of the other sheet properties to track
> dependencies?

Indeed, HTML forms is an important domain to extend to. We are actually working 
on a Javascript-based Adam(-like) system; we'll be happy to share and make public what we have soon.

We (Jaakko Järvi, John Freeman, and a few others at Texas A&M University) 
have collaborated with Sean and Mat on this Adam-like system---I guess
one could say it is a "research version of Adam" (there are some small 
differences in the details on how the declarative sheet specification is interpreted and solved).

A few papers are available on the topic:

Algorithms for User Interfaces
Jaakko Järvi, Mat Marcus, Sean Parent, John Freeman, and Jacob N. Smith.
GPCE '09 Proceedings of the 8th international conference on Generative programming and component engineering, New York, NY, USA, pages 147-156, 2009. ACM 
http://parasol.cs.tamu.edu/~jarvi/papers/gpce09.pdf

Jaakko Järvi, Mat Marcus, Sean Parent, John Freeman, and Jacob N. Smith. Property models: from incidental algorithms to reusable components. In GPCE '08: Proceedings of the 7th international conference on Generative programming and component engineering, New York, NY, USA, pages 89-98, 2008. ACM.
http://parasol.cs.tamu.edu/~jarvi/papers/gpce08.pdf

While not described in those papers, we have the internals (a constraint solver, dealing with widget enablement, etc.) implemented in Javascript. There is no Eve port (for layout), and the system is still a research prototype.

We'll make the source and documentation available soon, but for now, 
here's a link to our internal prototype (which is still not all executing in the browser):

http://parasol.tamu.edu/groups/pttlgroup/property-models/hammer/

It is a research tool, so there is no emphaisis on beauty and smoothness (as will be apparent) 
and there are some extra things going on (green arrows visualising 
dependencies between UI elements, etc.)

Best,

 Jaakko

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

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

I Ivan,
I did try later and got to see it - I look forward to seeing Begin working!
Sean

On Mon, Sep 6, 2010 at 1:45 AM, Ivan Le Lann <iva...@fr...> wrote:

> Hi Sean,
>
> > Sounds cool but I can't seem to get to the server.
>
> I had it tested externally before I sent my mail and did see some people
> coming this weekend.
> Most probably, the server lost its poor wifi connection when you tried. I'm
> sorry for this.
> Anyway, that was just a slider with a display number showing its value.
>
> I shut it down this morning and will relaunch it on a more suited host when
> "begin" works.
>
> Regards,
> Ivan.
>
>
>

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

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

Hi Sean,

> Sounds cool but I can't seem to get to the server.

I had it tested externally before I sent my mail and did see some people coming this weekend.
Most probably, the server lost its poor wifi connection when you tried. I'm sorry for this.
Anyway, that was just a slider with a display number showing its value.

I shut it down this morning and will relaunch it on a more suited host when "begin" works.

Regards,
Ivan.

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

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

Sounds cool but I can't seem to get to the server.

To answer Ralph's question, I think a JS library wouldn't be a lot of work.
I know of two efforts that are thinking along this lines. I've only done a
little JS programming but I'd be interested in collaborating on such an
effort and I know a couple of other folks who might be interested. I think
there are two key pieces of work here:

* Providing a data binding system for JS widgets.
* Come up with a good way to declare sheets and cells.

The actual algorithms should be pretty straight forward to implement.

The current adam.cpp file (including .42 although there are several bug
fixes in the mainline depot for .43) is nearly completely decoupled from the
ASL virtual machine, decoupling the two will likely be my next step but it
is easy to see that the code could work with any function objects (older
versions of the virtual machine did dependency tracking and back tracking -
that has all been removed).

The core of the code is the flow() algorithm starting online 1080:

<
http://stlab.adobe.com:8080/@lno=y@//adobe_source_libraries/source/adam.cpp?ac=64&rev1=26
>

My current thoughts on adam.cpp are:

* Completely untangle it from the virtual machine - it will just operate on
function objects - this will make it much simpler to use directly from C++
without the language or to plug into other systems.

* Change the "when" construct to apply to multiple relationships.

* Use the boost graph library to represent the graph, this would give us a
simple way to use graphviz for visualizations and to use the connected
components algorithm to improve the enablement logic (currently a cell is
enabled if it's priority or value is read, however, a better definition is
if the cell is part of the same connected component as a cell which had it's
value read).

* Provide a way to associate invariants with particular output cells.

* Provide a standard way to declare limits on cells that controllers can
bind to.

My gut feeling is that  a really clean implementation will be about 500
lines (compared to the current 1500 lines)

On Sat, Sep 4, 2010 at 3:45 AM, Ivan Le Lann <iva...@fr...> wrote:

>
> > I will hopefully find time to fire an online sample this weekend.
>
> The (quite impressive!) first sample to worked is online.
> http://82.240.181.123/
> I'll try to keep this temporary server up a few days.
>
> Actually this is "begin" c++ code running here, but with a dummy adm/eve
> couple.
> >From now, I will try to get "begin" to work, and then build test cases
> present in APL directory.
>
> Ivan.
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

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

> I will hopefully find time to fire an online sample this weekend.
 
The (quite impressive!) first sample to worked is online.
http://82.240.181.123/
I'll try to keep this temporary server up a few days.

Actually this is "begin" c++ code running here, but with a dummy adm/eve couple.
>From now, I will try to get "begin" to work, and then build test cases present in APL directory.

Ivan.

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

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

----- "Ralph Thomas" <ra...@gm...> a écrit :

> Nice! It would be pretty cool to use ASL to cook up HTML forms, and
> also to use ASL for forms Clutter & Mx.

Thank you. :)

> An (unrelated but) fun project might be to port Adam to Javascript...
> Maybe it would be possible to write the adam rule definitions in JS
> and use custom getters for all of the other sheet properties to track
> dependencies?

Below is a verbatim extract from my ASL TODO list.
I'm not sure how close to your idea this is.
Any comment or idea is welcome.

Ivan.



ADAM
- embed a scripting language interpreter to easily enrich virtual machine.
- when scripting, find out a way to preserve automatical disabling (see "flatness" example below)
  
Typical adm file:

include "my_favorite_function.lua" 
// contains something like : adam_symbols = { function my_favorite_function (p, f) return (p == nil and 0.0) or f end } 

sheet clipping_path
{
output:
    result                  <== { path: path, flatness: flatness };

interface:
    //unlink flatness : 0.0   <== (path == empty) ? 0.0 : flatness;
    // would become :
    unlink flatness : 0.0   <== my_favorite_function (path, flatness);
    path            : 1;
}

Re: [Adobe-source-devel] APL/WT : Eve surfing on the Web

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

Nice! It would be pretty cool to use ASL to cook up HTML forms, and
also to use ASL for forms Clutter & Mx.

An (unrelated but) fun project might be to port Adam to Javascript...
Maybe it would be possible to write the adam rule definitions in JS
and use custom getters for all of the other sheet properties to track
dependencies?

Ralph

On Thu, Sep 2, 2010 at 10:00 AM, Ivan Le Lann <iva...@fr...> wrote:
> Hi,
>
> Here is a small teaser to announce that I recently achieved
> to run part of APL with a Wt widget backend.
>
> For those who don't know Wt, it is a C++ web widget library.
> A Wt process is either a built-in http server or a FastCGI plugin.
> Their website, built with Wt, and full of online samples :
> http://www.webtoolkit.eu/wt
>
> My work is based on the "windows" APL backend directory as of 1.0.42.
> The Wt switch is made through preprocessor definition : ADOBE_PLATFORM_WT.
> No file or directory is Wt-specific. I moved some widget code to simplify cohabitation.
> Basically, "plaftorm_widget_utils.hpp" has grown and the .cpp file is the main backend switch.
>
> About half of Eve widgets are done.
> I will hopefully find time to fire an online sample this weekend.
>
>
> Regards,
> Ivan.
>
>
> PS:
> My work is on bitbucket. But I have a huge commit to push today.
> http://bitbucket.org/liukahr/asl_wt
>
> My real point was more to ease the writing of eve backends than to use Wt.
> I picked Wt mainly because I found it handy for demo purpose.
> I intend to port APL to a portable library,
> and these days I am considering Clutter for this task.
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>

[Adobe-source-devel] APL/WT : Eve surfing on the Web

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

Hi,

Here is a small teaser to announce that I recently achieved
to run part of APL with a Wt widget backend.

For those who don't know Wt, it is a C++ web widget library.
A Wt process is either a built-in http server or a FastCGI plugin.
Their website, built with Wt, and full of online samples :
http://www.webtoolkit.eu/wt

My work is based on the "windows" APL backend directory as of 1.0.42.
The Wt switch is made through preprocessor definition : ADOBE_PLATFORM_WT.
No file or directory is Wt-specific. I moved some widget code to simplify cohabitation.
Basically, "plaftorm_widget_utils.hpp" has grown and the .cpp file is the main backend switch.

About half of Eve widgets are done.
I will hopefully find time to fire an online sample this weekend.


Regards,
Ivan.


PS: 
My work is on bitbucket. But I have a huge commit to push today.
http://bitbucket.org/liukahr/asl_wt

My real point was more to ease the writing of eve backends than to use Wt.
I picked Wt mainly because I found it handy for demo purpose.
I intend to port APL to a portable library, 
and these days I am considering Clutter for this task.

[Adobe-source-devel] property models with multi-out relationships

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

A couple of days ago I found a bug in my flow algorithm where I wasn't  
marking edges correctly (fix prior to my latest submit). In fixing  
that, it dawned on me how multi-out relationships should work. I just  
checked in a first cut of this to my sandbox.

Here's what I did. You can now have multiple values on the lhs of a  
relate expression (comma separated) and if you have more than one  
item, the expression on the right must yield an array with the same  
number of items as is on the left:

relate {
   a, b <== [c, d];
   c, d <== [a, b];
}

For this cut, a cell can only appear once on the lhs for all terms in  
the relate clause (a limitation because of how I'm simulating marking  
edges instead of actually marking edges... I'm a little unsure about  
the correct way to handle this case but I think it should be simple  
with some better data structures).

To flow the graph through this relate clause, if I enter the clause  
through one value (let's say "a") then any term with "a" on the lhs is  
disqualified as an out. When there is only one term remaining, flow  
continues through the lhs cells of that term and any cells named on  
the lhs that aren't already marked as in or out are marked as in. So  
if a has a high priority in this example, then we only have the c,d  
term to flow out of and b gets marked as an in edge. Note that we only  
know at that point that b is an input to the relate, we don't know how  
the value of b is determined. The old hack to simulate used to "back- 
flow" into b screwing up the contributing values. For example, if you  
had:

relate {
   a, b <== [c, d];
   c, d <== [a, b];
}

relate {
   b <== e;
   e <== b;
}

Then if a has the highest priority then it will contribute to c and d  
along with either b or e (depending on which was higher). The result  
is you can do multi-out relationships without screwing up script  
recording. Here is the full grouped options example done the old way  
with the self-reference hack:

---
sheet grouped_options
{
  interface:
	a : true;
	b : true;
	c : true;
	g : [a, b, c];
	all;
	
  constant:
   	g_true : [true, true, true];
   	g_false : [false, false, false];

  logic:
	relate { a <== g[0]; g <== [a, g[1], g[2]]; }
	relate { b <== g[1]; g <== [g[0], b, g[2]]; }
	relate { c <== g[2]; g <== [g[0], g[1], c]; }

	relate {
		all <== g == g_true ? true : g == g_false ? false : empty;
		g <== [all, all, all];
	}

  output:
     	result <== { a: a, b: b, c: c };
}
---

Here it is the new way:

---
sheet grouped_options
{
  interface:
	a : true;
	b : true;
	c : true;
	all;
	
  logic:
	relate {
		all  <== a == b && b == c ? a : empty;
		a, b, c <== [all, all, all];
	}

  output:
     	result <== {a: a, b: b, c: c};
}
---

Now you can do things like CMYK to RGB conversions simply (and  
correctly). Yea! Not bad for an hour of hacking...

Sean

Re: [Adobe-source-devel] Changes required in ASL (sheet_t::update)

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

Awhile ago I wrote short paper on this issue-

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

The current solution is to use functions - breadboard connectors are  
note implemented and my current thinking is they should really be  
implemented outside the property model library.

Sean

On May 18, 2010, at 11:47 AM, Ruchin Kansal wrote:

>
>
> From: Ruchin Kansal
> Sent: Wednesday, May 19, 2010 12:07 AM
> To: 'ado...@li...'
> Cc: Sean Parent; Amit Kumar..
> Subject: Changes required in ASL (sheet_t::update)
>
> Hi All,
> We (AI) are facing some problems in using ADAM/EVE framework. The  
> non-reentrancy of sheet_t::update() is becoming a bottleneck for us,
> therefore we want to propose two minor changes in framework:
> 1. A provision of post update callback from the sheet. This callback  
> if registered by a client, should be called whenever the sheet  
> update is complete.
> 2. A method to query if any update is in progress on the sheet.
>
> A use case:
> We have a dialog which is having a popup and few checkboxes. The  
> checked/unchecked state of the checkbox depends on the current popup  
> selection and some dynamic information like preference. So whenever,  
> popup entry is changed we have to modify the state of checkboxes.  
> Therefore, if one cell is bound to popup and another is bound to  
> checkbox, when the change notification of popup cell is received we  
> have to modify the cell which is bound to checkbox. This is not  
> possible as of now since update is non-reentrant, therefore we  
> should have a mechanism to know when the previous update is  
> complete. Therefore, we suggested the above changes.
> There are many other use cases as well.
>
> Does anyone find an issue in this implementation? These changes do  
> not break something else and will not affect anyone until callback  
> is set explicitly by a client.
>
> Regards,
> Ruchin.
>

Re: [Adobe-source-devel] Layout issues witn EVE

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

Hi Kumar,

The current ASL depot is stlab.corp.adobe.com:10666. Though the document is
quite old, the basic concepts still hold as to contribution policies:

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

Basically ASL employs a sandbox-review method to give people a chance to
build and review changes made to ASL before they are submitted to the
mainline codebase. If you need an account created on the depot let me know.

Blessings,
Foster


On 18/05/10 6:24 AM, "Kumar Lomash" <kl...@ad...> wrote:

> I would be more than happy to work on ASL issues. Can I get some direction on
> “how to”? Repository, branch, bug fix process etc. OR a wiki which has all of
> it J
>  
> Thanks,
> Lomash
>  
> 
> From: Sean Parent [mailto:sea...@ma...]
> Sent: 18 May 2010 02:30
> To: Kumar Lomash
> Cc: Foster Brereton; asl [dev]
> Subject: Re: Layout issues witn EVE
>  
>  
> 
> On May 17, 2010, at 3:10 AM, Kumar Lomash wrote:
> 
> 
> Hi Sean,
> 
>  
> 
> We already have a guide widget “guide_consumer” in dvaadameve and I guess
> “row” should work as an attachment widget, so I guess we already have the
> infrastructure required at client’s end. Although some bugs can fixed like
> omitting no inter-widget spacing if size is 0 and so on.
> 
>  
> 
> Image:
> 
> 1.       I tried your solution and it worked –thanks! And, you were right to
> say that the bug with align_fill would bite me – I guess I will have to wait
> till this bug is fixed to have all my layouts properly ported to EVE2.
> 
>  
> 
> No ETA on a fix - feel free to jump in.
> 
> 
> 2.       If I have two columns, then the two widgets in the second column do
> not snap to first and third widgets of the first column. I was hoping that
> guides would do the trick here but they do not seem to be working as expected.
> Are there guide widgets in Adobe Begin? If yes, then I can test the code in it
> at least.
> 
>  
> 
> By default, columns mask baselines. You can fix that with a guide_mask
> attribute (pass an empty array to clear the default guide mask.
> 
>  
> 
> Begin doesn't have a guide widget - but here is an example using a small
> button as a baseline guide placeholder:
> 
>  
> 
> layout my_dialog
> 
> {
> 
>    view dialog(name: localize("Two Columns"))
> 
>    {
> 
>        row() {
> 
>                                 column(guide_mask: []) {
> 
>                                                 button(name: "Button 1");
> 
>                                                 button(name: "Button 2");
> 
>                                                 button(name: "Button 3");
> 
>                                 }
> 
>                                 column(guide_mask: []) {
> 
>                                                 button(name: "Button 1");
> 
>                                                 button(name: "baseline
> placeholder", size: @size_small);
> 
>                                                 button(name: "Button 3");
> 
>                                 }
> 
>                 }
> 
>    }
> 
> }
> 
>  
> 
> Sean
> 
> 
>  
> 
> Regards,
> 
> Lomash
> 
>  
> 
> From: Sean Parent [mailto:sea...@ma...]
> Sent: 14 May 2010 22:38
> To: Kumar Lomash
> Cc: Foster Brereton; asl [dev]
> Subject: Re: Layout issues witn EVE
> 
>  
> 
> +adobe-source-devel
> 
>  
> 
> I'd start by implementing a guide widget and/or an attachment attribute. A
> guide widget is just a widget that has a guide but no other dimension.
> Attachments attributes are a way to decorate an existing widget with a guide
> (such as attaching a guide on the left side). Both of these can be done client
> side, without modifying the layout engine.
> 
>  
> 
> A couple of fixes/additions to the layout engine may be required to make this
> work well:
> 
>             1) There isn't anyway to suppress the spacing on a widget so a
> guide widget will get inter item spacing on both sides. This could be worked
> around with the spacing attribute, but a better fix would be to suppress
> spacing for widgets with no dimension on an axis.
> 
>             2) The same bug we discussed before with align fill not obeying
> guides can bite you.
> 
>  
> 
> If you implement a guide widget or attachment attributes please discuss on the
> list so we can add the terminology to the standard terminology.
> 
>  
> 
>  
> 
> A couple of comments on the image -
> 
>             For the first case, I'm not a fan of group boxes - too much visual
> clutter. I prefer separator lines. We should still support such layouts with
> the engine though. Adding a guide on each end of the rows and fixing (1)
> should give you this.
> 
>             Not sure why the second case can't be handled with two columns.
> 
>  
> 
> Sean
> 
>  
> 
> On May 14, 2010, at 6:55 AM, Kumar Lomash wrote:
> 
> 
> 
> 
> Hi Sean,
> 
>  
> 
> Generally, we want some controls to be aligned from both the sides in a
> column. So, a very common practice is to put them in a column and say
> align_fill horizontally. But, this solution would not work when we are forced
> to keep these widgets in separate rows/columns. Then, need for both forward
> and reverse guides arise (I am not sure if it can be achieved with only one).
> 
>  
> 
> In the attached snapshots, there are two scenarios which I am guessing would
> be solved by the same “trick”. I have been trying to implement them but
> nothing seems to work fully.
> 
>  
> 
> Scenario description:
> 
> There are two scenarios, separated by a thick horizontal like. Assume two
> separate layouts. None of the widget’s sizes are same by default so we cannot
> assume that they will  be of the same size without any layout constraints.
> 
> 1.       A widget and a group box in a column, two widgets inside group box.
> All the 3 widgets should align from both the sides.
> 
> 2.       A row with two widgets, another widget and again a row with two
> widgets in a column
> 
> The red lines display expected alignments.
> 
>  
> 
> Thanks for your help.
> 
>  
> 
> Regards,
> 
> Lomash
> 
>  
> 
>  
> 
>  
> 
>  
>  

-- 
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] Layout issues witn EVE

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

On May 17, 2010, at 3:10 AM, Kumar Lomash wrote:

> Hi Sean,
>
> We already have a guide widget “guide_consumer” in dvaadameve and I  
> guess “row” should work as an attachment widget, so I guess we  
> already have the infrastructure required at client’s end. Although  
> some bugs can fixed like omitting no inter-widget spacing if size is  
> 0 and so on.
>
> Image:
> 1.       I tried your solution and it worked –thanks! And, you were  
> right to say that the bug with align_fill would bite me – I guess I  
> will have to wait till this bug is fixed to have all my layouts  
> properly ported to EVE2.

No ETA on a fix - feel free to jump in.

> 2.       If I have two columns, then the two widgets in the second  
> column do not snap to first and third widgets of the first column. I  
> was hoping that guides would do the trick here but they do not seem  
> to be working as expected. Are there guide widgets in Adobe Begin?  
> If yes, then I can test the code in it at least.

By default, columns mask baselines. You can fix that with a guide_mask  
attribute (pass an empty array to clear the default guide mask.

Begin doesn't have a guide widget - but here is an example using a  
small button as a baseline guide placeholder:

layout my_dialog
{
     view dialog(name: localize("Two Columns"))
     {
         row() {
		column(guide_mask: []) {
			button(name: "Button 1");
			button(name: "Button 2");
			button(name: "Button 3");
		}
		column(guide_mask: []) {
			button(name: "Button 1");
			button(name: "baseline placeholder", size: @size_small);
			button(name: "Button 3");
		}
	}
     }
}

Sean

>
> Regards,
> Lomash
>
> From: Sean Parent [mailto:sea...@ma...]
> Sent: 14 May 2010 22:38
> To: Kumar Lomash
> Cc: Foster Brereton; asl [dev]
> Subject: Re: Layout issues witn EVE
>
> +adobe-source-devel
>
> I'd start by implementing a guide widget and/or an attachment  
> attribute. A guide widget is just a widget that has a guide but no  
> other dimension. Attachments attributes are a way to decorate an  
> existing widget with a guide (such as attaching a guide on the left  
> side). Both of these can be done client side, without modifying the  
> layout engine.
>
> A couple of fixes/additions to the layout engine may be required to  
> make this work well:
>             1) There isn't anyway to suppress the spacing on a  
> widget so a guide widget will get inter item spacing on both sides.  
> This could be worked around with the spacing attribute, but a better  
> fix would be to suppress spacing for widgets with no dimension on an  
> axis.
>             2) The same bug we discussed before with align fill not  
> obeying guides can bite you.
>
> If you implement a guide widget or attachment attributes please  
> discuss on the list so we can add the terminology to the standard  
> terminology.
>
>
> A couple of comments on the image -
>             For the first case, I'm not a fan of group boxes - too  
> much visual clutter. I prefer separator lines. We should still  
> support such layouts with the engine though. Adding a guide on each  
> end of the rows and fixing (1) should give you this.
>             Not sure why the second case can't be handled with two  
> columns.
>
> Sean
>
> On May 14, 2010, at 6:55 AM, Kumar Lomash wrote:
>
>
> Hi Sean,
>
> Generally, we want some controls to be aligned from both the sides  
> in a column. So, a very common practice is to put them in a column  
> and say align_fill horizontally. But, this solution would not work  
> when we are forced to keep these widgets in separate rows/columns.  
> Then, need for both forward and reverse guides arise (I am not sure  
> if it can be achieved with only one).
>
> In the attached snapshots, there are two scenarios which I am  
> guessing would be solved by the same “trick”. I have been trying to  
> implement them but nothing seems to work fully.
>
> Scenario description:
> There are two scenarios, separated by a thick horizontal like.  
> Assume two separate layouts. None of the widget’s sizes are same by  
> default so we cannot assume that they will  be of the same size  
> without any layout constraints.
> 1.       A widget and a group box in a column, two widgets inside  
> group box. All the 3 widgets should align from both the sides.
> 2.       A row with two widgets, another widget and again a row with  
> two widgets in a column
> The red lines display expected alignments.
>
> Thanks for your help.
>
> Regards,
> Lomash
>
>
>
>

Re: [Adobe-source-devel] Layout issues witn EVE

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

+adobe-source-devel

I'd start by implementing a guide widget and/or an attachment  
attribute. A guide widget is just a widget that has a guide but no  
other dimension. Attachments attributes are a way to decorate an  
existing widget with a guide (such as attaching a guide on the left  
side). Both of these can be done client side, without modifying the  
layout engine.

A couple of fixes/additions to the layout engine may be required to  
make this work well:
	1) There isn't anyway to suppress the spacing on a widget so a guide  
widget will get inter item spacing on both sides. This could be worked  
around with the spacing attribute, but a better fix would be to  
suppress spacing for widgets with no dimension on an axis.
	2) The same bug we discussed before with align fill not obeying  
guides can bite you.

If you implement a guide widget or attachment attributes please  
discuss on the list so we can add the terminology to the standard  
terminology.


A couple of comments on the image -
	For the first case, I'm not a fan of group boxes - too much visual  
clutter. I prefer separator lines. We should still support such  
layouts with the engine though. Adding a guide on each end of the rows  
and fixing (1) should give you this.
	Not sure why the second case can't be handled with two columns.

Sean

On May 14, 2010, at 6:55 AM, Kumar Lomash wrote:

> Hi Sean,
>
> Generally, we want some controls to be aligned from both the sides  
> in a column. So, a very common practice is to put them in a column  
> and say align_fill horizontally. But, this solution would not work  
> when we are forced to keep these widgets in separate rows/columns.  
> Then, need for both forward and reverse guides arise (I am not sure  
> if it can be achieved with only one).
>
> In the attached snapshots, there are two scenarios which I am  
> guessing would be solved by the same “trick”. I have been trying to  
> implement them but nothing seems to work fully.
>
> Scenario description:
> There are two scenarios, separated by a thick horizontal like.  
> Assume two separate layouts. None of the widget’s sizes are same by  
> default so we cannot assume that they will  be of the same size  
> without any layout constraints.
> 1.       A widget and a group box in a column, two widgets inside  
> group box. All the 3 widgets should align from both the sides.
> 2.       A row with two widgets, another widget and again a row with  
> two widgets in a column
> The red lines display expected alignments.
>
> Thanks for your help.
>
> Regards,
> Lomash

[Adobe-source-devel] Thoughts about invariant cell.

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

Hi all,

Image a password input entry in a dialog.  Say, the user-entered password
should obey some rules, each rule corresponds to an invariant cell. We
need:
    If violate invariant cell A, then prompt user "A rule violation"(e.g.
"password too short").

interface:
    password;

invariant:
    len_ok <= check_len(password)
    contains_valid_character <= check_character(password)
    ...

Current "invariant cell" may not play well in this case, since:

   - If password cell is poison, we can't say whether it's too short, or
   contains invalid character, or some other reasons.
   - Adam needs calculate all cells in output_index and then say the
   password field is invalid, compare to the normal "event handler" way --  the
   later will detect an invalid user-entered password quickly.

Shall we need associate a "reason" with an invariant cell? If violate
that invariant
cell, the "reason" will be returned to the client.
Shall we track which invariant cells mark a cell poison?
Shall we try to check the inputs in the beginning of update phrase? Is there
any way?


Regards,
-- cee1

Re: [Adobe-source-devel] asl-users: ADAM cell for default focus in a layout

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

A few comments -

set_default_focus isn't part of the standard terminology:

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

There is nothing in the layout library that deals with focus - this is  
completely external to Eve.

I had started some work on dealing with focus before I left Adobe but  
didn't have a chance to complete it.

There is a single invariant that should hold for focus:  you need to  
be able cycle the focus through all currently visible elements that  
want focus (note that on a Mac, which elements want focus can be  
changed in the preferences - I tend to keep my systems setting to let  
you tab through all controls).

Maintaining this invariant is actually a bit tricky if you want to  
allow some way to specify what is focused next. The solution I had  
come up with is that the focus "ring" starts as an inorder traversal  
of the layout, skipping non-visible items, that circles back from the  
last to the first item. The only allowable operation on this cycle is  
to splice a give range to a particular position. This will always  
maintain a cycle.

Having an attribute that lets you specify the default focus is  
questionable because this would let you specify an item that isn't  
currently visible. However, one could define it to be that the default  
focus moves to the first defaulted item in the view or the first item  
if a defaulted item is not visible. Anytime a focus item is hidden,  
the focus needs to re-find the default (or first visible). This would  
mean that you could have multiple defaults (say one per view).

I'd like to see some UI study on any logic for setting focus beyond  
the above simple rule. I've seen applications remember the focus and  
found that a bit questionable because it means to navigate from the  
keyboard you really need to pay close attention, likewise, any  
programmatic setting of the focus would seem to work against keyboard  
navigation. We also know that relying on focus for UI behaviors often  
breaks accessibility.

So my first questions would be - "why do you want to programmatically  
set the focus? have you done a UI study and accessibility review of  
this solution?"

Foster is correct that the focus doesn't belong in the main sheet (but  
it could be in the layout sheet which can hold UI behaviors and is a  
full Adam sheet in recent builds). Before adding a standard "focus  
cell" though to the layout sheet, I'd want to get answers to the above  
questions.

Declaring the layout sheet (or a portion of one) separate from the  
layout would be fairly trivial, just use a sheet description and then  
feed the same sheet to the layout parser. If anyone want to work on  
the more general problem of a mechanism for compositing sheets so you  
can share logic, let me know - I'd love to discuss it!

Sean


On Feb 23, 2010, at 9:24 AM, Foster Brereton wrote:

> It belongs on the view side. Ideally the only components that exist  
> in the
> model are the ones necessary to construct the command you are  
> getting the
> parameters for via the UI. I say "ideally" because the property  
> model sheet
> is a convenient place to put things related to UI state, like the  
> default
> focus, dynamic button names, etc. I've been thinking about this some  
> and
> wonder if we need separate sheets for the command and UI properties?  
> That
> way the same property model sheet could be used in differing UIs  
> (e.g., a
> dialog and a panel, akin to Photoshop's adjustment dialog/panels in  
> CS4.)
>
> This is a general question, so I'm including the SF mailing list in  
> on it as
> well. Thoughts?
>
> Blessings,
> Foster
>
>
> On 22/02/10 10:28 PM, "Kumar Lomash" <kl...@ad...> wrote:
>
>> Hi,
>>
>> EVE layouts have a ‘set_default_focus’ flag which tells the EVE  
>> engine to give
>> focus to a certain widget when the layout is shown. The problem with
>> specifying this in EVE files is that we cannot decide this based on  
>> current
>> application state, unless of course we bind it an ADAM cell which  
>> we can
>> update dynamically, before layout is created.
>>
>> From a design perspective, is there an issue if UI specific  
>> parameters like
>> default focus are dependent on ADAM cells? From a model-view  
>> separation
>> perspective, where should the default focus flag reside – in the  
>> model or in
>> the view?
>>
>> Regards,
>> Lomash
>
> -- 
> 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
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

Re: [Adobe-source-devel] asl-users: ADAM cell for default focus in a layout

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

It belongs on the view side. Ideally the only components that exist in the
model are the ones necessary to construct the command you are getting the
parameters for via the UI. I say "ideally" because the property model sheet
is a convenient place to put things related to UI state, like the default
focus, dynamic button names, etc. I've been thinking about this some and
wonder if we need separate sheets for the command and UI properties? That
way the same property model sheet could be used in differing UIs (e.g., a
dialog and a panel, akin to Photoshop's adjustment dialog/panels in CS4.)

This is a general question, so I'm including the SF mailing list in on it as
well. Thoughts?

Blessings,
Foster


On 22/02/10 10:28 PM, "Kumar Lomash" <kl...@ad...> wrote:

> Hi,
>  
> EVE layouts have a ‘set_default_focus’ flag which tells the EVE engine to give
> focus to a certain widget when the layout is shown. The problem with
> specifying this in EVE files is that we cannot decide this based on current
> application state, unless of course we bind it an ADAM cell which we can
> update dynamically, before layout is created.
>  
> From a design perspective, is there an issue if UI specific parameters like
> default focus are dependent on ADAM cells? From a model-view separation
> perspective, where should the default focus flag reside – in the model or in
> the view?
>  
> Regards,
> Lomash

-- 
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] Questions about conditional_indirect_contributing_m

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

On Feb 14, 2010, at 2:31 AM, cee1 wrote:

> Hi Sean,
> Thanks for your reply, that's really helpful.
>
> Release 42 was a bit rushed and there are a couple of bugs in the  
> adam code - the current mainline should be in could shape. I'm going  
> to use that code for this discussion - you can see it here:
>
> http://stlab.adobe.com:8080/@lno=y@//adobe_source_libraries/source/adam.cpp?ac=64&rev1=23
>
> I'll checkout the latest code by perforce.
>
> The conditional predicates are evaluated prior to flowing the  
> relationships. conditional_indirect_contributing_m is an  
> accumulation of all cells contributing to the conditional  
> predicates. These indirectly contribute to any cell which is in  
> calculated after.
> My original thought is, some cells may not be involved in  
> conditional relate clause, so their contributing_m should not "|=  
> conditional_indirect_contributing_m"?

It may be overly conservative - I'd have to spend some time looking  
again. The problem is that it is difficult to know how a relate clause  
being active or inactive will effect the system, so the stance is that  
it effects everything.

>
>> What is the difference between output and interface cells?
>
> The implementation of interface cells is a pair of cells,  
> interface_input and interface_output. An interface cell (and only an  
> interface cell) can be involved in a relate clause and  for any  
> state in the system either the input half is contributing or the  
> output half is derived (or both if there is a self-reference loop).
> Can I say "interface cell is invented for the case of (direct or  
> indirect) self-reference"? (In this case, the value of interface  
> cell will either be "state_m of interface cell (input side)" or  
> "term_m() of interface cell(output side)"?)

The name "interface" comes from their duel role of input/output. If  
you get the value of the cell, you always get the value of the term  
unless it is a self-reference (that is, you are getting the value of  
the cell as part of evaluating the term on the cell:

A term is always present - The following two statements are equivalent:

interface:
	a;

interface:
	a <== a;

Because of the duel role that interface cells have, they are the only  
cells that can appear in a relate clause.

>
>
>> Data flow of various cells? (e.g. data from input cell only flow to  
>> output|interface cell? output|interface cell only accept data from  
>> input cell?)
>
> See slide 66 here <http://stlab.adobe.com/wiki/images/0/00/2008_04_03_accu.pdf 
> >
> I don't learn the detailed scenario of adam very well. The slide  
> shows me some, very helpful.
>
>> What is invariant cell doing? If an invariant cell evaluated  
>> "false", all cells contributing to it will be marked poison?
>
> Correct, and then any cell derived from poison is marked as invalid.  
> Consider a simple form where you must specify an age and the age  
> must not be less than 21.
> What if an invariant cell evaluated "false" because the value of one  
> contributing cell is invalid (say other contributing cells have  
> valid values),

The definition of if a cell is poison is if it contributes to an  
invariant - so you can't really say a single invariant was violated  
because of any particular cell contributing to it - all cells  
contributing to it cause the problem.

> then any cell derived from those "other" valid contributing cells is  
> marked as invalid?
> Should I write "proper granularity" of invariant cell to avoid this  
> problem?

Yes - each invariant should test a unique issue.

There is an issue I'd like to get around to fixing with invariants -  
they currently aren't associated with any particular output cell  
(except through the dependencies) - so lets say you wanted a sheet  
with two main results - one is going to be used for shipping USPS, the  
other by Fed-Ex you might want something like:

invariant:
	can_fedex <== is_not_po_box(address);
output:
	fedex <== [address, purchase];
         usps <== [address, purchase];

But you can't do this, because the can_fedex test will poison the  
address and make usps invalid as well. You can hack it with something  
like:

interface:
  //...
    poison : false;
invariant:
    invalid <== poison;
logic:
    can_fedex <== is_not_po_box(address);
output:
    fedex <== [can_fedex ? address : poison, purchase];
    usps <== [address, purchase];
}

The initial design was considering multiple actions being bound to the  
same sheet. Ideally, an invariant could be associated directly with an  
output cell.


>
>
> Thanks
> -- cee1

Re: [Adobe-source-devel] Questions about conditional_indirect_contributing_m

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

Hi Sean,
Thanks for your reply, that's really helpful.

Release 42 was a bit rushed and there are a couple of bugs in the adam code
> - the current mainline should be in could shape. I'm going to use that code
> for this discussion - you can see it here:
>
>
> http://stlab.adobe.com:8080/@lno=y@//adobe_source_libraries/source/adam.cpp?ac=64&rev1=23
>
> I'll checkout the latest code by perforce.

The conditional predicates are evaluated prior to flowing the relationships.
> conditional_indirect_contributing_m is an accumulation of all cells
> contributing to the conditional predicates. These indirectly contribute to
> any cell which is in calculated after.
>
My original thought is, some cells may not be involved in conditional relate
clause, so their contributing_m should not
"|= conditional_indirect_contributing_m"?


>    - What is the difference between output and interface cells?
>
> The implementation of interface cells is a pair of cells, interface_input
> and interface_output. An interface cell (and only an interface cell) can be
> involved in a relate clause and  for any state in the system either the
> input half is contributing or the output half is derived (or both if there
> is a self-reference loop).
>
Can I say "interface cell is invented for the case of (direct or indirect)
self-reference"? (In this case, the value of interface cell will either be
"state_m of interface cell (input side)" or "term_m() of interface
cell(output side)"?)


>
>    - Data flow of various cells? (e.g. data from input cell only flow to
>    output|interface cell? output|interface cell only accept data from input
>    cell?)
>
>
> See slide 66 here <
> http://stlab.adobe.com/wiki/images/0/00/2008_04_03_accu.pdf>
>
I don't learn the detailed scenario of adam very well. The slide shows me
some, very helpful.


>    - What is invariant cell doing? If an invariant cell evaluated "false",
>    all cells contributing to it will be marked poison?
>
> Correct, and then any cell derived from poison is marked as invalid.
> Consider a simple form where you must specify an age and the age must not be
> less than 21.
>
What if an invariant cell evaluated "false" because the value of
one contributing cell is invalid (say other contributing cells have valid
values), then any cell derived from those "other" valid contributing cells
is marked as invalid?
Should I write "proper granularity" of invariant cell to avoid this problem?


Thanks
-- cee1

Re: [Adobe-source-devel] Questions about conditional_indirect_contributing_m

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

Hi cee1,

Release 42 was a bit rushed and there are a couple of bugs in the adam  
code - the current mainline should be in could shape. I'm going to use  
that code for this discussion - you can see it here:

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

On Feb 13, 2010, at 3:21 AM, cee1 wrote:

> Hi all,
> I'm reading the code of asl 1.0.42.
> Some questions about conditional_indirect_contributing_m:
> I found "conditional_indirect_contributing_m" (data member of  
> sheet_t::implementation_t) is only set in function  
> sheet_t::implementation_t::update:
> (adam.cpp, 1119) accumulate_contributing_m.reset ();

Adjusting line numbers:

  1162.	    accumulate_contributing_m.reset();
> ...
> (adam.cpp, 1143) conditional_indirect_contributing_m =  
> accumulate_contributing_m;

And:

  1186.	    conditional_indirect_contributing_m =  
accumulate_contributing_m;

>
> It seems conditional_indirect_contributing_m will always be zero,  
> and is referenced as "a_variable |=  
> conditional_indirect_contributing_m", should it be useless? What is  
> conditional_indirect_contributing_m doing?


No - accumulate_contributing_m is a member variable and will  
accumulate bits (denoting cells) as variables are looked up when a  
cell expression is evaluated (variable lookup is bound to  
sheet_t::get()). Same discussion as on this prior thread <http://sourceforge.net/mailarchive/forum.php?thread_name=999EDB9A-2AFD-4E03-B3BA-97C1193FB8F1%40mac.com&forum_name=adobe-source-devel 
 >.

> What is conditional_indirect_contributing_m doing?


A relation can be conditional using a when() clause:

when (p) relate {
	x <== y;
	y <== x;
}

The conditional predicates are evaluated prior to flowing the  
relationships. conditional_indirect_contributing_m is an accumulation  
of all cells contributing to the conditional predicates. These  
indirectly contribute to any cell which is in calculated after.

>
> BTW, I've read the introduction at http://stlab.adobe.com and the  
> paper "Property Models -- From Incidental Algorithms to Reusable  
> Components", I'm still confused about:
> What is the difference between output and interface cells?
The implementation of interface cells is a pair of cells,  
interface_input and interface_output. An interface cell (and only an  
interface cell) can be involved in a relate clause and  for any state  
in the system either the input half is contributing or the output half  
is derived (or both if there is a self-reference loop).

> Data flow of various cells? (e.g. data from input cell only flow to  
> output|interface cell? output|interface cell only accept data from  
> input cell?)

See slide 66 here <http://stlab.adobe.com/wiki/images/0/00/2008_04_03_accu.pdf 
 >

> What is the difference between input and interface cells(e.g. why  
> input cell setting init_contributing_m while interface cell(input)  
> setting contributing_m)?

Interface cells are used to seed the sheet during initialization. We  
track the contributing values during initialization because a sheet  
can be "re-initialized" (this would happen if the state of something  
the sheet relies on was updated outside of the sheet). An input cell's  
value can only be set from code external to the sheet, where as the  
value in an interface cell (input side) can be applied from the output  
side fo the same cell. You can only bind an interface cell to  
something like an edit text widget because the input side can be set  
(controller side of widget) and the output side is displayed (view  
side of widget).

> Are relation cells only involved in "getting" value of interface  
> cells (output)?
A relation cell holds the bundle of expressions that binds the input  
side of the interface cell to the output side of the interface cell,  
along with any conditional predicates.

> What is invariant cell doing? If an invariant cell evaluated  
> "false", all cells contributing to it will be marked poison?
Correct, and then any cell derived from poison is marked as invalid.  
Consider a simple form where you must specify an age and the age must  
not be less than 21.

sheet drinking_test {
   interface:
     age : 0;
   invariant:
    age_test <==  !(age < 21);
   output:
    result <== age;
}

A layout to bind to this might look like:

layout drinking_test {
	view dialog() {
		edit_number(name: "Age", bind: @age);
		button(name: "Drink!", bind: @result);
	}
}

Here if age < 21 then age_test is false so age is marked as poison,  
result is derived from age so it is marked as invalid. The Drink!  
button, which is bound to result, will use the invalid flag to control  
enablement and will be disabled (a button invokes some function, and  
the value it is bound to is the arguments to that function, so if the  
arguments are invalid, then the pre-conditions of the function are not  
satisfied, and the button is disabled).

Hope that help,
Sean


>
> Regards
> -- cee1
> ------------------------------------------------------------------------------
> SOLARIS 10 is the OS for Data Centers - provides features such as  
> DTrace,
> Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
> http://p.sf.net/sfu/solaris-dev2dev_______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] Questions about conditional_indirect_contributing_m

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

Hi all,
I'm reading the code of asl 1.0.42.
Some questions about *conditional_indirect_contributing_m*:
I found "*conditional_indirect_contributing_m*" (data member of
sheet_t::implementation_t) is *only set* in function
sheet_t::implementation_t::update:
(adam.cpp, 1119) accumulate_contributing_m.reset ();
...
(adam.cpp, 1143) conditional_indirect_contributing_m
= accumulate_contributing_m;

It seems conditional_indirect_contributing_m will always be zero, and is
referenced as "a_variable |= conditional_indirect_contributing_m", should it
be useless? What is conditional_indirect_contributing_m doing?

BTW, I've read the introduction at http://stlab.adobe.com and the paper
"Property Models -- From Incidental Algorithms to Reusable Components", I'm
still confused about:

   - What is the difference between output and interface cells?
   - Data flow of various cells? (e.g. data from input cell only flow to
   output|interface cell? output|interface cell only accept data from input
   cell?)
   - What is the difference between input and interface cells(e.g. why input
   cell setting init_contributing_m while interface cell(input) setting
   contributing_m)?
   - Are relation cells only involved in "getting" value of interface cells
   (output)?
   - What is invariant cell doing? If an invariant cell evaluated "false",
   all cells contributing to it will be marked poison?


Regards
-- cee1

Re: [Adobe-source-devel] any_regular_t and capacity

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

I don't think anyone has looked into this - you could do this in the  
case the new type is smaller - if you want to go back up then you  
would also need to store the size and that would break ABI  
compaticility (you'd need a version_2 any_regular_t...).

I think reserve() would be tricky because of the small object  
optimization and ABI compatibility. Most of the cases I dealt with  
were small objects (dictionary, adobe::vector, string_t, basic  
types...). Being a small object is one advantage adobe::vector has  
over std::vector.

Sean


On Jan 20, 2010, at 3:15 PM, Florin Trofin wrote:

> Hello,
>
> I know any_regular_t has in-object allocation for types smaller than  
> 8 bytes (64 bits). Larger types are allocated on the heap. Consider  
> this scenario:
>
> BigObject obj; // 56 bytes->heap
> any_regular_t value(obj);
> [...]
> SmallerObject obj2; // 24 bytes
> value.assign(obj2); // destroys current object and re-allocates
>
> I looked at how any_regular_t::assign is implemented and it tries to  
> preserve its capacity if the new type is the same as the existing  
> one. If not, it destroys the guts of the current object and re- 
> allocates.
>
> Since heap allocations are expensive and a major bottleneck for  
> scalability I was wondering if anybody considered worth implementing  
> an optimization that checks if the current capacity is enough when  
> re-assigning. A reserve() and clear() methods would be a nice bonus.
>
> Best regards,
>
> Florin
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel

[Adobe-source-devel] any_regular_t and capacity

[Florin T. <fl...@gm...>]

Hello,

I know any_regular_t has in-object allocation for types smaller than 8 bytes
(64 bits). Larger types are allocated on the heap. Consider this scenario:

BigObject obj; // 56 bytes->heap
any_regular_t value(obj);
[...]
SmallerObject obj2; // 24 bytes
value.assign(obj2); // destroys current object and re-allocates

I looked at how any_regular_t::assign is implemented and it tries to
preserve its capacity if the new type is the same as the existing one. If
not, it destroys the guts of the current object and re-allocates.

Since heap allocations are expensive and a major bottleneck for scalability
I was wondering if anybody considered worth implementing an optimization
that checks if the current capacity is enough when re-assigning. A reserve()
and clear() methods would be a nice bonus.

Best regards,

Florin

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

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

On Dec 14, 2009, at 6:03 AM, cee1 wrote:

> Hi Sean,
>
> Thanks for the replay.
> I'm reading code of ASL 1.0.42.

Okay - that should be here <http://stlab.adobe.com:8080/@lno=y@//source_release/source/adam.cpp?ac=64&rev1=11 
 >


>> In the function sheet_t::implementation_t::get:
>> (adam.cpp 1387) "if (initialize_mode_m) { ..."
>> I've found initialize_mode_m is false when instantiates  
>> sheet_t::implementation_t, and will be true when calls  
>> add_constant, add_input or add_interface. So the following assert  
>> should always fail:
>
> (line 1435 in my copy) When a sheet is constructed, initializers are  
> evaluated as  the cells are added. the get() function is called by  
> the expression evaluator to look up variables. The expressions on a  
> sheet initializer can only refer to cells that have been previously  
> declared (added to the sheet) and the initializers don't attempt to  
> follow relationships, they only pick up the cell value of previously  
> initialized cells.
>
> Is "sheet_t::implementation_t::get" (only) directly used in the  
> following line? (i.e. when an interface cell has no define  
> expression):
>   799.	        cell_set_m.push_back(cell_t(access_interface_output,  
> name,
>   800.	                                     
> boost::bind(&implementation_t::get, boost::ref(*this), name),
>   801.	                                    cell_set_m.size(),  
> &cell_set_m.back()));

When there is no define expression it is equivalent to  a <== a. This  
call binds ::get() to the cell to implement that expression.

implementation_t::get can also be called from sheet_t::get. It is part  
of the public interface to a sheet.
   611.	any_regular_t sheet_t::get(name_t cell)
   612.	{ return object_m->get(cell); }

>
>> (adam.cpp 1428) assert(cell.interface_input_m && ...),
>> Because when this line is reached, the initialize_mode_m is false,  
>> then we should not have called add_constant, add_input or  
>> add_interface, so the cell is not an interface cell, assert failed.
>
> (line 1476) - there is a return statement on line 1449 so this line  
> is not going to be reached if initialize_mode_m is true.
>
> I found initialize_mode_m is true when:
>   a) reinitialize is called
>   b) add_constant is called
>   c) add_input is called
>   d) add_interface is called
> No place except constructor of sheet_t::implementation_t set  
> initialize_mode_m false.

Yes, it is true for the duration of the scope variable in those calls  
and then restored to it's prior value.

>
> The line 1476: assert(cell.interface_input_m && "FATAL (sparent) :  
> Only interface cells should be on the get stack.");
> That means we expect an interface cell here, but if we have an  
> interface cell, it should be added by add_interface, then  
> initialize_mode_m should be true: this line is not reachable ?
>>
>> Also, I find some code that makes no sense to me, like:
>> (adam.cpp 1267) sheet_t::implementation_t::initialize_one
>> accumulate_contributing_m.reset();
>> ...
>> cell.init_contributing_m |= accumulate_contributing_m;
>
> (1315) accumulate_contributing_m is a member variable that holds a  
> bit field corresponding to cells. Executing calculate_m() on line  
> 1323 is going to set the bits for the cells that are read as part of  
> that expression in accumulate_contributing_m. Then on line 1325 that  
> bit set is or'ed with the other bits contributing to the initializer  
> on that cell.
>
> In many places, calculate_m is a binding function object which is  
> essentially implementation_t::calculate_expression -- this function  
> doesn't touch accumulate_contributing_m.
> But calculate_m can also be a binding function object which is  
> essentially implementation_t::get -- this function touches  
> accumulate_contributing_m.
> Am I right?

calculate_expression calls the virtual machine to evaluate the  
expression, the virtual machine will call sheet_t::get() to do  
variable lookup, this will call implementation_t::get().

>>
>> or
>>
>> (adam.cpp  1173) in function sheet_t::implementation_t::update
>> if (cell.specifier_m == access_interface_output)  
>> get_stack_m.push_back(std::make_pair(cell.name_m, false));
>
> (1221) The get_stack_m is used to detect self-referential  
> expressions in get() (which is called as part of calculating an  
> expression for variable lookup). For example, if you have a rule like:
>
> a <== max(a, b);
>
> Then the lookup of "a" is self referential, and must refer to the  
> initial value of "a", but "b" is not self referential and will refer  
> to the final value of "b".
>
> See line 1475 for where this is used.
>
>> ...
>> if (cell.specifier_m == access_interface_output)  
>> get_stack_m.pop_back();
>
>  Does that means sheet_t::implementation_t::get may be called  
> recursively?

Yes. Getting the value of a cell may cause that's cell expression to  
be evaluated (see calls to cell.calculate()), this will invoke the  
virtual machine and may call back sheet_t::get() to do a variable  
lookup.


>>
>>
>> Sorry for this mass mail, but I feel lost in adam.cpp. Could  
>> someone show me the global picture of how these functions in  
>> sheet_t::implementation work?
>
> No problem - keep the questions coming.
>
> Thank you.
>
>
> Regards,
> - cee1

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

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

Hi Sean,

Thanks for the replay.
I'm reading code of ASL 1.0.42.

> In the function sheet_t::implementation_t::get:
> (adam.cpp 1387) "if (initialize_mode_m) { ..."
> I've found initialize_mode_m is false when instantiates
> sheet_t::implementation_t, and will be true when calls add_constant,
> add_input or add_interface. So the following assert should always fail:
>
>
> (line 1435 in my copy) When a sheet is constructed, initializers are
> evaluated as  the cells are added. the get() function is called by the
> expression evaluator to look up variables. The expressions on a sheet
> initializer can only refer to cells that have been previously declared
> (added to the sheet) and the initializers don't attempt to follow
> relationships, they only pick up the cell value of previously initialized
> cells.
>
> Is "sheet_t::implementation_t::get" (only) directly used in the following
line? (i.e. when an interface cell has no define expression):
  799.        cell_set_m.push_back(cell_t(access_interface_output, name,
  800.
 boost::bind(&implementation_t::get, boost::ref(*this), name),
  801.                                    cell_set_m.size(),
&cell_set_m.back()));


> (adam.cpp 1428) assert(cell.interface_input_m && ...),
> Because when this line is reached, the initialize_mode_m is false, then we
> should not have called add_constant, add_input or add_interface, so the cell
> is not an interface cell, assert failed.
>
>
> (line 1476) - there is a return statement on line 1449 so this line is not
> going to be reached if initialize_mode_m is true.
>
> I found initialize_mode_m is true when:
  a) reinitialize is called
  b) add_constant is called
  c) add_input is called
  d) add_interface is called
No place except constructor of sheet_t::implementation_t set
initialize_mode_m false.

The line 1476: assert(cell.interface_input_m && "FATAL (sparent) : Only
interface cells should be on the get stack.");
That means we expect an interface cell here, but if we have an interface
cell, it should be added by add_interface, then initialize_mode_m should be
true: this line is not reachable ?

>
> Also, I find some code that makes no sense to me, like:
> (adam.cpp 1267) sheet_t::implementation_t::initialize_one
> accumulate_contributing_m.reset();
> ...
> cell.init_contributing_m |= accumulate_contributing_m;
>
>
> (1315) accumulate_contributing_m is a member variable that holds a bit
> field corresponding to cells. Executing calculate_m() on line 1323 is going
> to set the bits for the cells that are read as part of that expression in
> accumulate_contributing_m. Then on line 1325 that bit set is or'ed with the
> other bits contributing to the initializer on that cell.
>
> In many places, calculate_m is a binding function object which is
essentially implementation_t::calculate_expression -- this function doesn't
touch accumulate_contributing_m.
But calculate_m can also be a binding function object which
is essentially implementation_t::get -- this function
touches accumulate_contributing_m.
Am I right?

>
> or
>
> (adam.cpp  1173) in function sheet_t::implementation_t::update
> if (cell.specifier_m == access_interface_output)
> get_stack_m.push_back(std::make_pair(cell.name_m, false));
>
>
> (1221) The get_stack_m is used to detect self-referential expressions in
> get() (which is called as part of calculating an expression for variable
> lookup). For example, if you have a rule like:
>
> a <== max(a, b);
>
> Then the lookup of "a" is self referential, and must refer to the initial
> value of "a", but "b" is not self referential and will refer to the final
> value of "b".
>
> See line 1475 for where this is used.
>
> ...
> if (cell.specifier_m == access_interface_output) get_stack_m.pop_back();
>
>  Does that means sheet_t::implementation_t::get may be called recursively?

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

Thank you.


Regards,
- cee1