ALMToolkit: Object reference not set to an instance of an object

Source Model = Desktop - 64 Bit - February 2021 release. Also uses composite model.
Destination Model = Power BI Service
Click compare - screen does not show any data/info - only reports "Object reference not set to an instance of an object".
Source model = 203MB  - Uses Incremental Refresh and now composite model too.
Same pbix was published to service and successfully refreshed in the service.
I intend to retest by publishing model and connecting with ALM Toolkit prior to refresh. (i.e. after no change).

David

Update on the retest.
PBIX Uploaded to workspace (that I'm the Admin of - workspace does contain other models).
Connection attempt with ALM toolkit - fails with Object reference not set to an instance of an object.

Hi David, is the service Premium Gen1, Gen2, PPU or Pro?

Hi Christian. It's Premium (and as I'm not the premium Admin, I think it will be Gen1?)
I have just deleted the connection to the Composite model and republished. Success I'm able to complete the compare.

went to Data Source settings, right click and delete. then Save and Publish and connect with ALM Tool Kit. Success.

Thanks for the heads up. Will look into it ...

@christianwade I can confirm the same use case of @dgwilson
Source Model = Version: 2.90.782.0 64-bit (February 2021)
Destination Model = Power BI Service - Premium Workspace Gen1
Model with incremental refresh and composite model (Using DirectQuery for Power BI datasets)
Connection attempt with ALM toolkit - fails with Object reference not set to an instance of an object.
Deleted the Power BI dataset data source I was connecting in DirectQuery and republished and connect with ALM Tool Kit with success.

Similar issue as above - on the first compare it did mention version differences between Source and Destination.
Do you think upgrading to Gen 2on the service will fix this? Thanks.

Sorry for delayed response on this.
Are you still getting this issue? I seem unable to repro. If yes, I'd like to find a way to repro, but might be tricky if depends on the source model for the composite model.
The different versions message, if you mean detection of compatibility levels, this is by design.

Hi Christian,
ALM Toolkit still fails with “object reference not set to an instance of an object” when we are comparing power bi service composite model that has more than 1 power bi dataset.
For now we are comparing individual power bi datasets that make up the composite model. Let me know if you need any other information.
Thanks,
Vamsi.
On Apr 30, 2021, at 8:03 PM, Christian Wade @.***> wrote:

[WARNING] EXTERNAL EMAIL: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Sorry for delayed response on this.
Are you still getting this issue? I seem unable to repro. If yes, I'd like to find a way to repro, but might be tricky if depends on the source model for the composite model.
The different versions message, if you mean detection of compatibility levels, this is by design.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/Analysis-Services/issues/98#issuecomment-830479276, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB575UQNZKFSGTRHNTR6WQTTLNHPDANCNFSM4YNOHA7A.

@christianwade https://github.com/christianwade I've retested this and
the same error prevails.
"Object reference not set to an instance of an object"
I've now upgraded ALM Toolkit to 5.0.19 - the same error message is still
emitted.
Next Step - upgrade Power BI Desktop version and republish
Source Model = Version: 2.92.706.0 64-bit (April 2021)
Destination Model = Power BI Service - Premium Workspace Gen2 (I think)
I've saved the PBIX desktop file in the new April release. Republished the
model to the Premium workspace. Then a connection attempt with ALM toolkit

fails with Object reference not set to an instance of an object.

FYI this is no longer a road block for me as I've moved forward and removed
the composite model from my development plans. I still have the source PBIX
file to aid in diagnosing this issue.
The file is 988MB in size and does include Incremental refresh on one
table. Happy to supply information where I can to aid in diagnostics.

David

On Sat, Mar 6, 2021 at 8:05 AM PBILab @.***> wrote:

@christianwade https://github.com/christianwade I can confirm the same
use case of @dgwilson https://github.com/dgwilson
Source Model = Version: 2.90.782.0 64-bit (February 2021)
Destination Model = Power BI Service - Premium Workspace Gen1
Model with incremental refresh and composite model (Using DirectQuery for
Power BI datasets)
Connection attempt with ALM toolkit - fails with Object reference not set
to an instance of an object.
Deleted the Power BI dataset data source I was connecting in DirectQuery
and republished and connect with ALM Tool Kit with success.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Analysis-Services/issues/98#issuecomment-791620437,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABVCN6TXETJ7GB7H3WLD43TCETPDANCNFSM4YNOHA7A
.

I think I found it and fixed it. Can you please try the latest version 5.0.20?

BOOM! Success!
Awesome work.
The Compare succeeds.
Right now both The Service and my local model are the same so no definition
differences to update.
Back in business. Thank you.
On Sat, Mar 6, 2021 at 8:05 AM PBILab @.***> wrote:

@christianwade https://github.com/christianwade I can confirm the same
use case of @dgwilson https://github.com/dgwilson
Source Model = Version: 2.90.782.0 64-bit (February 2021)
Destination Model = Power BI Service - Premium Workspace Gen1
Model with incremental refresh and composite model (Using DirectQuery for
Power BI datasets)
Connection attempt with ALM toolkit - fails with Object reference not set
to an instance of an object.
Deleted the Power BI dataset data source I was connecting in DirectQuery
and republished and connect with ALM Tool Kit with success.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Analysis-Services/issues/98#issuecomment-791620437,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABVCN6TXETJ7GB7H3WLD43TCETPDANCNFSM4YNOHA7A
.

Also... via Edge... I'm getting "AlmTookKitSetup.msi was blocked because it
could harm your device.". ...  I proceed and tell it to keep the file
etc... I have reported it as Safe.
On Tue, May 4, 2021 at 2:14 PM David Wilson @.***> wrote:

BOOM! Success!
Awesome work.
The Compare succeeds.
Right now both The Service and my local model are the same so no
definition differences to update.
Back in business. Thank you.
On Sat, Mar 6, 2021 at 8:05 AM PBILab @.***> wrote:

@christianwade https://github.com/christianwade I can confirm the same
use case of @dgwilson https://github.com/dgwilson
Source Model = Version: 2.90.782.0 64-bit (February 2021)
Destination Model = Power BI Service - Premium Workspace Gen1
Model with incremental refresh and composite model (Using DirectQuery for
Power BI datasets)
Connection attempt with ALM toolkit - fails with Object reference not set
to an instance of an object.
Deleted the Power BI dataset data source I was connecting in DirectQuery
and republished and connect with ALM Tool Kit with success.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/Analysis-Services/issues/98#issuecomment-791620437,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABVCN6TXETJ7GB7H3WLD43TCETPDANCNFSM4YNOHA7A
.

Sounds good! I'll see if anything can be done about the Edge thing.
Thanks for reporting this!


update settings through SDK

Is there any way to update setting through Java SDK?
Like for the curl request below:
$ curl
-X POST 'http://localhost:7700/indexes/movies/settings'
--data '{
"displayedAttributes": [
"title",
"description",
"poster",
"release_date",
"rank"
]
}'

Hello @ajay-a1! Thanks for your feedback, I really thought this kind of priority method was already implemented in this package, but I don't find any, my bad. I open a more detailed issue to add this.

Closing this issue in favor of #93


Single resource record

Is it possible to make the single-page settings?  like the outl1ne/nova-settings.

@aqjw hi
You can specify a link to a specific settings page in the Nova menu. This way there will be only one settings page


How do you prevent the Aerial split pane from becoming a buffer when the cursor is inside?

I often accidentally leave the cursor inside the Aerial split pane and switch to a different buffer and the pane ends up becoming that buffer. How do I prevent this from happening?

Check out https://github.com/stevearc/stickybuf.nvim/
Or if you're on Neovim 0.10+, you can set winfixbuf on the aerial window

@stevearc, with the release of 0.10 does it make sense to set winfixbuf automatically in aerial?


[Improvement][dao]When I search for the keyword Modify User, the web UI shows empty

Purpose of the pull request
[Improvement][dao]When I search for the keyword Modify User, the web UI shows empty
this closes #5304.

Codecov Report

Merging #5952 (62830d1) into dev (f567517) will decrease coverage by 0.01%.
The diff coverage is 71.42%.

@@             Coverage Diff              @@
##                dev    #5952      +/-   ##
============================================
- Coverage     46.77%   46.75%   -0.02%
+ Complexity     3746     3742       -4
============================================
  Files           604      604
  Lines         24820    24823       +3
  Branches       2832     2833       +1
============================================
- Hits          11610    11607       -3
- Misses        12072    12075       +3
- Partials       1138     1141       +3

Impacted Files
Coverage Δ

...lphinscheduler/server/worker/task/sql/SqlTask.java
59.52% <71.42%> (-2.32%)
:arrow_down:

...inscheduler/common/thread/ThreadPoolExecutors.java
19.23% <0.00%> (-1.93%)
:arrow_down:

...dolphinscheduler/remote/future/ResponseFuture.java
81.35% <0.00%> (-1.70%)
:arrow_down:

...er/master/processor/queue/TaskResponseService.java
68.05% <0.00%> (+4.16%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f567517...62830d1. Read the comment docs.


⚠ Bofrost.be has degraded performance

In 89d4614, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 1812 ms

Resolved: Bofrost.be performance has improved in 6d7d62b after 10 minutes.


Add documentation for the accounts API.

@justinvdm Ready for review.
I would like to claim that I'm breaking things into tiny PRs on purpose, but actually I'm just making a PR each time I realize something is missing. :)

:+1:


Update expressroute-about-encryption.md

This was our experience with an Cisco ASR1006-X IOS-XS 16.06.05. This feature is not possible to be disabled in the actual IOS-XS Version. Please clarify the "please" because it looks like it's a must.

@discodandy : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#sign-off

@ktoliver : Thanks for your contribution! The author(s) have been notified to review your proposed change.


PVSS,Scalar datatype?

Dear sir,
I notice that no matter what "keypair" or "secret" in HydRand,all of them is Scalar data type.Is there any way to use my own data? For example, i want to share a string message "hello,world!".  How to transfer str to Scalar, and after recover , the secret is  still a Scalar type value. How to transfer Scalar to a str?
I have tried the method "deterministic_random_scalar(purpose: Optional[str] = None, counter: Optional[int] = None)" in hydrand/utils.py , i think this is the way to Scalar, but i can't find a way back to string.

The PVSS as used in HydRand can only be used to share a random group
element. If you want to share a specific message, it is bet to derive a
symmetric encryption key from the shared group element and use a symmetric
key encryption algorithm to encrypt your data used the derived key. This
approach is describe e.g. by Schoenmakers (
https://link.springer.com/content/pdf/10.1007/3-540-48405-1_10.pdf) in more
detail.
chenjinhua1993<EMAIL_ADDRESS>schrieb am Mo., 18. Nov. 2019,
03:26:

Dear sir,
I notice that no matter what "keypair" or "secret" in HydRand,all of them
is Scalar data type.Is there any way to use my own data? For example, i
want to share a string message "hello,world!". How to transfer str to
Scalar, and after recover , the secret is still a Scalar type value. How to
transfer Scalar to a str?
I have tried the method "deterministic_random_scalar(purpose: Optional[str] = None, counter: Optional[int] = None)" in hydrand/utils.py , i think this is the way to Scalar, but i can't find a way back to string.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PhilippSchindler/hydrand/issues/4?email_source=notifications&email_token=ABATVRS7TILL7AL6BGS3LGTQUH4NBA5CNFSM4JONFUTKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HZ5CZUQ,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABATVRUKS4ABFTJCM3CFC6TQUH4NBANCNFSM4JONFUTA
.

Thank you very much !


Fix runc repo location in Dockerfile

There is no github.com/genuinetools/runc repo. And probably there shouldn't be one. I guess that this custiom runc dependency will be gone when runc patches will be merged upstream.

Codecov Report

Merging #65 into master will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff          @@
##           master   #65   +/-   ##
====================================
  Coverage       0%    0%
====================================
  Files          11    11
  Lines         546   546
====================================
  Misses        546   546

ah thanks, was a bad sed


Reducing bus factor in CODEOWNERS

Please provide a description for what this PR is for.
And to help us figure out who should review this PR, please
put an X in all the areas that this PR affects.
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

@nmittler: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-presubmit-tests-master
7712b83d3862337d8ab50b7cdb3e582f2262ff03
link
/test integ-mixer-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@nmittler: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

integ-mixer-k8s-presubmit-tests-master
7712b83d3862337d8ab50b7cdb3e582f2262ff03
link
/test integ-mixer-k8s-presubmit-tests-master

integ-new-install-k8s-presubmit-tests-master
7712b83d3862337d8ab50b7cdb3e582f2262ff03
link
/test integ-new-install-k8s-presubmit-tests-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


[Feature Proposal] Toggle field visibility (hide/show fields depending on other fields)

This is the most upvoted feature in our feature poll. So it's the first one we can tackle, now that we have v5 ready for launch.
Let's do this!!! 💪
The Problem
I've studied all previous PRs for this:

2016 - https://github.com/Laravel-Backpack/CRUD/pull/165
2018 - https://github.com/Laravel-Backpack/CRUD/pull/1257
2020 - https://github.com/Laravel-Backpack/CRUD/pull/3420
2021 - https://github.com/Laravel-Backpack/CRUD/pull/3753

As I said in https://github.com/Laravel-Backpack/addons/issues/11 ... this is a tricky problem to solve... because the developer needs can be so very different. In various places, people ask:

for the "source" to a select, others radio, checkbox, checklist, select2_from_array, etc;
for the "source" to be multiple fields, not just one;
for the "action" to be "hiding";
for the "action" to be "showing";
for the "action" to be "hiding and disabling";
for the "action" to be "calculating the value";

I'm ashamed we haven't done anything to solve this until now. Literal shame. But... the reason we haven't merged any of those... is that I didn't see way for us to cover what most devs need, most of the time. We would only be covering a particular use case, which would most certainly have meant we would be adding features and niche use cases to it for years, as people report them. And that simply wasn't a good idea, to take on such a big maintenance burden... when it's not that difficult to do it in JS, for the people who needed it. You could do it in create.js and update.js and you have a solution, for your project alone, with maximum customizability. That's why I've been suggesting "creating an addon for it" to devs who have made PRs for this... because they were niche solutions, and for sure somebody would have used it... but not everybody would have been happy with it.
I didn't see how we can build this feature/field/whatever so that most people will be happy with it. But now... I think I do. And it's sort of what @pxpm  suggested here... but without the AJAX calls, which I think are unproductive and bound to fail.
And thanks to the open-core split... we can start adding more and more feature, right into backpack/pro.
The Solution
What if... instead of wanting to define the JS behavior in PHP... we accept we have to write a little bit of JS for this? And have Backpack make that bit of JS so easy to write, it's a pleasure? In Backpack v5, thanks to the script widget, we can do:
Widget::add()->type('script')->content(asset('/path/to/js/file.js'));

So what if...
Step 1. We make it even easier, by providing a convenience method on CRUD, that also allows for inline content. Something like:
CRUD::addJavascript('/path/to/js/file.js');

// or even

CRUD::addJavascript("alert('what you want to be done here')");

Step 2. We make it dead-simple to write ALL of the combinations above, by providing a selector and a few actions on the crud javascript object (it's already onpage, usually used for working with DataTables). So that what JS you actually write looks like this:
// option 1 - probably needs jQuery
crud.field('agree').on("change", function() {
    crud.field('price').show();
});
crud.field('agree').onChange(function() {
    crud.field('price').show();
});

// option 2 - maybe doesn't need jQuery
crud.field('agree').addEventListener("change", function() {
    crud.field('price').show();
});

// of course, you should be able to do a few other stuff with your `fields`, but the minimum would be:
crud.field('price').show();
crud.field('price').hide();
crud.field('price').disable();
crud.field('price').enable();
crud.field('price').value(); // aka .setValue(), aka .val()

I believe this would solve all cases people have already expressed... but also fix the cases people haven't expressed yet. Which I'm sure will come up, in real apps, right after we introduce a feature with limited customizability. But by moving this logic to JS... it opens up the possibility for you to do... anything you want.

Thoughts, anyone? Am I missing something? Or is this a solution we could all get behind? I'm eager to prototype this, to see if we can launch it with Backpack v5 this week 🎉 I have a feeling it's either a lot simpler than I expect... or a lot more difficult 😅
Can't tell if this idea is incredibly good... or incredibly stupid 😅 Let me know.

Hello @tabacitu
In general I agree with your idea, it goes along with what I was already thinking with some twists, so I will try to sum up what I thought when reading it.
At first it seems to me that the only thing we are doing is "facilitating" the use of JS in page, not really adding the interactivity functionality. What I mean is:

you still need to know JS - it's probably good that you know some of it when working with PHP, but not totally necessary.
everything in Backpack is "dead-simple", I don't think this will ever be like it, what I really expect is spargetti JS in controller or spargetti JS in the .js file.
developers would be writting the same code over and over again for simple tasks like show/hide fields when they should just be providing the when (event) and what (action) and backpack would take care of the how (fields inside repeatable? inside inline create? etc) and execution.

One good thing I think it's worth for us doing is separating all those options (show, hide, setValue etc..) because I am sure some of them are easier to achieve than others and probably we could make the ajax optional for those who want it and leave it off for dead simple scenarios.
So starting by the most commons I think: show/hide/disable/enable
First we should establish that there are very different scenarios happening in cruds, including repeatable fields, fields inside modals, etc. So a simple .hide('field_name') may not work as desired and also, some fields uses hidden inputs that migth not be easy to target with a js selector.
That said, I think that is where backpack should shine in to help developer to don't have to think about how backpack fields are built to hide a field when other is clicked.
I am 100% against javascript in the controllers. At most I would agree with php aliases for js functions that we could translate, like.
CRUD::addfield([
    'name' => 'add_extra_cost',
    'type' => 'checkbox',
   'events' => [
        'onCheck' => function () {
            // for single form fields
            $this->hideField('field_name');
            $this->hideRepeatableField('some_field'); // we would know to search the current clicked row and hide the corresponding group field.
            $this->disableField('field_name');
       },
      'onUncheck' => function () {
                  $this->showField('field_name');
                  $this->showRepeatableField('field_name');
                  $this->enableField('field_name');
             },
]);

// events
function hideField($name) {
// return JS string to find and hide a simple field
}
function hideRepeatableField($name) {
// return JS string to find and hide a field inside a repeatable container
}

and we would translate this into JS like:
//
checkbox.on('change', function() {
    if($(this).isChecked()) {

        {!! $display_the_strings_we_build  !!}
    }else{
        {!! $display_the_strings_we_build  !!}
    }
}

this would not solve ALL the interactivity, but establishes a base for if/when we decide to support ajax for more complicated calculations and no need for dev to know how to search inside repeatable fields etc and repeating the code over and over again.
I also think it's worth adding that for fields that are complicated to get the containers that should be hidden etc, we could define on those fields a *fieldName*IdentifiableContainer like we have the initialize*fieldName*Field, just food for thought.
Let me know if I missed the point here @tabacitu .

Thanks for the feedback @pxpm 🙏 First of all, let me get the "big stuff" out of the way 😅 I have already considered and dismissed doing something like this:
CRUD::addfield([
    'name' => 'add_extra_cost',
    'type' => 'checkbox',
   'events' => [
        'onCheck' => function () {
            // for single form fields
            $this->hideField('field_name');
            $this->hideRepeatableField('some_field'); // we would know to search the current clicked row and hide the corresponding group field.
            $this->disableField('field_name');
       },
      'onUncheck' => function () {
                  $this->showField('field_name');
                  $this->showRepeatableField('field_name');
                  $this->enableField('field_name');
             },
]);

I agree with you that it will be the most dev-friendly way to do this. I do! For devs who don't know/want to code JS, this will be GOLD. And what those people want to do most of the time is show/hide fields, for which this solution would work ok.
But if you look at the bigger picture, there are more reasons NOT to like this than reasons to like this:

having this work will STILL need us to create a syntax/library to show/hide/disable/enable fields in JS, which would work with all field types; so it would still need the above, this would basically be a PHP layer on top of it;
the benefit will be for the 80% use case (agree, totally), but the other 20% use cases will find this useless, and they will need to resort to writing JS anyway;
what this would do is provide a way to define JS events in PHP; this is worse than writing direct JS in PHP, in my opinion; don't get me wrong, I'd hate to write JS in PHP; but at least writing JS in PHP is simple, clear and infinitely customizable: you know it's JS immediately, you can do whatever you want; creating a PHP syntax for writing JS is still "writing JS in PHP"; we're fooling ourselves if we say it's not; the only difference is that you're doing it in a different way; we'd be adding a layer that adds technical complexity, maintenance and limits available options (read: customizability), for the sake of slightly better ease-of-use; I have considered this, and decided it is NOT a tradeoff worth doing; the benefits in ease-of-use are not worth us creating a "programming language" to code JS in PHP;
creating a PHP syntax to code JS is a slippery slope; you proposed 4 functions, which are limiting, so there will soon be requests to "do that" and "do the other thing" etc. etc; and you know us, if they are good ideas we'll end up doing them; so it will baloon to cover more and more use cases; WE will be working on covering more and more niche use cases, for a very VERY niche feature, to make the developer save... how much time? seconds? how many developers? a few percent? Nope 😅 Our time is better spend solving bigger problems, not increasingly small problems; doing something like this is a slippery slope, and it's a categorical "no" on my end; it will end up being another 6-month-task like the relationship field, and it is NOT worth spending that much time on it; it's not something I want to build; it's not something I want to use; it's not something I want to maintain; a big role might be played by "preference" here, but it's such a very very strong preference; so no; na-ha; 😅

At first it seems to me that the only thing we are doing is "facilitating" the use of JS in page, not really adding the interactivity functionality. What I mean is:

you still need to know JS - it's probably good that you know some of it when working with PHP, but not totally necessary.

Agreed. This is one big reason I'm having doubts about this. But I think if we make the syntax simple enough, and with
enough examples, this is not a real problem.

everything in Backpack is "dead-simple", I don't think this will ever be like it, what I really expect is spargetti JS in controller or spargetti JS in the .js file.

If they're doing a complicated thing and they don't know what they're doing, there will be spaghetti somewhere. I'd rather it's in JS than in their controller.

developers would be writting the same code over and over again for simple tasks like show/hide fields when they should just be providing the when (event) and what (action) and backpack would take care of the how (fields inside repeatable? inside inline create? etc) and execution.

True... they would be writing the same code over and over again. But it's not longer code than giving the attributes for the same thing.
Note: I will ignore the "repeatable" thing because I don't think that's something that we will ever need to do. You target a field by name. If you don't know it's name, boo-fucking-hoo, code your own selector 😅 Might change my mind about this if anybody comes up with a real situation where a selector is needed specifically for inside a certain row in a repeatable. But that will be pretty difficult to in a general way, to account for the row but also all field types. Even the PHP syntax will need the JS selector. But again. I don't think that's something we should be worrying about (or providing) from day one. So I'll ignore it.
Ok back to how much code they take up:

in php

        'onCheck' => function () {
            // for single form fields
            $this->hideField('field_name');
            $this->disableField('field_name');
       },
      'onUncheck' => function () {
                  $this->showField('field_name');
                  $this->enableField('field_name');
             },

in js

crud.field('add_extra_box').on("change", function() {
    if (this.val == 1) {
        crud.field('field_name').hide();
        crud.field('field_name').disable();
    } else {
        crud.field('field_name').show();
        crud.field('field_name').enable();
    }
});

which could of course become in js

crud.field('add_extra_box').on("change", function() {
    crud.field('field_name').toggleVisibility();
    crud.field('field_name').toggleEnabledness(); // horrible name, but you know what I mean
});

One good thing I think it's worth for us doing is separating all those options (show, hide, setValue etc..) because I am sure some of them are easier to achieve than others and probably we could make the ajax optional for those who want it and leave it off for dead simple scenarios.

Ok sa you said a sensitive word here... "AJAX" 😅 That is out of the question. We are not creating a baby-Livewire, when in half-a-year or a year we'll be providing support for Livewire itself. No freaking way.

Hi @tabacitu, I was reading this thread and this is really interesting, if we think outside and look at the fields, the first question that comes to my mind is, does the fields API need to be changed or enhanced? does this have anything to do with the fields? well, yes this is related to the fields, but can we if feature versions of backpack introduce another type (ex: groups, or boxes) and we have to support the show/hide/disable/enable, I think this is very possible, and regarding those thoughts, this can cover more than the fields, so what comes to my mind is something like a new wrapper over the UI crud objects that provide those features. This way we can support any field that is currently used by backpack and can ensure evolution.
What @pxpm said is very logical, especially the points about keeping backpack simple to use, (after all this is what makes backpack one of the greatest in administration panels) but the missing key here is, how to introduce this type of feature that play in the front, support all fields and feature fields, and it's easy to understand, easy to use, and of course can grow smoothly without affecting core components, the answer that comes to my mind is another type of wrapper filed, it's only job is UI state of what is inside of it, like Flutter with the GestureDetector.
So tell me what do you think about this, sometimes I overthink, I hope this is not the case 😅

@tabacitu first of all I LOVE when we disagree ❤
Looking at your example, yeah, dead simple ... Just one or two more rows in JS than PHP but not ugly.
Now, you decided to ignore repeatable, I think that is where we are splitting opinions here.
I 100% agree that for dead dead simple tasks it would not be much overhead added using plain JS, but can you try with your example get one field in a specific repeatable row ? I will help you out:
//if element does not have a custom-selector attribute we use the name attribute
                if (typeof element.attr('data-custom-selector') == 'undefined') {
                    form.find('[name="'+$dependency+'"], [name="'+$dependency+'[]"]').change(function(el) {
                            $(element.find('option:not([value=""])')).remove();
                            element.val(null).trigger("change");
                    });
                } else {
                    // we get the row number and custom selector from where element is called
                    let rowNumber = element.attr('data-row-number');
                    let selector = element.attr('data-custom-selector');

                    // replace in the custom selector string the corresponding row and dependency name to match
                    selector = selector
                        .replaceAll('%DEPENDENCY%', $dependency)
                        .replaceAll('%ROW%', rowNumber);

                    $(selector).change(function (el) {
                        $(element.find('option:not([value=""])')).remove();
                        element.val(null).trigger("change");
                    });
                }
            }

It's not literally this, but you get the point of how that goes.
I was giving some tries hiding some fields etc etc, and I think I got to the point that @soufiene-slimi is refering. Some fields have different wrappers and different artifacts in page that need to be hidden. Hide the labels too ?
It does not seem a bad approach at all to have a StateWrapper in "html elements we want" (not referring to fields as it would work with any html inside the wrapper) .
Thanks @soufiene-slimi very nice idea I guess, need to give it some more thinking.
@tabacitu disregard the ajax part, like I said, let's focus on simple tasks (including repeatable as a simple task as is  one of our main fields).
Currently we already have some kind of toggable functionality:
CRUD::addField([
'name' => 'bla',
'dependencies' => ['dep_1','dep_2'],
]);

This means that whenever one of those dependencies changes, the value of this field is cleared. What we are trying to do is inverting this dependency, and tell in dep_1 and dep_2 when they change, set the value of bla to null.
I don't agree with you that we are writting JS inside controller if we use wrappers. Eg: You are not writting bit code when coding in C, but the compiler will translate what you write into bit code.
So basically what I am proposing is a compiler (that have a PREDEFINED set of instructions) that he knows how to handle and transform you PHP code into usable JS.
To sum up the instructions that I think we need to cover 90%++) of the cases:
EVENTS:

text/textarea

change (this includes datepickers etc)

checkboxes / radio

checked, unchecked

selects

selected, unselected, cleared

ACTIONS:

show/hide/disable/enable/setAttribute

I can not argue about the time commitment to do this feature beeing higher than allowing people to writte JS in controllers, but I cannot see how this will really help to solve this toggable problem if we follow your route.
I can already do what you describe using widgets, for complex scenarios, I don't think there is any benefit added creating an alias for Widget::add().
For real real complex scenarios you can add your on JS functions with a Widget, and our "compiler" could also know: runJavascriptFunction(func_name). The big difference is that in that function you don't need to know what is happening, you call it from the rigth event (checked, selected, unchecked ... ) for a particular scenario.
Let the house burn! 🔥 🙃

Thank you @soufiene-slimi & @pxpm
Regarding the wrapper - that's exactly how I think about it too. Very difficult line to walk, in this case 😀 I saw it as a feature of the "wrapper" too. When I said "field" I was actually referring to the field's wrapper div.

I 100% agree that for dead dead simple tasks it would not be much overhead added using plain JS, but can you try with your example get one field in a specific repeatable row ? I will help you out:

Thank you for the example! I don't think the code itself is an argument for PHP API and against JS API:

if we decide to support subfields:

this bit of JS needs to be written by the maintainers EITHER WAY;
the only difference is if we hide it behind a JS function or a PHP function;

if we decide to NOT support subfields:

this bit of JS needs to be written by the developer anyway;

That being said, I don't see the code as complicated as that. I think in most cases what you'll want is a subfield to show/hide another subfield. So it'd be more like:
// the marketing subfield is hidden by default, only show it if the user has agreed to smth else
$("div[data-repeatable-holder=items] input[name$='[i_agree]']").change(function(){
    var row = $(this).parent('.repeatable-element');
    var marketingSubfield = row.find("name$='[would_you_like_some_spam]'").parent('form-group');

    marketingSubfield.toggleClass('d-none');
});

// notice we can:
// - use $= to see which inputs end with [field_name] in order to select subfields
// - use the DOM to our advantage... we don't need to traverse everything, just the current row

But of course... for repeatable subfields there are other considerations. Like the fact that... they might not exist on pageload. Which is why I think we should not provide subfield hiding/showing. Nobody asked for this, why are we spending time thinking about it?

I was giving some tries hiding some fields etc etc, and I think I got to the point that @soufiene-slimi is refering. Some fields have different wrappers and different artifacts in page that need to be hidden. Hide the labels too ?

Yes. When you hide a field you hide the entire field wrapper. Label, input, everything. Is this questionable in any way? I don't think so...

I don't agree with you that we are writting JS inside controller if we use wrappers. Eg: You are not writting bit code when coding in C, but the compiler will translate what you write into bit code. So basically what I am proposing is a compiler (that have a PREDEFINED set of instructions) that he knows how to handle and transform you PHP code into usable JS.

Yeah, ok... I misspoke. It's not the same thing. I think that's a very good comparison... it is kind of like writing your own compiler, yes. But I think that only goes to strengthen or clarify my negative opinion on this:

as a dev, I don't want the small convenience a compiler would bring; I want freedom;
as a maintainer, I don't want to code, review, bugfix nor maintain a compiler;

I think you're heavily underestimating how long writing that compiler would take, and how bug-prone it would be.

I can not argue about the time commitment to do this feature beeing higher than allowing people to writte JS in controllers, but I cannot see how this will really help to solve this toggable problem if we follow your route.

Hmm... well... it would make it easier. The dev will no longer have to think about:

the proper selector to use (depending on field type);
the proper events to use;
the proper value setting or class to add, to what element in particular;

As a dev, you always do:
crud.field('agree').on("change", function() {
    crud.field('price').show();
});

doesn't matter the field type, it'd still work.

@pxpm please remember to copy-paste here the examples we created yesterday.

CRUD::field([
    'name' => 'add_extra_cost',
    'type' => 'checkbox',
    //'default' => 1
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number', // 10
    'visibleWhen' => ['add_extra_cost', 'isChecked'], // show when check is true
    //'visibleWhen' => ['add_extra_cost', '!==', ''],
    //'enabledWhen' => ['add_extra_cost', '===', 1],
    'emptyWhen' => ['add_extra_cost', 'isUnchecked']
]);

// ---------------------------------------

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => ['person_type', '===', 'business'], // show when select value is business
]);

// ---------------------------------------

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => [
            ['person_type', '===', 'business'],
            ['start_date', '>=', 'end_date'],
        ],
]);

// ---------------------------------------

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => [
            ['person_type', '===', 'business'],
            ['start_date', '>=', 'end_date', 'OR'], // default AND
        ],
]);

// ---------------------------------------

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => [
            ['person_type', '===', 'business'],
            ['start_date', '>=', 'end_date', 'OR'], // default AND
        ],
]);

sources inputs
<input>, <select>, <textarea>
available methods

visibleWhen
emptyWhen
enabledWhen

syntax
[FIELD, OPERATOR, VALUE, PIPE = AND]

Operators - <,>, === etc and: isChecked, isUnchecked

For sure such (verry missing !) feature will require a Backpack Form Sate JS API and to my mind the closest thing I think about is Drupal Conditional Form Fields.
TIP : note the # naming convention for attributes 🥰 !
==> Huge re/work but zero JS line of code for most of case (while keeping possibility to add custom JS, of course).

It looks very similar to what we have prototyped in our last brainstorm about this. I like it @rroblik.
Thanks

Thank you @pxpm & @rroblik . Pedro - let me rephrase your copy-paste, in a way that would help me remember what we talked about, determine if I still think is a good idea, and walk others through our findings, so they can understand and maybe give feedback.

We talked about the solution I proposed above (the JS syntax) as being inconvenient... and maybe not such a good idea after all 😅 Not the syntax itself... but the need to create that JS file or write JS-in-PHP.
What would a solution to problem that be? A PHP syntax. Yep, we're back to that 😅 So we said "ok, let's explore what the most common use cases are, to determine if we can actually create a PHP syntax that will cover all of them". Here's our first draft for that.

Where?
First of all, what items will we need to perform actions on? If you think about it... all Backpack fields store their value in an <input>, <select> or <textarea>, without exception. They're form fields, after all, so even the complex ones will use a hidden input or something... but an <input> nonetheless.
So yes, any solution will have to take that into consideration.
What?
What will we need to perform on Backpack fields, most of the time, to cover 90% of the use cases or more? We narrowed it down to these:

show/hide
change the value
enable/disable

How?
It looks like the needs above will be covered with a PHP syntax consisting of visibleWhen, emptyWhen and enabledWhen, which would receive conditions:

'doSomethingWhen' => ['field_name', 'comparison_operator', 'value']

In practical terms, it would be something like:

'visibleWhen' => ['agreed', '==', true]
'emptyWhen' => ['category', '!=', '3']
'enabledWhen' => ['subtotal', '>=', '99']

Complications
Of course, nothing's that simple. There are also a few complications worth mentioning:

(C1) what operators will we need to support? on most fields, you'll want to do stuff depending on another fields' value; so you can use the normal JS comparison operators:

== (equal to)
=== (equal value and equal type)
!= (not equal)
!== (not equal value or not equal type)
> (greater than)
< (less than)
>= (greater than or equal to)
<= (less than or equal to)
? (ternary operator) - NO, this one doesn't make sense to support;

(C2) however, there are cases where JS comparison operators are NOT enough; for example, you can't do conditionals on checkboxes and radios based on their value, you have to do them depending on their state (checked/not); so they need some new operators, something like:

isChecked
isUnchecked

(C3) additionally, you might want to do show/hide/empty/enable/disable fields not when ONE other field respects a condition, but when MULTIPLE fields respect MULTIPLE conditions; and in that case... the question becomes, what's between those conditions... AND/OR? so we also need to support logical operators, which can be given as a last parameter to the condition:

'visibleWhen' => [
    ['agreed', '==', true, '&&'],
    ['category', '!=', 33]
]

So we ended up with these examples, for the most common scenarios we identified:

// *********
// show a second field when a checkbox is checked
// *********

CRUD::field([
    'name' => 'add_extra_cost',
    'type' => 'checkbox',
    //'default' => 1
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number', // 10
    'visibleWhen' => ['add_extra_cost', 'isChecked'], // show when check is true
    //'visibleWhen' => ['add_extra_cost', '!==', ''],
    //'enabledWhen' => ['add_extra_cost', '===', 1],
    'emptyWhen' => ['add_extra_cost', 'isUnchecked']
]);

// *********
// show a second field when a first field has a certain value (would work with select, input[type=text], textarea)
// *********

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => ['person_type', '===', 'business'], // show when select value is business
]);

// *********
// show a second field when multiple conditions are met, on different fields
// *********

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => [
            ['person_type', '===', 'business'], // if a fourth parameter is missing, we assume "AND" / "&&"
            ['start_date', '>=', 'end_date'],
        ],
]);

// *********
// show a second field when one of multiple conditions are met, on different fields
// *********

CRUD::field([
    'name' => 'person_type',
    'type' => 'select',
    'options' => ['person', 'business'],
]);

CRUD::field([
    'name' => 'extra_cost_value',
    'type' => 'number',
    'showWhen' => [
            ['person_type', '===', 'business'],
            ['start_date', '>=', 'end_date', 'OR'], // default AND
        ],
]);

// Questions here: should the operator be on the FIRST or SECOND condition?!

That's it. That's the rephrase. Hope it makes better sense now (to us and to others). I'll type out a second reply here with my thoughts on it.

I disagree with most of what you said 😀

😅 That's why we're here, that's why we're talking about it in the open 😅 Thanks for pitching in!

Features we are talking about here require a JS API to leverage server side to client side rules "conversions".

I guess you're right. To make this feature complete, the PHP syntax would ALSO require the JS syntax I mentioned at the top of this issue. That would:

make it both easily usable AND extensible 👍
probably double the time of development 👎

Also about CON3 : this JS API must/will be expendable, by design.

That's the thing:

the JS API can be extensible by design; but you might not even need to extend it at all; you can just code your own JS or jQuery or Vue or whatever you want, to do whatever you want;
the PHP API cannot be extensible by design; we would basically need to modify all fields to account for this new feature, which is definitely not worth it; the implementation would become very complicated;

One other (small) thing you didn't mention is the validation : sometimes a field become mandatory depending on other field value. We can already manage it server side but not client side.

DAMN IT! See? That's what I was saying... with the new scenarios that will keep popping up. Yes you might want to make something required depending on what's happening in the form. Makes perfect sense.
Problem is... on the front-end you can only manipulate the front-end required status, NOT the PHP validation... So even if you add an asterisk to it and make require input... the back-end validation would still need to account for both scenarios.
This is food for thought... thank you.

hard work in perspective but... with Pro all become possible !

That's the attitude!!! 💪

Scenarios so far:

[ ] MUST: when a checkbox is checked, show a second field;
[ ] MUST: when a checkbox is checked, show a second field AND un-disable/un-readonly it;
[ ] MUST: when a radio has something specific selected, show a second field;
[ ] MUST: when a select has something specific selected, show a second field;
[ ] MUST: when a checkbox is checked AND a select has a certain value, then show a third field;
[ ] MUST: when a checkbox is checked OR a select has a certain value, then show a third field;
[ ] SHOULD: when a select is a certain value, show a second field; if it's another value, show a third field;
[ ] SHOULD: when a checkbox is checked, automatically check a different checkbox or radio;
[ ] COULD: when a text input is written into, write into a second input (eg. slug);
[ ] COULD: when multiple inputs change, change a last input to calculate the total or smth;
[ ] WON'T: when a checkbox is checked, make a different field required; (can't edit PHP validation from front-end)

Scenarios so far:

[ ]  MUST: when a checkbox is checked, show a second field;
[ ]  MUST: when a checkbox is checked, show a second field AND un-disable/un-readonly it;
[ ]  MUST: when a radio has something specific selected, show a second field;
[ ]  MUST: when a select has something specific selected, show a second field;
[ ]  MUST: when a checkbox is checked AND a select has a certain value, then show a third field;
[ ]  MUST: when a checkbox is checked OR a select has a certain value, then show a third field;
[ ]  SHOULD: when a select is a certain value, show a second field; if it's another value, show a third field;
[ ]  SHOULD: when a checkbox is checked, automatically check a different checkbox or radio;
[ ]  COULD: when a text input is written into, write into a second input (eg. slug);
[ ]  COULD: when multiple inputs change, change a last input to calculate the total or smth;
[ ]  WON'T: ~when a checkbox is checked, make a different field required;~ (can't edit PHP validation from front-end)

Thanks for sum up!
SHOULD  : ➡ Same logic as the MUST ones so yes, it's also a MUST !
WON'T : ➡ but should be done front side, à required field look same as not required, except that the "*" appended to the label.  Hope that is doable using JavaScript 😆
once again to my mind Drupal way of doing this must be double checked, it's the way to go without reinventing the wheel !

Regarding a field becoming mandatory based on other inputs, sometimes you need to duplicate code in both the frontend and backend, whether you're using a framework or not.
I like the ideas here, but I hope it doesn't become too over-complicated that nobody will be able to figure out how to use it or that it becomes too hard to maintian

I like the ideas here, but I hope it doesn't become too over-complicated that nobody will be able to figure out how to use it or that it becomes too hard to maintian

That's my fear too...

Regarding a field becoming mandatory based on other inputs, sometimes you need to duplicate code in both the frontend and backend, whether you're using a framework or not.
I like the ideas here, but I hope it doesn't become too over-complicated that nobody will be able to figure out how to use it or that it becomes too hard to maintian

For sure server side validation remain mandatory. In fact with backpack there is not client side validation so this must stay like that 😉. I only speak about mandatory field, add a span for the * must be faisable 😀

This is all interesting stuff, I've been following these discussions for a while as it always crops up that I need to show certain fields when certain conditions are met.
For the past week I've been wondering if we need a more generic scaffold solution. So all the common logic is in a class, and we (the developers) write a field/column that extends this logic for specific use cases.
But I'm enjoying the current way of thinking, I remember being around when the drupal form api was in its' infancy!
One thing I would like to mention is, does BackPack need to encompass all use-cases? I know drupal does as that's what kind of beast it is (more for end users than devs) but shouldn't there be some element of development logic for us end users being as we are developers?!

@fronbow Drupal Form API is not for end users but for developers and Drupal admin UI rely on it. Here with backpack no admin ui, only in code possibility ; main reason why we need an real Form API like that in Backpack !

I finally finished the reading! It's awesome to read process like that, always constructive.
I like a lot of the backend/php solution with the wheres-alike conditions, seem really versatile, from my point of view.
I'm not sure I'm adding something constructive, but for theses :

CON 1 - 🟨 - I don't like showWhen&disableWhen very much... maybe we find a different way around this duplication;

CONs - What I don't like about this PHP solution (and proposed workarounds for some):

(CON 1) I think most of the time, you won't only need to show/hide some field, you will also need to disable it, in order to not have it in the request; so what you end up with, most of the time, is writing the same conditions twice; so then... most of the time you use this feature... you'll end up with duplicated code; this is even more visible when you have multiple conditions:

It seems to me like the disable and hiding should be set based on the field's setting.
If I try to explain my pov here :

If you needed the field to always have a value (in the request and in the validation)
The showWhen conditions will hide the field but keep it available, to have its value in the request

This would use the default value of the field
But I feel this opens more cases and the need of a : default-value-when-hidden

If you can avoid having the field, and the field isn't required,
The show/hide feature disable and hide the field

Need more brainstorming :
I think hiding the field completely helps the reading and decluttered forms in general.
It's more a UX question, but I feed I would like to set this in a more general way, aside from each field.
Maybe in the config file : conditional_field_hidding_behavior : hide, grayed out. And I would implement only the hiding first. And see if it's a thing.
Anyhow, I hoped this makes sense a bit. I might be to late.
Love this process and thanks for inviting me to comment on it.

@ashek1412  I would say the plan is : https://github.com/Laravel-Backpack/CRUD/issues/4158#issuecomment-1037917117
But only iterative dev and test would tell what would be the v1.0 for this.

It's a real shame that the issue is still not solved after all these discussions. My client bought the Backpack PRO and I can't give him a solution. It's a real shame for the Backapak team.

@ashek1412 Everything is gonna be OK, you'll find a solution for your problem. Don't push down an entire package on one missing features. That is planned btw.
I think that is not the place to ask that and say that.
It's awesome that the backpack team asks the community and brainstorm with them for the implementations of the feature.

however, I have to do it using javascript for the time being. but when you guys put your plan into action?

Hi everyone!
I've done this in the past, using Javascript, I created a simple solution for what I needed at that time, take a look at the result;
https://user-images.githubusercontent.com/1838187/161063634-b3cc44fb-201e-471a-adea-7cee785f0425.mp4
You can show/hide based on select and input[type="checkbox"].
Until Backpack provides a solution for this, you can use this code. It uses wrapperAttributes to add attributes to fields (select, checboxs) so it hides and shows based on that
It's super easy to implement, here is the code;
public/assets/js/backpack-toggle.js

JavaScript
let toggleInputFields = elem => {
  const targetsIds = elem.dataset.toggles.split(' ');
  targetsIds.forEach(id => {
    const targetElem = document.querySelector(
      `#${id}, [data-field-name=${id}]`
    );

    const checkbox = elem.querySelector('input[type="checkbox"]');
    targetElem.classList.toggle('d-none', !checkbox.checked);
  });
};

let toggleSelectFields = elem => {
  const { value } = elem;
  const { dataset: { toggles }} = elem.closest('[data-toggles]');

  document.querySelectorAll(`[${toggles}]`).forEach(field => {
    let r = false;

    // Check if json or single value
    try {
      r = !JSON.parse(field.attributes[toggles].value).includes(value);
    } catch (e) {
      r = field.attributes[toggles].value !== value;
    }

    // Toggle visibility
    field.classList.toggle('d-none', r);

    // Clear any child selects
    field.querySelectorAll('[data-toggles] select').forEach(select => {
      select.value = '';
      toggleSelectFields(select);
    });
  });
};

let initTogglers = () => {
  document.querySelectorAll('[data-toggles]').forEach(elem => {
    const field = elem.querySelector('input[type="checkbox"], select');
    // eslint-disable-next-line default-case
    switch (field.type) {
      case 'checkbox':
        // On click
        elem.addEventListener('click', () => {
          toggleInputFields(elem);
        });

        // Check initial status
        if (elem.querySelector('[type=checkbox]').checked) {
          toggleInputFields(elem);
        }
        break;
      case 'select-one':
        // On change
        $(elem).on('change', () => {
          toggleSelectFields(field);
        });

        // Check initial status
        toggleSelectFields(field);
        break;
    }
  });
};

document.addEventListener('DOMContentLoaded', initTogglers);

public/assets/css/backpack-toggle.css

CSS
.form-quote {
  border-left: 1px solid #e7e8ea;
  margin-left: 2rem;
  max-width: calc(100% - 4rem);
  margin-bottom: 0;
  padding-top: 0.5rem;
  padding-bottom: 0.5rem;
}

app\Http\Controllers\Admin\EntityCrudController.php

PHP
protected function setupCreateOperation() {
    Widget::add()->type('script')->content('assets/js/backpack-toggle.js');
    Widget::add()->type('style')->content('assets/css/backpack-toggle.css');
    ...

// Select Toggler
CRUD::addField([
    ...
    'wrapperAttributes' => [
        'data-toggles' => 'toggler-device-type',
    ],
]);

CRUD::addField([
    ...
    'wrapperAttributes' => [
        'class' => 'd-none form-group col-sm-12 form-quote',
        'toggler-device-type' => 'win',
    ],
]);

// Checkbox Toggler
CRUD::addField([
    ...
    'wrapperAttributes' => [
        'class' => 'field-toggler form-group col-sm-12',
        'data-toggles' => 'hours minutes',
    ],
]);

CRUD::addField([
    ...
    'wrapperAttributes' => [
        'class' => 'd-none col-12 form-quote',
        'id' => 'hours',
    ],
]);

CRUD::addField([
    'name' => 'minutes',
    ...
    'wrapperAttributes' => [
        'class' => 'd-none col-12 form-quote',
        'id' => 'minutes',
    ],
]);

The example video above uses the following code;
app\Http\Controllers\Admin\EntityCrudController.php

Example PHP
protected function setupCreateOperation() {
    Widget::add()->type('script')->content('assets/js/backpack-toggle.js');
    Widget::add()->type('style')->content('assets/css/backpack-toggle.css');

    // Toggler Device Type
    CRUD::addField([
        'name' => 'device_type',
        'label' => 'Device type',
        'type' => 'select_from_array',
        'options' => [
            'win' => 'Windows',
            'linux' => 'Linux',
            'mac' => 'Mac',
            'unix' => 'Unix',
        ],
        'default' => 'win',
        'wrapperAttributes' => [
            'data-toggles' => 'toggler-device-type',
        ],
    ]);

    CRUD::addField([
        'name' => 'win_script',
        'label' => 'Windows script',
        'wrapperAttributes' => [
            'class' => 'd-none form-group col-sm-12 form-quote',
            'toggler-device-type' => 'win',
        ],
    ]);

    CRUD::addField([
        'name' => 'win_type',
        'label' => 'Windows type',
        'type' => 'select_from_array',
        'options' => [
            'win10' => 'Win 10',
            'win11' => 'Win 11',
        ],
        'default' => 'win',
        'wrapperAttributes' => [
            'class' => 'd-none form-group col-sm-12 form-quote',
            'toggler-device-type' => 'win',
            'data-toggles' => 'toggler-win-type',
        ],
    ]);

    CRUD::addField([
        'name' => 'win11',
        'label' => 'Windows 11 special function',
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'toggler-win-type' => 'win11',
        ],
    ]);

    // ---

    CRUD::addField([
        'name' => 'linux_title',
        'label' => 'Linux title (unix / linux)',
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'toggler-device-type' => json_encode(['linux', 'unix']),
        ],
    ]);

    CRUD::addField([
        'name' => 'mac_title',
        'label' => 'Mac title (unix / mac)',
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'toggler-device-type' => json_encode(['mac', 'unix']),
        ],
    ]);

    CRUD::addField([
        'name' => 'unix_script',
        'label' => 'Unix script (unix / (linux / mac))',
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'toggler-device-type' => json_encode(['unix', 'linux', 'mac']),
        ],
    ]);

    // Toggler time
    CRUD::addField([
        'name' => 'scheduled_time',
        'label' => 'Scheduling time',
        'type' => 'checkbox',
        'wrapperAttributes' => [
            'class' => 'field-toggler form-group col-sm-12',
            'data-toggles' => 'hours minutes',
        ],
    ]);

    CRUD::addField([
        'name' => 'hours',
        'label' => 'Hours',
        'type' => 'select2_from_array',
        'options' => range(0, 23),
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'id' => 'hours',
        ],
    ]);

    CRUD::addField([
        'name' => 'minutes',
        'label' => 'Minutes',
        'type' => 'select2_from_array',
        'options' => range(0, 60),
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'id' => 'minutes',
        ],
    ]);

    // Toggler weekdays
    CRUD::addField([
        'name' => 'scheduled_weekdays',
        'label' => 'Scheduling weekdays',
        'type' => 'checkbox',
        'wrapperAttributes' => [
            'class' => 'field-toggler form-group col-sm-12',
            'data-toggles' => 'weekdays',
        ],
    ]);

    CRUD::addField([
        'name' => 'weekdays',
        'label' => 'Weekdays',
        'type' => 'select2_from_array',
        'allows_multiple' => true,
        'options' => ['Sunday', 'Monday', 'Tuesday', 'Wednesday', 'Thursday', 'Friday', 'Saturay'],
        'wrapperAttributes' => [
            'class' => 'd-none col-12 form-quote',
            'id' => 'weekdays',
        ],
    ]);
}

Nice ! Bottom line :

you cannot handle required fields properly with that
Lot of code repetition (wrapper base class for example)

That must stay what you say : a workaround only

I'm back with good news. Like I said, I think the first steps towards a good solution are:

having a documented way to easily do the top 10 most common scenarios; even if it's verbose / vanilla JS / jQuery;
having a JS library to interact with fields, with examples for simple scenarios;
having a JS library to interact with fields, so that when you get to do complicated stuff, you only think about your custom stuff, not field selectors and other boilerplate like that;

And the above are... pretty much done! At least the working version, that I can show (v7 in my prototypes though 😅).
Check out https://github.com/Laravel-Backpack/CRUD/pull/4312 - where I've created a small JS library to help devs interact with fields. It's got only ~90 lines of JS, but it covers ALL the scenarios we talked about. I even included the proof 😅 It still needs feedback but... I kind of like it. It's a simple solution to a complicated problem. And I love it when that happens.
Let me know what you guys think.
Cheers!

Nice! I love simple solutions to complicated problems. I'll have to take a look at it later

I'm going to close this issue, in order to move the conversation to the PR here https://github.com/Laravel-Backpack/CRUD/pull/4312 🎉🎉🎉
It would be super-difficult for anybody to read all this thread anyway.


Not very clear when a mail has an attachment

It is not visually clear when a mail has an attachment.  One has to open the mail, click on the mime tab to see the attachment.  There is no paperclip icon or symbol from the inbox view or message view to show there is an attachment.

Is there any plan to enrich maiilhog web ui to allow to download the attached files by clicking on a their names ?
It think it should be easy to modify mailhog UI to add this feature since the attachements are already listed
Thanks for your help

Maybe I could try to make a PR on this subject but i don't know how to modify html and js files since their are embedded in a bindata go file.
How can I try to edit the HTML and JS files ?

up!

Up!


use releaxedJson for get behind a flag

Signed-off-by: Mukundan Sundararajan<EMAIL_ADDRESS>Description
Follow up to #1581 , have put the relaxedJson representation behind a flag in GetRequest alone.
When this metadata is passed in GetRequest, then relaxedJson representation is used, else the v1.6.0 behavior of canonicalJson will be used. This will make the PR 1581 as not a breaking change immediately for a Stable component Get API.
After 2 releases following normal Dapr deprecation policy, this flag can be removed.
For now it will be deprecated and a Warning log will be printed for every Get Request which uses canonical json representation.
Issue reference
We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.
Please reference the issue this PR will close: #[issue number]
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[x] Code compiles correctly
[x] Created/updated tests
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: dapr/docs#[issue number]

I think it is better to keep the breaking change and not default to the warning behavior.

closing this PR.


incorrect parsing of regex?

I hadn't worked with rust in months so I made major updates of both rustc and my dependencies (including regex). I noticed that my program was now failing in a weird way and I finally tracked it down to this bug (regression?), either that or I'm doing something very wrong here:
let re = Regex::new(r"(^\.)|(~$)").unwrap();
assert!(!re.is_match("favicon.png"));

That assertion is failing even though it shouldn't AFAIK. It certainly didn't before.
The regex is supposed to match if the string begins with . or ends with ~. Even without the groupings/capture groups it fails. Somehow it is matching on "favicon.png".
I can't imagine something like this got through though so I'm thinking it may be a misunderstanding I have of how that regex should work. I tried this just now in the chrome console with javascript and I don't see this problem there, though I am aware that regex implementations tend to differ, I wasn't aware that they differ in something like this.

Regulex seems to confirm my understanding of this pattern, unless I'm misunderstanding the diagram too.

Gah. This is probably a bug in the literal optimizer being too aggressive. I'll check it out tomorrow.

No worries, I would appreciate it.

@blaenk Interestingly, running re.find("favicon.png") returns None as it should. The reason why is because the forward DFA was falsely reporting a match, but the backward DFA correctly determined it not to match. The is_match routine only uses the forward DFA, which resulted in the incorrect match bubbling up.
In any case, the underlying cause was indeed an aggressive literal optimization. #281 should fix it!

Ahhh. Thank you very much for fixing this!

No rush but do you have any idea when a new release will be out on crates.io with this fix? Or is there some set release schedule?

It's uploading. :-)

Thank you very much once again!!

No problem. 0.1.77 is now on crates.io! Thanks for the bug report!


chore(SetTheory/Ordinal/Artihmetic): clean up pred API

This PR does the following:

Use o ∈ range succ instead of the full (and backwards) spelling ∃ a, o = succ a
Add the missing convenience lemmas pred_eq and pred_one
Golf proofs, or otherwise remove term mode sorcery
Remove the unnecessary Set prefix in Set.range while we're at it

Closing since I plan on generalizing pred and deprecating this definition instead.


Bumping odo version v2.0.7 -> v2.0.8

Signed-off-by: Mohammed Zeeshan Ahmed<EMAIL_ADDRESS>

/retest

/approve


Can't run test mode

time bin/manga-downloadr --test
/home/rodrigo/temp/src/elixir-tests/manga-downloadr/lib/manga-downloadr/workflow.rb:30:in `fetch_chapters': wrong number of arguments (given 0, expected 1) (ArgumentError)
        from /home/rodrigo/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/chainable_methods-0.1.3/lib/chainable_methods.rb:36:in `method_missing'
        from /home/rodrigo/temp/src/elixir-tests/manga-downloadr/lib/manga-downloadr/workflow.rb:23:in `run_tests'
        from bin/manga-downloadr:71:in `block in <main>'
        from /home/rodrigo/.rbenv/versions/2.3.1/lib/ruby/2.3.0/benchmark.rb:293:in `measure'
        from bin/manga-downloadr:70:in `<main>'

The problem seems to be the newer version of chainable_methods (0.1.3) which satisfies the Gemfile but is really backwards incompatible with 0.1.2 since it swaps the arguments passed to CM:
https://github.com/akitaonrails/manga-downloadr/blob/master/manga-downloadr.gemspec#L17
Swapping the arguments to CM allowed the app to work. I'm not submitting any patches as I have no ideas on how you prefer to fix this.

Sorry about that, you're right, I fixed that.


[TSDoc Home page]: Horizontal scroll bar appears in 'Code' part when text spacing is enabled.[Sev3][WCAG1.4.12][WCAG2.1]

Test Environment:
OS Build: Windows 10
Browser: Edge Dev
URL: https://tsdoc.org/
Repro Steps:

Open the above URL and login with valid credentials.
TSDoc page will get displayed.
Now enable the ‘Text Spacing’.
Now navigate to 'Intro' link and activate it.
Navigate to 'Code' part which is available in 'What is TSDoc' page and observe the issue.

Actual:
Horizontal scroll bar appears in 'Code' part when text spacing is enabled in 'What is TSDoc' page.
Expected:
Horizontal scroll bar should not appear in code part when text spacing is enabled in 'What is TSDoc' page.
User Experience:
Users with dyslexia and low vision who need to increase space between text to make a better experience will be impacted if horizontal scroll bar appears in 'Code' part when applying Text spacing.
Note: This issue is repro through out the TSDoc URL where ever 'Code' part is available.
WCAG Reference:
https://www.w3.org/WAI/WCAG21/Understanding/text-spacing

This issue has been closed because this Jekyll project has been retired. The documentation content has been migrated to Docusaurus.
If the problem has not been addressed, please file a new issue under this GitHub project instead:
https://github.com/microsoft/rushstack-websites


Np to vtk cnvrt

Added tools for converting numpy arrays to vtk Objects, as well as the opposite (vtk Objects to numpy arrays).
Additional tools and examples to follow.

Aren't a large number of these files already in other PRs?

I'm going to make a few restructuring suggestions, but after those have been done I would advocate for simply merging this PR and dealing with issues as they crop up... @tacaswell I know you're not going to like this very much, but this PR is literally never going to get merged otherwise

My vision of what would go in the skxray/api/ folder was science namespaces. With that in mind, I'd like to collapse all of the skxray/api/image_processing/* files into a single skxray/api/image_processing.py module

I would like to see the skxray/img_proc/ folder renamed to skxray/image/

Rename skxray/img_proc/imgQuant.py to skxray/img_proc/quant.py

Rename skxray/io/RAW_io.py to skxray/io/raw.py

Many of your files in the io directory have _io appended to them. Can you get rid of the _io appendage from these? It is unneeded as they are already in the io directory

Can you rename skxray/io/vtk_tools to skxray/io/vtk?

Is there anyway to chop this up into a number of smaller PRs?  2k lines is an absolute bear to review.

@tacaswell : Holy smokes. I'm suspect that all of those additional commits were included because I probably created the branch while in another branch. I'll fix that because I meant for this PR to ONLY focus on numpy/VTK data conversion, with the next PR(s) to focus on VTK visualization and quantification tools.

The current commit generates a segmentation fault when an additional operation is executed on the "converted" data/array. This suggests that there is a problem with the conversion process and that the conversion is NOT currently working as it is supposed to.
Currently writing a conversion test that evaluates whether a given data set, and data type converts correctly.

Need to get in touch with kitware. Contact them about errors associated with numpy_support.np_to_vtk

Take a look at the docstring as well. (It mentions the segfaults.)
On Thu, Apr 16, 2015 at 1:26 PM Gabriel Iltis<EMAIL_ADDRESS>wrote:

Need to get in touch with kitware. Contact them about errors associated
with numpy_support.np_to_vtk
—
Reply to this email directly or view it on GitHub
https://github.com/Nikea/scikit-xray/pull/246#issuecomment-93790611.

@giltis Any progress on this?

@giltis Any luck avoiding the segfaults by following the docstrings? Once we know it has worked for someone in our group once, we can check this off our list and thank VTK for doing it for us.

maybe this one can be closed?


[OTHER] How does Conventional Changelog Action create CHANGELOG.MD

What would you like to share?
I would like to know how Conventional Changelog Action works as I too want to this in my project. I pasted the exact same code of the workflow of releases.yml, into my project but that didn't work for some reason. Please help me out.
Additional information
Feel free to move this to discussions as it's not related to Linkfree, I can't post it on the discord as I'm not verified there.

Hi 👋  I suggest opening discussions instead of issues for this :) You don't need to ping everyone, we shall and will see your queries.
Can I get a link to your implementation to diagnose the issue?

Will move this to discussions. Yes... I was trying to avoid pinging anyone
but they made the file lol, so thought they would know something about it
so pinged, but won't next time.
I did it in a personal organization repo, I think so you will have to
accept the github organization request.
On Sat, 12 Feb 2022 at 21:38, Krish Gupta @.***> wrote:

Hi 👋 I suggest opening discussions instead of issues for this :) You
don't need to ping everyone, we shall and will see your queries.
Can I get a link to your implementation to diagnose the issue?
—
Reply to this email directly, view it on GitHub
https://github.com/EddieHubCommunity/LinkFree/issues/1121#issuecomment-1037272501,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUGJUTJK32YZMUVLAYTTNRDU22AYPANCNFSM5OHCCBOA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you authored the thread.Message ID:
@.***>

Will move this to discussions. Yes... I was trying to avoid pinging anyone but they made the file lol, so thought they would know something about it so pinged, but won't next time. I did it in a personal organization repo, I think so you will have to accept the github organization request.
…
On Sat, 12 Feb 2022 at 21:38, Krish Gupta @.> wrote: Hi 👋 I suggest opening discussions instead of issues for this :) You don't need to ping everyone, we shall and will see your queries. Can I get a link to your implementation to diagnose the issue? — Reply to this email directly, view it on GitHub <#1121 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUGJUTJK32YZMUVLAYTTNRDU22AYPANCNFSM5OHCCBOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID: @.>

Seems that I have deleted the repo, or can't find it rn. Making on on my profile and will make you collabarotor.

Will move this to discussions. Yes... I was trying to avoid pinging anyone but they made the file lol, so thought they would know something about it so pinged, but won't next time. I did it in a personal organization repo, I think so you will have to accept the github organization request.
…
On Sat, 12 Feb 2022 at 21:38, Krish Gupta @.> wrote: Hi 👋 I suggest opening discussions instead of issues for this :) You don't need to ping everyone, we shall and will see your queries. Can I get a link to your implementation to diagnose the issue? — Reply to this email directly, view it on GitHub <#1121 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUGJUTJK32YZMUVLAYTTNRDU22AYPANCNFSM5OHCCBOA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>
Seems that I have deleted the repo, or can't find it rn. Making on on my profile and will make you collabarotor.

REPO LOCATED HERE @krshdev : https://github.com/KendallDoesCoding/release-testing/

Hi 👋 I suggest opening discussions instead of issues for this :)

I will have to make a new discussion thread, let the maintainers do it so this thread will remain as it is if they tap the "Convert to Discussion" button.

Hey @KendallDoesCoding did you add this token? https://github.com/KendallDoesCoding/release-testing/blob/main/.github/workflows/release.yml#L18

Hey @KendallDoesCoding did you add this token? https://github.com/KendallDoesCoding/release-testing/blob/main/.github/workflows/release.yml#L18

I tried doing it in the original repo, but idk if i did it correctly, how do I make a token?

Hey @KendallDoesCoding did you add this token? https://github.com/KendallDoesCoding/release-testing/blob/main/.github/workflows/release.yml#L18

I tried doing it in the original repo, but idk if i did it correctly, how do I make a token?

Awaiting for reply Krish!

env:
          GITHUB_TOKEN: ${{ secrets.github_token }}

With this it should work

env:
          GITHUB_TOKEN: ${{ secrets.github_token }}

With this it should work

wdym, i can't understand.. can you make a pr?

Hey @KendallDoesCoding did you add this token? https://github.com/KendallDoesCoding/release-testing/blob/main/.github/workflows/release.yml#L18

I tried doing it in the original repo, but idk if i did it correctly, how do I make a token?

Github -> Settings -> Developer Settings -> Personal access token with repo perms, then the repo settings and actions -> add the secret with the name of CHANGELOG_RELEASE, @schmelto suggested a alternative, using the default gh token, I will make the PR :)

Thanks for the detailed explanation, testing now.
On Sun, 13 Feb 2022 at 13:41, Krish Gupta @.***> wrote:

Hey @KendallDoesCoding https://github.com/KendallDoesCoding did you add
this token?
https://github.com/KendallDoesCoding/release-testing/blob/main/.github/workflows/release.yml#L18
https://github.com/KendallDoesCoding/release-testing/blob/main/.github/workflows/release.yml?rgh-link-date=2022-02-12T17%3A30%3A53Z#L18
I tried doing it in the original repo, but idk if i did it correctly, how
do I make a token?
Github -> Settings -> Developer Settings -> Personal access token with
repo perms, then the repo settings and actions -> add the secret with the
name of CHANGELOG_RELEASE, @schmelto https://github.com/schmelto
suggested a alternative, using the default gh token, I will make the PR :)
—
Reply to this email directly, view it on GitHub
https://github.com/EddieHubCommunity/LinkFree/issues/1121#issuecomment-1037911856,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUGJUTLOSF6RMFORUZQLSKDU25RSFANCNFSM5OHCCBOA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID:
@.***>

Doesn't seem to work?

Doesn't seem to work?

 I added a commit messege and tried again its still showing this. Sorry for so much inconvenience btw, just i've never used tools like this nor too many workflows before

Your commit message should have the message starting with fix: etc. that the action is triggered

Doesn't seem to work?

 I added a commit messege and tried again its still showing this. Sorry for so much inconvenience btw, just i've never used tools like this nor too many workflows before

Your commit message should have the message starting with fix: etc. that the action is triggered

Oh ok

Perfect it works... Closing for now... Will re-open if face a issue


Support android motion sensors as plugin, make an OSVR Android

If we can create some form of plugin that talks to the Android API when used on an Android target, we can use the Motion Sensors part of the API: http://developer.android.com/guide/topics/sensors/sensors_motion.html to access what the phone believes the current orientation of itself is. That would allow us to support using Android without the need for root.
With that in mind, it may also be beneficial to create an Android app which acts as a simple wrapper to start the osvr_server instance when an app requests it, and close it when the app exits. This would mean not having to manually start the OSVR server via SSH, which simply goes against how Android apps are supposed to work.
You could edit the OSVR configuration inside of that app too (hopefully graphically), which seems like it would be the best way to support Android moving forward (rather than the clunky hack it currently has to use)

Hopefully this evening, although I won't make any promises, I'll see what I can do to figure out how to wrap the Java-based Motion Sensors interface back into a plugin that OSVR can use. I've had some experience with wrapping SWIG, but SWIG is generally intended for wrapping C++ libraries and letting a Java/C#/etc program access them, rather than the other way around.

You might find some inspiration in one of the VRPN Android projects, that I believe did that (the sensor thing). Think it's this file and neighboring code - was a course project, so there's docs and things. https://github.com/vrpn/vrpn/blob/master/vrpn_android/comp523android/src/edu/unc/cs/vrpn/AccelerometerListener.java
Would be nice if Google's Cardboard tracking stuff (which I get the impression extends the built-in sensors somehow) could be plugged in.
I think the idea for Android going forward is to have a service and a GUI, yes, but not necessarily related to this code.

Oh, perfect! That's probably exactly what I'm looking for. I may even be able to restructure the oculus-rift plugin to use this, since it already uses VRPN.

Have you had a chance to work on this at all?

I unfortunately have not. I did manage to root my phone, but I've been
rather tied up with my job and some community events on Steam.
I was hoping to do it on the weekend but I haven't had a free weekend since
last month. Have you got any news?
On Tue, Jul 14, 2015 at 12:45 PM, Ryan Pavlik<EMAIL_ADDRESS>wrote:

Have you had a chance to work on this at all?
—
Reply to this email directly or view it on GitHub
https://github.com/OSVR/OSVR-Core/issues/164#issuecomment-121304617.

It appears as though some work is already being done for this on the OSVR Android Build git. Excellent! I'll see if there isn't a chance I can improve the Linux build system/paths instead, since that was the next thing on my list.

The server app would also be useful, probably more useful than the Linux build system at the moment (those are quick updates for me when I get a chance).

There is now a simple plugin for Android which uses the built-in sensors for head-tracking. It's using the built in sensor fusion from android (the software rotation vector sensor). There need to be some enhancements in the long term, such as predictive tracking and custom sensor fusion/filtering like the Cardboard SDK does, but it's usable:
https://github.com/OSVR/OSVR-Android-Plugins


E2E: go tag main SLSA3 config-ldflags assets

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.2
Run: https://github.com/slsa-framework/example-package/actions/runs/2276758561
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.2
Date: Thu May  5 15:53:04 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/2276755977
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: main
Date: Thu May  5 15:53:24 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.3
Run: https://github.com/slsa-framework/example-package/actions/runs/2276806501
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.3
Date: Thu May  5 16:01:43 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.4
Run: https://github.com/slsa-framework/example-package/actions/runs/2276811062
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.4
Date: Thu May  5 16:03:05 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.6
Run: https://github.com/slsa-framework/example-package/actions/runs/2276848066
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.6
Date: Thu May  5 16:09:36 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.8
Run: https://github.com/slsa-framework/example-package/actions/runs/2277058507
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.8
Date: Thu May  5 16:54:32 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.9
Run: https://github.com/slsa-framework/example-package/actions/runs/2277110671
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.9
Date: Thu May  5 17:06:36 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.0.10
Run: https://github.com/slsa-framework/example-package/actions/runs/2277540380
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.0.10
Date: Thu May  5 18:36:25 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.10.10
Run: https://github.com/slsa-framework/example-package/actions/runs/2277542426
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.10.10
Date: Thu May  5 18:37:14 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.10.11
Run: https://github.com/slsa-framework/example-package/actions/runs/2277544090
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.10.11
Date: Thu May  5 18:39:26 UTC 2022

Repo: https://github.com/slsa-framework/example-package/tree/v10.10.12
Run: https://github.com/slsa-framework/example-package/actions/runs/2277682011
Workflow name: go tag main SLSA3 config-ldflags assets
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.go.tag.main.config-ldflags-assets.slsa3.yml
Trigger: push
Branch: v10.10.12
Date: Thu May  5 19:06:50 UTC 2022
Tests are passing now. Closing this issue.


On the Species template, fix text color of list-group-item-success

It's blue-on-green, which doesn't look good and is inconsistent with other list-group-items that are also links. Just make the text color black.
(This is currently being used for the "default" variety of a species.)

Actually, it may be preferable to use list-group-item-info instead. Blue seems to work better than green. Still worth looking into the text color.


cloud-init api change breaks upgrade

What happened:
Attempting to upgrade kubevirt from v0.35 to v0.50, workloads started failing because of api field change.
This change updates the hyphen cloud init field instance-id, local-hostname, delimited field to an underscore delimited field (snake case).
Upon upgrade the workloads started failing because it couldnt find instance-id and the omitempty json tag didnt populate the field
What you expected to happen:
VMIs workloads are expected to work with the same configuration as before even after upgrade
How to reproduce it (as minimally and precisely as possible):

Run cloud init configdrive metadata with older kubevirt (v0.35)
upgrade kubevirt
try to create and boot up the same as step 1 vmi again.

Additional context:
Today the api fields have inconsistent keys, the NoCloudMetada continues to have - delimited keys vs snake case in ConfigDriveMetadata.
It would be good to add additional fields LegacyInstanceType with json:"instance-type,omitempty" so that users can define their fields consistently and also the upgrades from older version of the API are not breaking.

/cc @davidvossel

@alaypatel07 I changed the ConfigDrive cloud init metadata to use underscores in the json output because that's the way these fields are interpreted by the ConfigDrive cloud-init DataSource.
So, the field public_keys is known by the ConfigDrive datasouce and results in the injection of those public keys into the guest. the field public-keys is not interpreted by the ConfigDrive datasource and is unknown. The change you refer to was meant to align us with how cloud init worked.

@davidvossel thanks a quick response and the explanation. We dont use the public_keys feature so I wasnt aware, but the instance-id field is what broke this upgrade.
I had two questions for my own understanding:

Does cloud-init config drive also require instance-id, local-hostname are fields to be instance_id and local_hostname?
If they would you be open to adding LegacyInstanceID, LegacyInstanceType, LegacyLocalHostname fields to the metadata to make sure older vmi's work?

Does cloud-init config drive also require instance-id, local-hostname are fields to be instance_id and local_hostname?

I at least had the impression that it got picked up in the past. Considering your feedback, it seems like it worked for you with the old fields but not with the new ones? Is cloud-init itself failing or your payload on top which may parse these fields as well?

2. If they would you be open to adding LegacyInstanceID, LegacyInstanceType, LegacyLocalHostname fields to the metadata to make sure older VMIs work?

If really cloud-init is failing now and not your workload I would say we definitely need a fix. Otherwise the Legacy* path would also be a viable option for me.

@rmohr @davidvossel Apologies in not being clear in the original issue.

I at least had the impression that it got picked up in the past.

Yes, it is getting picked up.

Is cloud-init itself failing or your payload on top which may parse these fields as well?

cloud-init is working properly, but the VMI on  bootup, reads the cloud-init metadata and is in the critical path of a successful bootup.
When the upgrade happened,

the VMIs using cloudInitNoCloud volume source continued to boot up successfully because the instance-id fields was present in the metadata file in the VMI and VMI was happy at boot-time.

# echo $logs | base64 -d
{"instance-id":"foo-bar","hostname":"minikube"}

The VMIs using cloudInitConfigDrive volume source failed because the older instance-id were missing and instead instance_id was present. The startup application found the field missing and was unable to boot up the VM.

# echo $logs | base64 -d
{"instance_id":"foo-bar","hostname":"minikube"}

In order for the VMI to work post upgrade, the application has workaround this by looking for both the fields.
I was wondering if we can add the fields to the ConfigDriveMetadata struct.
	// The following fields are added for backward compatibility so that upgrades go through without downtime and consistency with NoCloudMetadata
	LegacyInstanceTypeSnakeCase  string `json:"instance-type,omitempty"`
	LegacyInstanceIDSnakeCase    string `json:"instance-id,omitempty"`
	LegacyLocalHostnameSnakeCase string `json:"local-hostname,omitempty"`

resulting in
# echo $logs | base64 -d
{"instance_id":"foo-bar","hostname":"minikube", "instance-id":"foo-bar"}

I realized the version skew of the upgrade is large, but I only make this request because I believe the support burden for this insignificant.  I would be happy to put up a PR for it.

So just to summarize:

we did not break cloud-init with this, but
we broke applications which are reading this file as well

It looks to me as well that the maintenance burden of this would be relatively small. I have no objectsion adding a backwadd compatibility fix for third-party applications. @davidvossel ?

So just to summarize:
we did not break cloud-init with this, but
we broke applications which are reading this file as well

This is accurate. The VMI images in our stack are built with many install/post-install scripts which read the metadata json file that is populated by cloud-init. After the upgrade, it was observed that VMIs come up but because of these install/post-install scripts many applications were broken because of the missing instance-id field in the json.
It is much harder to go look at each such script in the tenant codebase than to add the legacy fields back to  ConfigDriveMetadata
cc @rthallisey please keep me honest here if I am misstating anything.

This issue has been discussed in the kubevirt community meeting on the 22nd of February and several voices raised that this is problematic.
The maintenance is not ending with code being added, but with the need to consider deprecated parts for (based on this proposal) indefinitely. While one may not seem much, such a policy will make it very hard to go forward and improve for the long run.
I am pretty sure we have deprecated several fields already and will continue to evolve like that in the future. If we will need to keep supporting everything for so long, we will have a maintenance problem.
I would expect to see multiple users effected by this before considering this as an exception.
Considering the original changed happened more than 20 versions ago, I think that is unlikely.

This issue has been discussed in the kubevirt community meeting on the 22nd of February and several voices raised that this is problematic.

The maintenance is not ending with code being added, but with the need to consider deprecated parts for (based on this proposal) indefinitely. While one may not seem much, such a policy will make it very hard to go forward and improve for the long run.
I am pretty sure we have deprecated several fields already and will continue to evolve like that in the future. If we will need to keep supporting everything for so long, we will have a maintenance problem.

@EdDev There are two problems with the current situation this solution will avoid:

If the application is using cloudInitMetadata source it will have to look for _ fields, if the application is using noCloudMetadata source, it will have to look for - fields. So this is not just affecting backward compatibility, this is also affecting the fact that application needs to be aware of how they are configured.
the upgrades

While the upgrade case might be something that is just affecting us, the first case will affect everyone building images to read from cloud-config metadata which makes this enough to consider the fix IMHO


Logging while dryRun(true)

Hi,
It'd be a good feature if the app logged the actions it is blocking while dry running.
Does that seem acceptable?
Cheers and thanks for the great component :-)

Well with verbose logging for iOS you should still get tracking logged even while dry running. For logging on Android see this link.
Dry run is a feature of the native GA library, and so it is not this module while is explicitly blocking hits. So it's probably good enough to just use the normal logs?