V2: review request for configure details page

V2: review request for configure details page

[Reyna, David]

Hi Belén,

Thank you for your review. I believe that I have now fixed all of the identified issues, but I did have some observations.

1) "The Description filter should be applied when you load this page"

Ok, I got this to work. Note that the consequence of this is that the title of the page is _never_ "Configuration", but instead is something like "984 variables found", because the filter is now always asserted by default.

2) "But the Set in file heading should be sortable"

Well, I am surprised, I actually got it to mostly work :-O.

    'orderfield': _get_toggle_order(request, "vhistory__file_name"),

When I write "mostly", it does actually sort, but I observe "conf/bitbake" values that get inserted into the sort order. Upon examination, these entries are always the last entry in that entry's history list, where the first element appears to reflect the sort order, it appears to me that the sort system always uses the _first_ element when it encounters a list.

So, in these instances the sort to appear to be broken to the user when the first (and explicitly hidden) file entry is different from the last (shown).

I need to investigate whether the existing sort system allows the specification of custom compare functions in order to force the compare to be against the _last_ entry. The examples I have seen so far only use flat class member specifications.

3) "The path for the bitbake.conf file is not the full path"

Every entry in the database for "bitbake.conf" is "conf/bitbake.conf". These are the only non-full path entries that I have found in the file lists, so I think that this is specific to the respective code in the toast database capture code.

I will file a bug against the toaster backend.

- David

> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Friday, February 14, 2014 8:27 AM
> To: Reyna, David; Damian, Alexandru
> Cc: toaster@yoctoproject.org
> Subject: Re: review request for configure details page
> 
> Thanks, David. Those file filters are really neat :)
> 
> I have reviewed this page. There are a few little things
> implementation-related, and there are other (bigger) issues that are
> design problems.
> 
> The implementation first:
> 
> SUMMARY TAB
> 
> * The Summary values in the Build configuration section don't seem to be
> coming in (for my Beagleboard build, I see machine 'atom-pc', which
> doesn't seem right). That section should list:
> 
> ** BitBake version (BB_VERSION)
> 
> ** Build system (BUILD_SYS)
> 
> ** Host distribution (NATIVELSBSTRING)
> 
> ** Target system (TARGET_SYS)
> 
> ** Machine (MACHINE)
> 
> ** Distro (DISTRO)
> 
> ** Distro version (DISTRO_VERSION)
> 
> ** Tune features (TUNE_FEATURES)
> 
> ** Target FPU (TARGET_FPU)
> 
> ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you are
> building (e.g. core-image-minimal). If more than one, please mark them up
> within an unnumbered list (<ul>)
> 
> If any of the above variables has no value, we don't list the variable
> 
> * We should take out the blue icon next to the layer name
> 
> BITBAKE VARIABLES TAB
> 
> * The Description filter should be applied when you load this page
> 
> * The Value heading is not sortable
> 
> * But the Set in file heading should be sortable
> 
> * The path for the bitbake.conf file is not the full path (it only says
> conf/bitbake.conf)
> 
> * In the filter modal dialogs, the headings and the "All" radio button
> labels say "configvars" instead of "variables". This also happens in the
> applied filter tooltip (in the "Show all" button) and in the placeholder
> text in the search input field (which should say "Search BitBake
> variables")
> 
> There are also some design problems with this page that I need to think
> about:
> 
> 
> * As it was designed, the modal dialog for the history should only exist
> if the number of config files touching the variable is higher than one.
> This causes a few issues:
> 
> ** how do we show the operation and line number for the variables touched
> by only one file?
> 
> 
> ** Search and filtering work across all entries, which means it might not
> be obvious why you get certain results since they are hidden inside the
> history modal dialog
> 
> 
> * How do we deal with very long values (both in the table and in the
> history modal dialogs)?
> 
> * The design specification says that the page h1 should not be manipulated
> by search results: for pages with tabs, like this one, it says to display
> a h2 right above the search field with the number of results returned by
> the search query. Having said that, I am not particularly happy with that
> design either. On the other hand, manipulating the h1 causes some weird
> interactions in the page that could be confusing. This is the kind of
> thing you need to test with users to actually find out. I am inclined to
> leave it as is for the moment, and see how it goes. We can always refine
> it in the next release cycle.
> 
> 
> * What do we do with the B_* variables (in a core-image-minimal build you
> get about 600 of those). We knew we were going to hit this problem at some
> point, but I am not sure how we can exclude those entries within our
> existing filtering patterns. The only easy solution seems to be removing
> the B variable from documentation.conf, which means that neither B nor any
> of the 600 B_* variables will show by default, since we apply the
> Variables with description filter.
> 
> * I have been thinking about how we can keep the links to the full
> variable descriptions in the Yocto Project manual. Right now, we do know
> that an entry in the manual exists for each variable that has a
> description, so it is safe to show the link. We also know their structure
> should be:
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var- +
> <variableName>
> 
> For example:
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ALL
> OW_EMPTY
> 
> The question is: what's the best way to generate the URLs?
> 
> 
> Sorry for the brain dump: I thought I'd share my pains with you all ;) I
> will try and look into the design issues above as soon as possible. If you
> have any suggestions for any of them, please let me know.
> 
> Belén
> 
> 
> On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
> 
> >Hi again,
> >
> >> ³I have the filter for the descriptions, but is depends on the presence
> >>of a space character²
> >
> >Ok, I was able to redo and push the filter using a regex, so that will
> >allow the possibility of a description that has characters but no spaces.
> >
> >    ('Show only variables with description', 'description__regex:.+'),
> >
> >- David
> >
> >From: toaster-bounces@yoctoproject.org
> >[mailto:toaster-bounces@yoctoproject.org]
> >On Behalf Of Reyna, David
> >Sent: Friday, February 14, 2014 1:20 AM
> >To: belen.barros.pena@intel.com; Damian, Alexandru
> >(alexandru.damian@intel.com)
> >Cc: toaster@yoctoproject.org
> >Subject: [Toaster] review request for configure details page
> >
> >
> >
> >Hi Belen and Alex,
> >
> >
> >
> >I have the configuration page ready for review at:
> >³dreyna/configure-detail-view²
> >
> >
> >
> >Implementation Notes:
> >
> >
> >
> >* In the file list pop-up dialog, I truncate the variable¹s value to 200
> >characters max.
> >
> >
> >
> >
> >The reason is that I discovered for variables (like ³BBINCLUDE²) with
> >very long values, the pop-up is in fact unable by design to scroll to the
> >end, to show the file list.
> > I think that 200 characters give the right idea, and the result looks
> >consistent with the more normal pop-ups.
> >
> >
> >
> >* I have the file filters working for each of the indicated categories.
> >
> >
> >
> >
> >I will note that in my examinations that there were a few file types that
> >were not covered by the existing categories, and I wondered if you were
> >ok that.
> >
> >
> >
> >    poky/meta/classes/*
> >
> >    poky/bitbake/lib/bb/*
> >
> >
> >
> >* I have the filter for the descriptions.
> >
> >
> >
> >I ended on filtering on the presence of a space character, because I
> >could not find an appropriate alternate field lookup. I suppose I could
> >try a regex test.
> >
> >
> >
> >* I implemented the file list such the last file is the one shown.
> >
> >
> >
> >I was however curious if it is absolutely the case that the foreign key
> >select on the VariableHistory table is guaranteed to be in time order. I
> >did manually examine the
> > first 100 rows and found that indeed that the rows were in primary key
> >sequential order, but that is not proof.
> >
> >
> >
> >Thanks,
> >
> >David
> >
> >
> >
> >
> >
> >
> >
> 

Re: V2: review request for configure details page

[Damian, Alexandru]

[-- Attachment #1: Type: text/plain, Size: 10304 bytes --]

On Fri, Feb 14, 2014 at 9:11 PM, Reyna, David <david.reyna@windriver.com>wrote:

> Hi Belén,
>
> Thank you for your review. I believe that I have now fixed all of the
> identified issues, but I did have some observations.
>
> 1) "The Description filter should be applied when you load this page"
>
> Ok, I got this to work. Note that the consequence of this is that the
> title of the page is _never_ "Configuration", but instead is something like
> "984 variables found", because the filter is now always asserted by default.
>
> 2) "But the Set in file heading should be sortable"
>
> Well, I am surprised, I actually got it to mostly work :-O.
>
>     'orderfield': _get_toggle_order(request, "vhistory__file_name"),
>
> When I write "mostly", it does actually sort, but I observe "conf/bitbake"
> values that get inserted into the sort order. Upon examination, these
> entries are always the last entry in that entry's history list, where the
> first element appears to reflect the sort order, it appears to me that the
> sort system always uses the _first_ element when it encounters a list.
>
> So, in these instances the sort to appear to be broken to the user when
> the first (and explicitly hidden) file entry is different from the last
> (shown).
>
> I need to investigate whether the existing sort system allows the
> specification of custom compare functions in order to force the compare to
> be against the _last_ entry. The examples I have seen so far only use flat
> class member specifications.
>

​[Alex] maybe I need to redo the DB schema to hold the file list in a
different table. Right now it's a single field because it comes as a text
field from Bitbake, but if needed, we can change that. A second option is
implement a custom sort using a lambda expression in the VariableHistory
model, instead of relying on the default sort. I would guess second option
is way faster and less intrusive, and more in the spirit of Bitbake, but
going for the first option is a new requirement that requires the
VariableHistory change anyway (
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5811). So don't worry
about this specific detail, I will implement it.



>
> 3) "The path for the bitbake.conf file is not the full path"
>
> Every entry in the database for "bitbake.conf" is "conf/bitbake.conf".
> These are the only non-full path entries that I have found in the file
> lists, so I think that this is specific to the respective code in the toast
> database capture code.
>
> I will file a bug against the toaster backend.
>
> - David
>
> > -----Original Message-----
> > From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> > Sent: Friday, February 14, 2014 8:27 AM
> > To: Reyna, David; Damian, Alexandru
> > Cc: toaster@yoctoproject.org
> > Subject: Re: review request for configure details page
> >
> > Thanks, David. Those file filters are really neat :)
> >
> > I have reviewed this page. There are a few little things
> > implementation-related, and there are other (bigger) issues that are
> > design problems.
> >
> > The implementation first:
> >
> > SUMMARY TAB
> >
> > * The Summary values in the Build configuration section don't seem to be
> > coming in (for my Beagleboard build, I see machine 'atom-pc', which
> > doesn't seem right). That section should list:
> >
> > ** BitBake version (BB_VERSION)
> >
> > ** Build system (BUILD_SYS)
> >
> > ** Host distribution (NATIVELSBSTRING)
> >
> > ** Target system (TARGET_SYS)
> >
> > ** Machine (MACHINE)
> >
> > ** Distro (DISTRO)
> >
> > ** Distro version (DISTRO_VERSION)
> >
> > ** Tune features (TUNE_FEATURES)
> >
> > ** Target FPU (TARGET_FPU)
> >
> > ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you
> are
> > building (e.g. core-image-minimal). If more than one, please mark them up
> > within an unnumbered list (<ul>)
> >
> > If any of the above variables has no value, we don't list the variable
> >
> > * We should take out the blue icon next to the layer name
> >
> > BITBAKE VARIABLES TAB
> >
> > * The Description filter should be applied when you load this page
> >
> > * The Value heading is not sortable
> >
> > * But the Set in file heading should be sortable
> >
> > * The path for the bitbake.conf file is not the full path (it only says
> > conf/bitbake.conf)
> >
> > * In the filter modal dialogs, the headings and the "All" radio button
> > labels say "configvars" instead of "variables". This also happens in the
> > applied filter tooltip (in the "Show all" button) and in the placeholder
> > text in the search input field (which should say "Search BitBake
> > variables")
> >
> > There are also some design problems with this page that I need to think
> > about:
> >
> >
> > * As it was designed, the modal dialog for the history should only exist
> > if the number of config files touching the variable is higher than one.
> > This causes a few issues:
> >
> > ** how do we show the operation and line number for the variables touched
> > by only one file?
> >
> >
> > ** Search and filtering work across all entries, which means it might not
> > be obvious why you get certain results since they are hidden inside the
> > history modal dialog
> >
> >
> > * How do we deal with very long values (both in the table and in the
> > history modal dialogs)?
> >
> > * The design specification says that the page h1 should not be
> manipulated
> > by search results: for pages with tabs, like this one, it says to display
> > a h2 right above the search field with the number of results returned by
> > the search query. Having said that, I am not particularly happy with that
> > design either. On the other hand, manipulating the h1 causes some weird
> > interactions in the page that could be confusing. This is the kind of
> > thing you need to test with users to actually find out. I am inclined to
> > leave it as is for the moment, and see how it goes. We can always refine
> > it in the next release cycle.
> >
> >
> > * What do we do with the B_* variables (in a core-image-minimal build you
> > get about 600 of those). We knew we were going to hit this problem at
> some
> > point, but I am not sure how we can exclude those entries within our
> > existing filtering patterns. The only easy solution seems to be removing
> > the B variable from documentation.conf, which means that neither B nor
> any
> > of the 600 B_* variables will show by default, since we apply the
> > Variables with description filter.
> >
> > * I have been thinking about how we can keep the links to the full
> > variable descriptions in the Yocto Project manual. Right now, we do know
> > that an entry in the manual exists for each variable that has a
> > description, so it is safe to show the link. We also know their structure
> > should be:
> >
> > http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-+
> > <variableName>
> >
> > For example:
> >
> >
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ALL
> > OW_EMPTY
> >
> > The question is: what's the best way to generate the URLs?
> >
> >
> > Sorry for the brain dump: I thought I'd share my pains with you all ;) I
> > will try and look into the design issues above as soon as possible. If
> you
> > have any suggestions for any of them, please let me know.
> >
> > Belén
> >
> >
> > On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
> >
> > >Hi again,
> > >
> > >> ³I have the filter for the descriptions, but is depends on the
> presence
> > >>of a space character²
> > >
> > >Ok, I was able to redo and push the filter using a regex, so that will
> > >allow the possibility of a description that has characters but no
> spaces.
> > >
> > >    ('Show only variables with description', 'description__regex:.+'),
> > >
> > >- David
> > >
> > >From: toaster-bounces@yoctoproject.org
> > >[mailto:toaster-bounces@yoctoproject.org]
> > >On Behalf Of Reyna, David
> > >Sent: Friday, February 14, 2014 1:20 AM
> > >To: belen.barros.pena@intel.com; Damian, Alexandru
> > >(alexandru.damian@intel.com)
> > >Cc: toaster@yoctoproject.org
> > >Subject: [Toaster] review request for configure details page
> > >
> > >
> > >
> > >Hi Belen and Alex,
> > >
> > >
> > >
> > >I have the configuration page ready for review at:
> > >³dreyna/configure-detail-view²
> > >
> > >
> > >
> > >Implementation Notes:
> > >
> > >
> > >
> > >* In the file list pop-up dialog, I truncate the variable¹s value to 200
> > >characters max.
> > >
> > >
> > >
> > >
> > >The reason is that I discovered for variables (like ³BBINCLUDE²) with
> > >very long values, the pop-up is in fact unable by design to scroll to
> the
> > >end, to show the file list.
> > > I think that 200 characters give the right idea, and the result looks
> > >consistent with the more normal pop-ups.
> > >
> > >
> > >
> > >* I have the file filters working for each of the indicated categories.
> > >
> > >
> > >
> > >
> > >I will note that in my examinations that there were a few file types
> that
> > >were not covered by the existing categories, and I wondered if you were
> > >ok that.
> > >
> > >
> > >
> > >    poky/meta/classes/*
> > >
> > >    poky/bitbake/lib/bb/*
> > >
> > >
> > >
> > >* I have the filter for the descriptions.
> > >
> > >
> > >
> > >I ended on filtering on the presence of a space character, because I
> > >could not find an appropriate alternate field lookup. I suppose I could
> > >try a regex test.
> > >
> > >
> > >
> > >* I implemented the file list such the last file is the one shown.
> > >
> > >
> > >
> > >I was however curious if it is absolutely the case that the foreign key
> > >select on the VariableHistory table is guaranteed to be in time order. I
> > >did manually examine the
> > > first 100 rows and found that indeed that the rows were in primary key
> > >sequential order, but that is not proof.
> > >
> > >
> > >
> > >Thanks,
> > >
> > >David
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
>


-- 
Alex Damian
Yocto Project
SSG / OTC

[-- Attachment #2: Type: text/html, Size: 13475 bytes --]

Re: V2: review request for configure details page

[Barros Pena, Belen]

On 14/02/2014 21:11, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi Belén,
>
>Thank you for your review. I believe that I have now fixed all of the
>identified issues, but I did have some observations.
>
>1) "The Description filter should be applied when you load this page"
>
>Ok, I got this to work. Note that the consequence of this is that the
>title of the page is _never_ "Configuration", but instead is something
>like "984 variables found", because the filter is now always asserted by
>default.

I can see that. I think we can leave it as is for the moment. If it turns
out to be confusing for users, we'll hear about it :)

>
>2) "But the Set in file heading should be sortable"
>
>Well, I am surprised, I actually got it to mostly work :-O.
>
>    'orderfield': _get_toggle_order(request, "vhistory__file_name"),
>
>When I write "mostly", it does actually sort, but I observe
>"conf/bitbake" values that get inserted into the sort order. Upon
>examination, these entries are always the last entry in that entry's
>history list, where the first element appears to reflect the sort order,
>it appears to me that the sort system always uses the _first_ element
>when it encounters a list.
>
>So, in these instances the sort to appear to be broken to the user when
>the first (and explicitly hidden) file entry is different from the last
>(shown).
>
>I need to investigate whether the existing sort system allows the
>specification of custom compare functions in order to force the compare
>to be against the _last_ entry. The examples I have seen so far only use
>flat class member specifications.
>
>3) "The path for the bitbake.conf file is not the full path"
>
>Every entry in the database for "bitbake.conf" is "conf/bitbake.conf".
>These are the only non-full path entries that I have found in the file
>lists, so I think that this is specific to the respective code in the
>toast database capture code.
>
>I will file a bug against the toaster backend.
>
>- David
>
>> -----Original Message-----
>> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
>> Sent: Friday, February 14, 2014 8:27 AM
>> To: Reyna, David; Damian, Alexandru
>> Cc: toaster@yoctoproject.org
>> Subject: Re: review request for configure details page
>> 
>> Thanks, David. Those file filters are really neat :)
>> 
>> I have reviewed this page. There are a few little things
>> implementation-related, and there are other (bigger) issues that are
>> design problems.
>> 
>> The implementation first:
>> 
>> SUMMARY TAB
>> 
>> * The Summary values in the Build configuration section don't seem to be
>> coming in (for my Beagleboard build, I see machine 'atom-pc', which
>> doesn't seem right). That section should list:
>> 
>> ** BitBake version (BB_VERSION)
>> 
>> ** Build system (BUILD_SYS)
>> 
>> ** Host distribution (NATIVELSBSTRING)
>> 
>> ** Target system (TARGET_SYS)
>> 
>> ** Machine (MACHINE)
>> 
>> ** Distro (DISTRO)
>> 
>> ** Distro version (DISTRO_VERSION)
>> 
>> ** Tune features (TUNE_FEATURES)
>> 
>> ** Target FPU (TARGET_FPU)
>> 
>> ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you
>>are
>> building (e.g. core-image-minimal). If more than one, please mark them
>>up
>> within an unnumbered list (<ul>)
>> 
>> If any of the above variables has no value, we don't list the variable
>> 
>> * We should take out the blue icon next to the layer name
>> 
>> BITBAKE VARIABLES TAB
>> 
>> * The Description filter should be applied when you load this page
>> 
>> * The Value heading is not sortable
>> 
>> * But the Set in file heading should be sortable
>> 
>> * The path for the bitbake.conf file is not the full path (it only says
>> conf/bitbake.conf)
>> 
>> * In the filter modal dialogs, the headings and the "All" radio button
>> labels say "configvars" instead of "variables". This also happens in the
>> applied filter tooltip (in the "Show all" button) and in the placeholder
>> text in the search input field (which should say "Search BitBake
>> variables")
>> 
>> There are also some design problems with this page that I need to think
>> about:
>> 
>> 
>> * As it was designed, the modal dialog for the history should only exist
>> if the number of config files touching the variable is higher than one.
>> This causes a few issues:
>> 
>> ** how do we show the operation and line number for the variables
>>touched
>> by only one file?
>> 
>> 
>> ** Search and filtering work across all entries, which means it might
>>not
>> be obvious why you get certain results since they are hidden inside the
>> history modal dialog
>> 
>> 
>> * How do we deal with very long values (both in the table and in the
>> history modal dialogs)?
>> 
>> * The design specification says that the page h1 should not be
>>manipulated
>> by search results: for pages with tabs, like this one, it says to
>>display
>> a h2 right above the search field with the number of results returned by
>> the search query. Having said that, I am not particularly happy with
>>that
>> design either. On the other hand, manipulating the h1 causes some weird
>> interactions in the page that could be confusing. This is the kind of
>> thing you need to test with users to actually find out. I am inclined to
>> leave it as is for the moment, and see how it goes. We can always refine
>> it in the next release cycle.
>> 
>> 
>> * What do we do with the B_* variables (in a core-image-minimal build
>>you
>> get about 600 of those). We knew we were going to hit this problem at
>>some
>> point, but I am not sure how we can exclude those entries within our
>> existing filtering patterns. The only easy solution seems to be removing
>> the B variable from documentation.conf, which means that neither B nor
>>any
>> of the 600 B_* variables will show by default, since we apply the
>> Variables with description filter.
>> 
>> * I have been thinking about how we can keep the links to the full
>> variable descriptions in the Yocto Project manual. Right now, we do know
>> that an entry in the manual exists for each variable that has a
>> description, so it is safe to show the link. We also know their
>>structure
>> should be:
>> 
>> 
>>http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-
>>+
>> <variableName>
>> 
>> For example:
>> 
>> 
>>http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-A
>>LL
>> OW_EMPTY
>> 
>> The question is: what's the best way to generate the URLs?
>> 
>> 
>> Sorry for the brain dump: I thought I'd share my pains with you all ;) I
>> will try and look into the design issues above as soon as possible. If
>>you
>> have any suggestions for any of them, please let me know.
>> 
>> Belén
>> 
>> 
>> On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
>> 
>> >Hi again,
>> >
>> >> ³I have the filter for the descriptions, but is depends on the
>>presence
>> >>of a space character²
>> >
>> >Ok, I was able to redo and push the filter using a regex, so that will
>> >allow the possibility of a description that has characters but no
>>spaces.
>> >
>> >    ('Show only variables with description', 'description__regex:.+'),
>> >
>> >- David
>> >
>> >From: toaster-bounces@yoctoproject.org
>> >[mailto:toaster-bounces@yoctoproject.org]
>> >On Behalf Of Reyna, David
>> >Sent: Friday, February 14, 2014 1:20 AM
>> >To: belen.barros.pena@intel.com; Damian, Alexandru
>> >(alexandru.damian@intel.com)
>> >Cc: toaster@yoctoproject.org
>> >Subject: [Toaster] review request for configure details page
>> >
>> >
>> >
>> >Hi Belen and Alex,
>> >
>> >
>> >
>> >I have the configuration page ready for review at:
>> >³dreyna/configure-detail-view²
>> >
>> >
>> >
>> >Implementation Notes:
>> >
>> >
>> >
>> >* In the file list pop-up dialog, I truncate the variable¹s value to
>>200
>> >characters max.
>> >
>> >
>> >
>> >
>> >The reason is that I discovered for variables (like ³BBINCLUDE²) with
>> >very long values, the pop-up is in fact unable by design to scroll to
>>the
>> >end, to show the file list.
>> > I think that 200 characters give the right idea, and the result looks
>> >consistent with the more normal pop-ups.
>> >
>> >
>> >
>> >* I have the file filters working for each of the indicated categories.
>> >
>> >
>> >
>> >
>> >I will note that in my examinations that there were a few file types
>>that
>> >were not covered by the existing categories, and I wondered if you were
>> >ok that.
>> >
>> >
>> >
>> >    poky/meta/classes/*
>> >
>> >    poky/bitbake/lib/bb/*
>> >
>> >
>> >
>> >* I have the filter for the descriptions.
>> >
>> >
>> >
>> >I ended on filtering on the presence of a space character, because I
>> >could not find an appropriate alternate field lookup. I suppose I could
>> >try a regex test.
>> >
>> >
>> >
>> >* I implemented the file list such the last file is the one shown.
>> >
>> >
>> >
>> >I was however curious if it is absolutely the case that the foreign key
>> >select on the VariableHistory table is guaranteed to be in time order.
>>I
>> >did manually examine the
>> > first 100 rows and found that indeed that the rows were in primary key
>> >sequential order, but that is not proof.
>> >
>> >
>> >
>> >Thanks,
>> >
>> >David
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> 
>

Re: V2: review request for configure details page

[Barros Pena, Belen]

Hi David

So everything is fixed, except for the Value heading, which should not be
sortable (but it is). I didn't make it sortable because I didn't think it
would be very useful. Having said that, feel free to keep it if you think
otherwise. 

Of the other issues:

* I remembered we have an open issue for the bitbake.conf path problem

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5562

This is one of the issues assigned to Cristiana Voicu, which Alex has
asked for help with.

* you are working on the sorting of the Set in file column so that it will
sort only using the last file that touches the variable. If we cannot get
this working, or if it is too much trouble, the alternative is to disable
the sorting in this column (better than it looking broken).

I'm afraid I have found a few more things here and there:

* Searching sets back the Description filter. How to reproduce:

1) In the Configuration page, set the description filter to Show all
variables
2) Search for something (e.g. local.conf)

Outcome: when search results are returned, the description filter is once
more set to Show only variables with description. This should not  happen:
the scope of the search is always the full content of the database.

* The description filter tooltip says: "Showing only Show only variables
with description". It should say "Showing only variables with
description". If needed, we can change the radio button label to say just
"Variables with description"

* In the Summary tab, Target System should be Target system (lowercase -s
to match all other labels)

* Some variables show more than once. If in the BitBake variables tab I
search for IMAGE_FSTYPES I get 3 rows with exactly the same content. In my
database, there is only one entry for that variable and that build. It is
as if something in between the database and my browser is multiplying
entries

* Variables with no value and no file are only there because there is a
description set for them in documentation.conf. They should be excluded
from the view (table, search, sorting and filtering).

Cheers

Belén



On 17/02/2014 10:57, "Barros Pena, Belen" <belen.barros.pena@intel.com>
wrote:

>On 14/02/2014 21:11, "Reyna, David" <david.reyna@windriver.com> wrote:
>
>>Hi Belén,
>>
>>Thank you for your review. I believe that I have now fixed all of the
>>identified issues, but I did have some observations.
>>
>>1) "The Description filter should be applied when you load this page"
>>
>>Ok, I got this to work. Note that the consequence of this is that the
>>title of the page is _never_ "Configuration", but instead is something
>>like "984 variables found", because the filter is now always asserted by
>>default.
>
>I can see that. I think we can leave it as is for the moment. If it turns
>out to be confusing for users, we'll hear about it :)
>
>>
>>2) "But the Set in file heading should be sortable"
>>
>>Well, I am surprised, I actually got it to mostly work :-O.
>>
>>    'orderfield': _get_toggle_order(request, "vhistory__file_name"),
>>
>>When I write "mostly", it does actually sort, but I observe
>>"conf/bitbake" values that get inserted into the sort order. Upon
>>examination, these entries are always the last entry in that entry's
>>history list, where the first element appears to reflect the sort order,
>>it appears to me that the sort system always uses the _first_ element
>>when it encounters a list.
>>
>>So, in these instances the sort to appear to be broken to the user when
>>the first (and explicitly hidden) file entry is different from the last
>>(shown).
>>
>>I need to investigate whether the existing sort system allows the
>>specification of custom compare functions in order to force the compare
>>to be against the _last_ entry. The examples I have seen so far only use
>>flat class member specifications.
>>
>>3) "The path for the bitbake.conf file is not the full path"
>>
>>Every entry in the database for "bitbake.conf" is "conf/bitbake.conf".
>>These are the only non-full path entries that I have found in the file
>>lists, so I think that this is specific to the respective code in the
>>toast database capture code.
>>
>>I will file a bug against the toaster backend.
>>
>>- David
>>
>>> -----Original Message-----
>>> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
>>> Sent: Friday, February 14, 2014 8:27 AM
>>> To: Reyna, David; Damian, Alexandru
>>> Cc: toaster@yoctoproject.org
>>> Subject: Re: review request for configure details page
>>> 
>>> Thanks, David. Those file filters are really neat :)
>>> 
>>> I have reviewed this page. There are a few little things
>>> implementation-related, and there are other (bigger) issues that are
>>> design problems.
>>> 
>>> The implementation first:
>>> 
>>> SUMMARY TAB
>>> 
>>> * The Summary values in the Build configuration section don't seem to
>>>be
>>> coming in (for my Beagleboard build, I see machine 'atom-pc', which
>>> doesn't seem right). That section should list:
>>> 
>>> ** BitBake version (BB_VERSION)
>>> 
>>> ** Build system (BUILD_SYS)
>>> 
>>> ** Host distribution (NATIVELSBSTRING)
>>> 
>>> ** Target system (TARGET_SYS)
>>> 
>>> ** Machine (MACHINE)
>>> 
>>> ** Distro (DISTRO)
>>> 
>>> ** Distro version (DISTRO_VERSION)
>>> 
>>> ** Tune features (TUNE_FEATURES)
>>> 
>>> ** Target FPU (TARGET_FPU)
>>> 
>>> ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you
>>>are
>>> building (e.g. core-image-minimal). If more than one, please mark them
>>>up
>>> within an unnumbered list (<ul>)
>>> 
>>> If any of the above variables has no value, we don't list the variable
>>> 
>>> * We should take out the blue icon next to the layer name
>>> 
>>> BITBAKE VARIABLES TAB
>>> 
>>> * The Description filter should be applied when you load this page
>>> 
>>> * The Value heading is not sortable
>>> 
>>> * But the Set in file heading should be sortable
>>> 
>>> * The path for the bitbake.conf file is not the full path (it only says
>>> conf/bitbake.conf)
>>> 
>>> * In the filter modal dialogs, the headings and the "All" radio button
>>> labels say "configvars" instead of "variables". This also happens in
>>>the
>>> applied filter tooltip (in the "Show all" button) and in the
>>>placeholder
>>> text in the search input field (which should say "Search BitBake
>>> variables")
>>> 
>>> There are also some design problems with this page that I need to think
>>> about:
>>> 
>>> 
>>> * As it was designed, the modal dialog for the history should only
>>>exist
>>> if the number of config files touching the variable is higher than one.
>>> This causes a few issues:
>>> 
>>> ** how do we show the operation and line number for the variables
>>>touched
>>> by only one file?
>>> 
>>> 
>>> ** Search and filtering work across all entries, which means it might
>>>not
>>> be obvious why you get certain results since they are hidden inside the
>>> history modal dialog
>>> 
>>> 
>>> * How do we deal with very long values (both in the table and in the
>>> history modal dialogs)?
>>> 
>>> * The design specification says that the page h1 should not be
>>>manipulated
>>> by search results: for pages with tabs, like this one, it says to
>>>display
>>> a h2 right above the search field with the number of results returned
>>>by
>>> the search query. Having said that, I am not particularly happy with
>>>that
>>> design either. On the other hand, manipulating the h1 causes some weird
>>> interactions in the page that could be confusing. This is the kind of
>>> thing you need to test with users to actually find out. I am inclined
>>>to
>>> leave it as is for the moment, and see how it goes. We can always
>>>refine
>>> it in the next release cycle.
>>> 
>>> 
>>> * What do we do with the B_* variables (in a core-image-minimal build
>>>you
>>> get about 600 of those). We knew we were going to hit this problem at
>>>some
>>> point, but I am not sure how we can exclude those entries within our
>>> existing filtering patterns. The only easy solution seems to be
>>>removing
>>> the B variable from documentation.conf, which means that neither B nor
>>>any
>>> of the 600 B_* variables will show by default, since we apply the
>>> Variables with description filter.
>>> 
>>> * I have been thinking about how we can keep the links to the full
>>> variable descriptions in the Yocto Project manual. Right now, we do
>>>know
>>> that an entry in the manual exists for each variable that has a
>>> description, so it is safe to show the link. We also know their
>>>structure
>>> should be:
>>> 
>>> 
>>>http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-
>>>+
>>> <variableName>
>>> 
>>> For example:
>>> 
>>> 
>>>http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-
>>>A
>>>LL
>>> OW_EMPTY
>>> 
>>> The question is: what's the best way to generate the URLs?
>>> 
>>> 
>>> Sorry for the brain dump: I thought I'd share my pains with you all ;)
>>>I
>>> will try and look into the design issues above as soon as possible. If
>>>you
>>> have any suggestions for any of them, please let me know.
>>> 
>>> Belén
>>> 
>>> 
>>> On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
>>> 
>>> >Hi again,
>>> >
>>> >> ³I have the filter for the descriptions, but is depends on the
>>>presence
>>> >>of a space character²
>>> >
>>> >Ok, I was able to redo and push the filter using a regex, so that will
>>> >allow the possibility of a description that has characters but no
>>>spaces.
>>> >
>>> >    ('Show only variables with description', 'description__regex:.+'),
>>> >
>>> >- David
>>> >
>>> >From: toaster-bounces@yoctoproject.org
>>> >[mailto:toaster-bounces@yoctoproject.org]
>>> >On Behalf Of Reyna, David
>>> >Sent: Friday, February 14, 2014 1:20 AM
>>> >To: belen.barros.pena@intel.com; Damian, Alexandru
>>> >(alexandru.damian@intel.com)
>>> >Cc: toaster@yoctoproject.org
>>> >Subject: [Toaster] review request for configure details page
>>> >
>>> >
>>> >
>>> >Hi Belen and Alex,
>>> >
>>> >
>>> >
>>> >I have the configuration page ready for review at:
>>> >³dreyna/configure-detail-view²
>>> >
>>> >
>>> >
>>> >Implementation Notes:
>>> >
>>> >
>>> >
>>> >* In the file list pop-up dialog, I truncate the variable¹s value to
>>>200
>>> >characters max.
>>> >
>>> >
>>> >
>>> >
>>> >The reason is that I discovered for variables (like ³BBINCLUDE²) with
>>> >very long values, the pop-up is in fact unable by design to scroll to
>>>the
>>> >end, to show the file list.
>>> > I think that 200 characters give the right idea, and the result looks
>>> >consistent with the more normal pop-ups.
>>> >
>>> >
>>> >
>>> >* I have the file filters working for each of the indicated
>>>categories.
>>> >
>>> >
>>> >
>>> >
>>> >I will note that in my examinations that there were a few file types
>>>that
>>> >were not covered by the existing categories, and I wondered if you
>>>were
>>> >ok that.
>>> >
>>> >
>>> >
>>> >    poky/meta/classes/*
>>> >
>>> >    poky/bitbake/lib/bb/*
>>> >
>>> >
>>> >
>>> >* I have the filter for the descriptions.
>>> >
>>> >
>>> >
>>> >I ended on filtering on the presence of a space character, because I
>>> >could not find an appropriate alternate field lookup. I suppose I
>>>could
>>> >try a regex test.
>>> >
>>> >
>>> >
>>> >* I implemented the file list such the last file is the one shown.
>>> >
>>> >
>>> >
>>> >I was however curious if it is absolutely the case that the foreign
>>>key
>>> >select on the VariableHistory table is guaranteed to be in time order.
>>>I
>>> >did manually examine the
>>> > first 100 rows and found that indeed that the rows were in primary
>>>key
>>> >sequential order, but that is not proof.
>>> >
>>> >
>>> >
>>> >Thanks,
>>> >
>>> >David
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> 
>>
>

Re: V2: review request for configure details page

[Reyna, David]

Hi Belén,

See in-line...

> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Monday, February 17, 2014 8:12 AM
> To: Reyna, David; Damian, Alexandru
> Cc: toaster@yoctoproject.org
> Subject: Re: V2: review request for configure details page
> 
> Hi David
> 
> So everything is fixed, except for the Value heading, which should not be
> sortable (but it is). I didn't make it sortable because I didn't think it
> would be very useful. Having said that, feel free to keep it if you think
> otherwise.

I think that we should keep it as a sortable column. I see it having a value for people learning the bitbake build system (an experience I remember vividly - it was totally bewildering), and while "search" is powerful it does not help for when you do not know what to look for. Besides, it has no cost and little overhead.

> Of the other issues:
> 
> * I remembered we have an open issue for the bitbake.conf path problem
> 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5562
> 
> This is one of the issues assigned to Cristiana Voicu, which Alex has
> asked for help with.

I will grab this defect once I get the Target page working.

> * you are working on the sorting of the Set in file column so that it will
> sort only using the last file that touches the variable. If we cannot get
> this working, or if it is too much trouble, the alternative is to disable
> the sorting in this column (better than it looking broken).

We can think about this in parallel with our other work, and decide a little later I think. I have a proposed easy fix with the added field, and Alex has a proposed easy fix where he reverses the table order (and I then reverse that order back to true in the template filter).

> I'm afraid I have found a few more things here and there:
> 
> * Searching sets back the Description filter. How to reproduce:
> 
> 1) In the Configuration page, set the description filter to Show all
> variables
> 2) Search for something (e.g. local.conf)
> 
> Outcome: when search results are returned, the description filter is once
> more set to Show only variables with description. This should not  happen:
> the scope of the search is always the full content of the database.

Well this is totally weird. This default filter should only assert itself when there are no "mandatory_parameters" present (i.e. when the page is first served), but I clearly see the same behavior as you do. 

I will have to debug the GET state and the "_verify_parameters" routine.

> * The description filter tooltip says: "Showing only Show only variables
> with description". It should say "Showing only variables with
> description". If needed, we can change the radio button label to say just
> "Variables with description"

Hmm, I do not see that error. It should disappear for you as well in my next push.

> * In the Summary tab, Target System should be Target system (lowercase -s
> to match all other labels)

Done.

> * Some variables show more than once. If in the BitBake variables tab I
> search for IMAGE_FSTYPES I get 3 rows with exactly the same content. In my
> database, there is only one entry for that variable and that build. It is
> as if something in between the database and my browser is multiplying
> entries

Wow, I see that as well. I myself get two duplicates, and I can show that they both have the same PK values.

I do observe that without the search that there is only one entry in the display, so the database and the template code are presumably both fine. There is evidently something in the functions that assemble the querysets that is duplicating the rows.

> * Variables with no value and no file are only there because there is a
> description set for them in documentation.conf. They should be excluded
> from the view (table, search, sorting and filtering).

Ok, I will work to add that additional condition. I could do it at the template level, but that would throw off the row counts, so I will have to add that refinement early in the view class (before the pagination).

Thanks,
David

> Cheers
> 
> Belén
> 
> 
> 
> On 17/02/2014 10:57, "Barros Pena, Belen" <belen.barros.pena@intel.com>
> wrote:
> 
> >On 14/02/2014 21:11, "Reyna, David" <david.reyna@windriver.com> wrote:
> >
> >>Hi Belén,
> >>
> >>Thank you for your review. I believe that I have now fixed all of the
> >>identified issues, but I did have some observations.
> >>
> >>1) "The Description filter should be applied when you load this page"
> >>
> >>Ok, I got this to work. Note that the consequence of this is that the
> >>title of the page is _never_ "Configuration", but instead is something
> >>like "984 variables found", because the filter is now always asserted by
> >>default.
> >
> >I can see that. I think we can leave it as is for the moment. If it turns
> >out to be confusing for users, we'll hear about it :)
> >
> >>
> >>2) "But the Set in file heading should be sortable"
> >>
> >>Well, I am surprised, I actually got it to mostly work :-O.
> >>
> >>    'orderfield': _get_toggle_order(request, "vhistory__file_name"),
> >>
> >>When I write "mostly", it does actually sort, but I observe
> >>"conf/bitbake" values that get inserted into the sort order. Upon
> >>examination, these entries are always the last entry in that entry's
> >>history list, where the first element appears to reflect the sort order,
> >>it appears to me that the sort system always uses the _first_ element
> >>when it encounters a list.
> >>
> >>So, in these instances the sort to appear to be broken to the user when
> >>the first (and explicitly hidden) file entry is different from the last
> >>(shown).
> >>
> >>I need to investigate whether the existing sort system allows the
> >>specification of custom compare functions in order to force the compare
> >>to be against the _last_ entry. The examples I have seen so far only use
> >>flat class member specifications.
> >>
> >>3) "The path for the bitbake.conf file is not the full path"
> >>
> >>Every entry in the database for "bitbake.conf" is "conf/bitbake.conf".
> >>These are the only non-full path entries that I have found in the file
> >>lists, so I think that this is specific to the respective code in the
> >>toast database capture code.
> >>
> >>I will file a bug against the toaster backend.
> >>
> >>- David
> >>
> >>> -----Original Message-----
> >>> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> >>> Sent: Friday, February 14, 2014 8:27 AM
> >>> To: Reyna, David; Damian, Alexandru
> >>> Cc: toaster@yoctoproject.org
> >>> Subject: Re: review request for configure details page
> >>>
> >>> Thanks, David. Those file filters are really neat :)
> >>>
> >>> I have reviewed this page. There are a few little things
> >>> implementation-related, and there are other (bigger) issues that are
> >>> design problems.
> >>>
> >>> The implementation first:
> >>>
> >>> SUMMARY TAB
> >>>
> >>> * The Summary values in the Build configuration section don't seem to
> >>>be
> >>> coming in (for my Beagleboard build, I see machine 'atom-pc', which
> >>> doesn't seem right). That section should list:
> >>>
> >>> ** BitBake version (BB_VERSION)
> >>>
> >>> ** Build system (BUILD_SYS)
> >>>
> >>> ** Host distribution (NATIVELSBSTRING)
> >>>
> >>> ** Target system (TARGET_SYS)
> >>>
> >>> ** Machine (MACHINE)
> >>>
> >>> ** Distro (DISTRO)
> >>>
> >>> ** Distro version (DISTRO_VERSION)
> >>>
> >>> ** Tune features (TUNE_FEATURES)
> >>>
> >>> ** Target FPU (TARGET_FPU)
> >>>
> >>> ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you
> >>>are
> >>> building (e.g. core-image-minimal). If more than one, please mark them
> >>>up
> >>> within an unnumbered list (<ul>)
> >>>
> >>> If any of the above variables has no value, we don't list the variable
> >>>
> >>> * We should take out the blue icon next to the layer name
> >>>
> >>> BITBAKE VARIABLES TAB
> >>>
> >>> * The Description filter should be applied when you load this page
> >>>
> >>> * The Value heading is not sortable
> >>>
> >>> * But the Set in file heading should be sortable
> >>>
> >>> * The path for the bitbake.conf file is not the full path (it only says
> >>> conf/bitbake.conf)
> >>>
> >>> * In the filter modal dialogs, the headings and the "All" radio button
> >>> labels say "configvars" instead of "variables". This also happens in
> >>>the
> >>> applied filter tooltip (in the "Show all" button) and in the
> >>>placeholder
> >>> text in the search input field (which should say "Search BitBake
> >>> variables")
> >>>
> >>> There are also some design problems with this page that I need to think
> >>> about:
> >>>
> >>>
> >>> * As it was designed, the modal dialog for the history should only
> >>>exist
> >>> if the number of config files touching the variable is higher than one.
> >>> This causes a few issues:
> >>>
> >>> ** how do we show the operation and line number for the variables
> >>>touched
> >>> by only one file?
> >>>
> >>>
> >>> ** Search and filtering work across all entries, which means it might
> >>>not
> >>> be obvious why you get certain results since they are hidden inside the
> >>> history modal dialog
> >>>
> >>>
> >>> * How do we deal with very long values (both in the table and in the
> >>> history modal dialogs)?
> >>>
> >>> * The design specification says that the page h1 should not be
> >>>manipulated
> >>> by search results: for pages with tabs, like this one, it says to
> >>>display
> >>> a h2 right above the search field with the number of results returned
> >>>by
> >>> the search query. Having said that, I am not particularly happy with
> >>>that
> >>> design either. On the other hand, manipulating the h1 causes some weird
> >>> interactions in the page that could be confusing. This is the kind of
> >>> thing you need to test with users to actually find out. I am inclined
> >>>to
> >>> leave it as is for the moment, and see how it goes. We can always
> >>>refine
> >>> it in the next release cycle.
> >>>
> >>>
> >>> * What do we do with the B_* variables (in a core-image-minimal build
> >>>you
> >>> get about 600 of those). We knew we were going to hit this problem at
> >>>some
> >>> point, but I am not sure how we can exclude those entries within our
> >>> existing filtering patterns. The only easy solution seems to be
> >>>removing
> >>> the B variable from documentation.conf, which means that neither B nor
> >>>any
> >>> of the 600 B_* variables will show by default, since we apply the
> >>> Variables with description filter.
> >>>
> >>> * I have been thinking about how we can keep the links to the full
> >>> variable descriptions in the Yocto Project manual. Right now, we do
> >>>know
> >>> that an entry in the manual exists for each variable that has a
> >>> description, so it is safe to show the link. We also know their
> >>>structure
> >>> should be:
> >>>
> >>>
> >>>http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-
> >>>+
> >>> <variableName>
> >>>
> >>> For example:
> >>>
> >>>
> >>>http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-
> >>>A
> >>>LL
> >>> OW_EMPTY
> >>>
> >>> The question is: what's the best way to generate the URLs?
> >>>
> >>>
> >>> Sorry for the brain dump: I thought I'd share my pains with you all ;)
> >>>I
> >>> will try and look into the design issues above as soon as possible. If
> >>>you
> >>> have any suggestions for any of them, please let me know.
> >>>
> >>> Belén
> >>>
> >>>
> >>> On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
> >>>
> >>> >Hi again,
> >>> >
> >>> >> ³I have the filter for the descriptions, but is depends on the
> >>>presence
> >>> >>of a space character²
> >>> >
> >>> >Ok, I was able to redo and push the filter using a regex, so that will
> >>> >allow the possibility of a description that has characters but no
> >>>spaces.
> >>> >
> >>> >    ('Show only variables with description', 'description__regex:.+'),
> >>> >
> >>> >- David
> >>> >
> >>> >From: toaster-bounces@yoctoproject.org
> >>> >[mailto:toaster-bounces@yoctoproject.org]
> >>> >On Behalf Of Reyna, David
> >>> >Sent: Friday, February 14, 2014 1:20 AM
> >>> >To: belen.barros.pena@intel.com; Damian, Alexandru
> >>> >(alexandru.damian@intel.com)
> >>> >Cc: toaster@yoctoproject.org
> >>> >Subject: [Toaster] review request for configure details page
> >>> >
> >>> >
> >>> >
> >>> >Hi Belen and Alex,
> >>> >
> >>> >
> >>> >
> >>> >I have the configuration page ready for review at:
> >>> >³dreyna/configure-detail-view²
> >>> >
> >>> >
> >>> >
> >>> >Implementation Notes:
> >>> >
> >>> >
> >>> >
> >>> >* In the file list pop-up dialog, I truncate the variable¹s value to
> >>>200
> >>> >characters max.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >The reason is that I discovered for variables (like ³BBINCLUDE²) with
> >>> >very long values, the pop-up is in fact unable by design to scroll to
> >>>the
> >>> >end, to show the file list.
> >>> > I think that 200 characters give the right idea, and the result looks
> >>> >consistent with the more normal pop-ups.
> >>> >
> >>> >
> >>> >
> >>> >* I have the file filters working for each of the indicated
> >>>categories.
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >I will note that in my examinations that there were a few file types
> >>>that
> >>> >were not covered by the existing categories, and I wondered if you
> >>>were
> >>> >ok that.
> >>> >
> >>> >
> >>> >
> >>> >    poky/meta/classes/*
> >>> >
> >>> >    poky/bitbake/lib/bb/*
> >>> >
> >>> >
> >>> >
> >>> >* I have the filter for the descriptions.
> >>> >
> >>> >
> >>> >
> >>> >I ended on filtering on the presence of a space character, because I
> >>> >could not find an appropriate alternate field lookup. I suppose I
> >>>could
> >>> >try a regex test.
> >>> >
> >>> >
> >>> >
> >>> >* I implemented the file list such the last file is the one shown.
> >>> >
> >>> >
> >>> >
> >>> >I was however curious if it is absolutely the case that the foreign
> >>>key
> >>> >select on the VariableHistory table is guaranteed to be in time order.
> >>>I
> >>> >did manually examine the
> >>> > first 100 rows and found that indeed that the rows were in primary
> >>>key
> >>> >sequential order, but that is not proof.
> >>> >
> >>> >
> >>> >
> >>> >Thanks,
> >>> >
> >>> >David
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>
> >
>