Nick's TODO's (can also be done by community)

This is my TODO list for this repo. I've been really slacking on updates since I'm mostly using Ubuntu these days. That said, I want to keep this repo up-to-date in case I want to switch back to macOS full time.

Update OC to latest (I believe macOS still works on current version)
Post new BIOS config for F9

Optionally update some screenshots for F9

Make it known that I've stopped using the Fenvi because it's janky AF
???
Profit

I used Ubuntu and a couple of other Linux distros for years. Incredibly
stable... but none of my audio software runs on it, except in a
self-defeating way through Wine. Well, I take that back: Presonus does
maintain a Linux version of their Studio One DAW, and there are a couple of
native DAWs that have gotten better. But virtually none of the hundreds of
plug-ins I use will work in that environment. So, Mac/Hackintosh is the way
to go for me at least for now (along with a WIndows 10 laptop).
All that said, it seems to me that some kind of enhanced virtualization is
the post-Intel future for Hackintosh – if, indeed, there is a future.
Wondering what anyone else's take is on this. JW
On Sat, Jan 22, 2022 at 10:37 AM Nick Baughman @.***>
wrote:

This is my TODO list for this repo. I've been really slacking on updates
since I'm mostly using Ubuntu these days. That said, I want to keep this
repo up-to-date in case I want to switch back to macOS full time.

Update OC to latest (I believe macOS still works on current version)
Post new BIOS config for F9

Optionally update some screenshots for F9

???
Profit

—
Reply to this email directly, view it on GitHub
https://github.com/baughmann/designaire-z390-intel-i9-9900k-opencore/issues/57,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQTAP3GRAY277LJCCLIDMCLUXLFKTANCNFSM5MSDQYSQ
.
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 are subscribed to this thread.Message
ID: @.***
com>

@jahwookie Im not too sure there is a long term future. After Apple drops support for Intel Macs, I’d guess that it would be quite a long time before hackintoshes with good performance re-emerge. Like you stated, the future probably lies with virtualization

Maybe so, and that virtualization is easily done in Linux! So maybe I'll be
able to come back to Ubuntu one day...
On Sat, Jan 22, 2022 at 11:16 PM Nick Baughman @.***>
wrote:

@jahwookie https://github.com/jahwookie Im not too sure there is a long
term future. After Apple drops support for Intel Macs, I’d guess that it
would be quite a long time before hackintoshes with good performance
re-emerge. Like you stated, the future probably lies with virtualization
—
Reply to this email directly, view it on GitHub
https://github.com/baughmann/designaire-z390-intel-i9-9900k-opencore/issues/57#issuecomment-1019410860,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQTAP3AZV7XQPXES4UTSKPLUXN6IBANCNFSM5MSDQYSQ
.
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:
<baughmann/designaire-z390-intel-i9-9900k-opencore/issues/57/1019410860@
github.com>

CaseySJ added a way to use the internal BT/WiFI in the motherboard:
https://www.tonymacx86.com/threads/asus-z690-proart-creator-wifi-thunderbolt-4-i7-12700k-amd-rx-6800-xt.318311/post-2331654
Any thoughts to integrate that into the repo? I know it means losing a USB port... or two...

@jordanurbs Thanks for letting me know about this. There should be a way to include it, maybe as an alternate EFI.  Looks like they are using is SSDT patching to enable disable USB ports. Leave it with me for the next release.
Thanks again.

@jordanurbs Thanks for letting me know about this. There should be a way to include it, maybe as an alternate EFI. Looks like they are using is SSDT patching to enable disable USB ports. Leave it with me for the next release.
Thanks again.

Cheers @seven-of-eleven! And thanks for taking over this repo.
Just some feedback. CaseySJ also released an EFI set-up using internal BT/WiFi and iMacPro19,1, which is what I was using for a month or two, up until this week. It has HS14 enabled but none of the USB-C/thunderbolt ports work unless they are true thunderbolt devices (otherwise they are disabled as USB devices)--which can be frustrating.
So I decided to give this repo a try again since you've taken over in the legend @baughmann's absence, and it still gives me one USB-C port behind the machine.
However..... On this EFI (same hardware), I get random shutdowns (mostly during sleep) and it seems overall poorer performance with this compared to CaseySJ's new-ish EFI. I haven't run any actual tests to confirm poorer performance but just feels that way.
I have been trying myself to disable HS11 and enable HS14 for mobo BT/Wifi to see how it'll perform in this EFI, but with no luck, because I still haven't gotten the hang of mapping USB Ports. CaseySJ also kept it at iMac19,1, which also may have something to do with the issues I'm experiencing using MacPro7,1
I would personally love to try a version of this repo enable internal BT/WiFi while leaving a USB-C port open, and to see how it fares with iMac19,1
Cheers!

@jordanurbs I'm working on an update now that OC 0.8.5 is released. It should be complete in a couple of days.

@jahwookie unfortunately I don't have a Thunderbolt device to test with. If you can recommend a cheap Thunderbolt device I'll pick it up and test it out. Thanks.

@jordanurbs let me know if the 2nd EFI works for you. It is working for me. All the best.

@seven-of-eleven THANK YOU!!!
I feel like I can breathe again. Machine is running incredibly, and I have so many ports!
Your efforts are appreciated :)

@jordanurbs are you on Monterey or Big Sur? And if Monterey, is Bluetooth 100% reliable for you?
I had previously used OpenIntelWireless kexts for bluetooth with Big Sur and had mostly success. Not so much with Monterey. Weird "volume hash mismatch" errors and bluetooth connection instability.
Some examples:

AirPod Pros would sometimes just cut out and it seemed like Bluetooth completed crashed. Had to restart.
Trackpad would never reliably connect after a restart. Sometimes couldn't get it to connect again. Battery was draining VERY quickly (suggesting disconnecting over and over again)

My original motivation for using OpenIntelWireless for Bluetooth was to eliminate the need for the internal motherboard USB 2.0 header as part of the USB port mapping for the Fenvi card. My Bluetooth troubles might have been caused by using a mixture -- Bluetooth from the Intel chipset and WiFi from the Fenvi/Broadcom card.
So, for me personally, now that I'm on Monterey, I've switched backto Fenvi/Broadcom for both Bluetooth and WiFi and I've disabled the Intel Wifi option in the BIOS. Since I have the Fenvi card, I'm not really sure why I was fighting it :)  I may give it a try again in a few months if it looks like there is more progress at OpenIntelWireless.

@JonMcL I'm on Monterey and using the internal Bluetooth now as well. I'm not having any issues with my Apple TrackPad 2. I leave it on continuously and it connects automatically when I startup or reboot. I use my Sony xm4s with it as well without issue, but typically only for 1-2 hours at a time.
I don't use the internal WiFi though (it works I just turn it off). I used to have a PCIE wifi card (don't remember the brand) and I alway experienced drops between WiFi and Bluetooth as you've described. Looking into it I was told that it's b/c they both use the 2.4 GHz range. Some folks suggested connecting WiFi to 5GHz to avoid this. I never tried that, I just turned it off, as I prefer to use ethernet.
Anyways thought I'd share my experience as well. If your system is working, I wouldn't rush to change it. If you do be sure to take a backup of your EFI folder. Best of luck.

@JonMcL Monterey. BT has never been 100% reliable on my hackintosh, for any setup, and I think my general rule of thumb is not to connect more than 2 devices at a time. I notice issues when I have more than 2 devices connected.


chore(STONEO11Y-117): Update CONTRIBUTING guide

Updated  CONTRIBUTING.md with pipenv installation command.

LGTM

/lgtm


[SP-3055][PDI-14797] Get Filenames Step issue with VFS and WinSSHD

reverted because is not full fix

Checked locally. Revert looks OK.
Merging

Build Completed
:x: This pull request has errors. They will need to be addressed before it can be accepted. See below for more details. Some links are also available below for further assistance in addressing those issues.
Build Commands
ant -Dtestreports.dir=bin/reports/unit-test -f engine/build.xml clean-all resolve jacoco && ant -Dtestreports.dir=bin/reports/integration-test -f engine/build.xml jacoco-integration checkstyle publish-local

Cleanup Commands
rm -r ~/.ivy2/local || echo no publish local to remove

Changed files
  engine/src/org/pentaho/di/trans/steps/getfilenames/GetFileNames.java

Unit test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.core.auth.core.impl.DefaultAuthenticationConsumerFactory

Branch Change:  + 7.14%
Complexity Change:  + 7.69%

org.pentaho.di.job.entries.sql.JobEntrySQL

Instruction Change: -1.64%:small_red_triangle_down:
Line Change: -1.97%:small_red_triangle_down:

org.pentaho.di.repository.kdr.KettleDatabaseRepositoryCreationHelper

Branch Change:  + 1.64%
Complexity Change:  + .69%
Instruction Change:  + 2.43%
Line Change:  + 2.95%

org.pentaho.di.trans.step.StepMeta

Instruction Change: -.19%:small_red_triangle_down:
Line Change: -.27%:small_red_triangle_down:

org.pentaho.di.trans.steps.sortedmerge.SortedMergeMeta

Instruction Change:  + .18%

org.pentaho.di.trans.steps.symmetriccrypto.symmetriccryptotrans.SymmetricCryptoTransMeta

Branch Change:  + 3.33%
Complexity Change:  + 1.85%
Instruction Change:  + .28%

org.pentaho.di.trans.steps.textfileinput.TextFileInputMeta

Branch Change: -.53%:small_red_triangle_down:

Integration test coverage change
These statistics help you identify how your changes have affected the coverage of the following files. If a file is not in this list, then its coverage was not affected by your changes. To get some help interpreting these metrics, please refer to Jacoco's documentation.
org.pentaho.di.trans.step.BaseStep

Branch Change:  + .30%
Complexity Change:  + .18%
Instruction Change:  + .13%
Line Change:  + .08%

License header violations

:heavy_exclamation_mark: Copyright year is not the current year on engine/src/org/pentaho/di/trans/steps/getfilenames/GetFileNames.java. Found 2013. Was expecting 2016

Checkstyle violations
The code submitted is not complying with one or more of our guidelines. To perform these checks locally, please use this tool.
/home/buildguy/project/engine/src/org/pentaho/di/trans/steps/getfilenames/GetFileNames.java

:heavy_exclamation_mark: '{' at column 9 should be on the previous line. at Line: 258 Column: 9


Any plans to support .NET Standard 2.1 (and ASP.Net Core 3.1)?

I am porting a .NET Core web application from ASP.NET Core 2.2 to 3.1, and discovered that the WebApi.Hal library does not appear to support .NET Core 3.1, at least not yet.
This is in part because Microsoft has dropped their dependency on Newtonsoft.Json in favor of their own System.Text.Json library.
Are there plans to support .NET Standard 2.1 in the near future?

This was news to me, thanks for pointing it out. I've battled the pinned dependency on Newtonsoft.Json with .net functions, so this is welcome news. "We", as in the loosely organized maintainers in our part time support of the project have had no plans here. Pull requests are very welcome with the caveat that we will need to support netstandard 2 also (I think) so may need more build targets.

Hi, past the holydays i was a bit bored, so i allready migrated WebApi.Hal to Core31.
The current version is not working with 31 because they changed some Formatter APIs.
This was the easy part (as far as i can trust the unittests)
Then in started to migrate to system.text.json and this is a very heavy task.
system.text.json isnt supporting the serialization attributes, it ignores inherited attributes and at last in only serializes properties of the type thats supplied.
At first i would avoid the migration to system.text.json.
is there a chance, that i could provide you my 3.1 migration?
Regards Johannes

we have found when the startup.cs class seperated and moved from hosting project this issue get resolved.

Hello, what's the current status? When do you plan to support core 3.1?

We'll review this, hopefully tonight. Thanks so much for the effort!

I have tested code from branch 3.1 and it doest work as expected. It does serialize _link no matter if it's application/json or application/hal+json

Reading through the details of the error running under dotnet core 3.1, ugh! I will ran a branch with the sample project updated to 3.1 and see what ideas I can come up with. Open to any ideas that still include supporting .net framework users.

TLDR; I think its a good idea to merge the PR to support .net core 3.1.
We'd accept the PR into a new version 4 that will temporarily drop .net framework users and only support .net core 3.1. .net framework users 4.8 and below and .net core users < 3.1 can continue to use the 3.1 version, and there is no new functionality anyway. The IsMultiLink PR I would accept into this 4.0 branch as it is also a potentially breaking change. Then when .net 5.0 comes out, we converge to a new version 5 that supports the current (then) netstandard2.1 and works in .net core and .net framework.
Other ideas in range of more to less desirable:

move the formatters to a separate projects, one for netstandard2.0 and one for .net core 3.1 and update docs to tell people how to wire these up. Would also need to find an alternative to the [JsonIgnore]. Seems like too much work, and worse usability for developers
rewrite the formatters from scratch instead of basing them on the existing and now removed formatters form asp.net mvc. I don't think anybody wants to take that on, and while better for developers, could easily introduce breaking changes in a project that has no new functionality and works against a spec that is also not changing.

Any update on this?

Since I've heard no other comments positive or negative, this is the way I'll go. Now when is the next question, in crunch time with my paid gig! Soon. But if the people that submitted their PR's want to update them, I'd be very ok with that too.

This has been updated and merged. A new release will be made and pushed to nuget once documentation has been updated

Just tried the latest and it still has some dependencies dependent on .Net Framework which is causing it to error.

Just upload version 4.0.1 to nuget. This is the .net core 3.1 version. Thanks for the reminder


Use strict is invalid in proxies js file

If you have two get methods (same name 'get'), one without a parameter and one with the 'use strict' condition fails when trying to call the proxy.
This is the sample shown working on your description page.
Thanks

Please can you provide a little more detail, I'm new to the project, so not sure what description page you are referring to?

Is it safe to propose just to remove use strict (for now)? #quickfix :smile:


Text after the comma disappears in TypedFormData.Body

Summary

SDK Version: 3.1.2
Expected behavior:
Actual behavior: text after the comma disappears

Code occuring the bug
@TypedRoute.Patch()
async update(@TypedFormData.Body() body: IUser): Promise<IUser> {
  return this.appService.update(body);
}

Project:
git clone https://github.com/itzRolf/nestia-bug-report.git
cd nestia-bug-report
pnpm run start:dev

Oops, I've used mis-implemented FormData parsing code of LLM generated.
Will fix it ASAP.

Upgrade to v3.1.3, then be fixed. Thanks for reporting.


✨ FR: Multiple projects in one

Use case, if you have a frontend and a backend project and the frontend one has the backend url/port as env var and the backend has an env var vor its port also both would need a teller file and the teller file needs to be in the project folder.
Instead, an option for having a central teller file for multiple possibly overlapping project that don't have to be checked in at all and can reside in the home directory would be nice.

Got it.
So to re-iterate, a single config file, that outline multiple projects.
Lets say we have a monorepo:
backend/
frontend/
some.json
other.json
teller.yml <--- this is a single config

And our yaml file will map:

projects:
  backend:
    [...]
  frontend:
   [...]

and somehow, let Teller via CLI pick which project you want.
Is that accurate?

yes pretty much, but maybe also that teller looks for a .tellery.yaml in the home folder also if it doesn't find one and the projects need to have some kind of path set to it

And do you foresee some settings/secrets that are common to both backend and frontend as well?

port settings for example. backend running on port and frontend accessing port of said backend


docker compose not working

I have the following setting in my docker-compose
  meilisearch:
    container_name: ${PROJECT_SUFFIX}_meilisearch
    image: getmeili/meilisearch:latest
    restart: always
    depends_on:
      - db
    volumes:
      - ./sql:/data.ms
    environment:
      MEILI_NO_ANALYTICS: 'true'
      MEILI_NO_SENTRY: 'true'
      MEILI_MASTER_KEY: null
      MEILI_ENV: 'development'
    ports:
      - target: 7700
        published: 7700
        protocol: tcp

on start will throw the following error :  Error: Meilisearch (v0.26.1) failed to infer the version of the database. Please consider using a dump to load your data.
I already cleaned up couple of times the shared Folder but the error persist.

Hello @deroccha
Have you updated the version of Meilisearch? The error message says you are trying to run Meilisearch with v0.26.1, but your documents have been added using an older version (like v0.25.0?).
Is it the case?

@curquiza after upgrade I deleted the mounted folder and even  docker fully resteddocker system prune -u

Hi @deroccha If I understand you correctly, you've upgraded to version 0.26.1 of Meilisearch and now you're getting the following error: Error: Meilisearch (v0.26.1) failed to infer the version of the database. Please consider using a dump to load your data.
Have you tried removing specifically your database folder (data.ms) and using this version to reindex your documents all over again?

Hi @curquiza I made a custom builded container and tagged that on build with the right platfom for M1 and now works. Previously I deleted all specific meilisearch data's but did not worked

@deroccha glad to read you found out an issue. I'm a little bit annoyed since we did not succeed to reproduce your issue on our side (on M1).
If you have the time, can you share with us how you build it?

Hey,
I'm also encountering the error:

Error: Function not implemented (os error 38)

while trying to build an arm64 docker image from getmeili/meilisearch:v0.26.1.
#9 [linux/arm64 1/3] FROM [docker.io/getmeili/meilisearch:v0.26.1@sha256:10f72ecdd219a54be8d3d17e231888047ec5bf1b38548f773880cbf8eaeb0f4a](http://docker.io/getmeili/meilisearch:v0.26.1@sha256:10f72ecdd219a54be8d3d17e231888047ec5bf1b38548f773880cbf8eaeb0f4a)
#9 extracting sha256:0857af6692e3c2c1b2d380b06b1a02b15a494c0b3300865af0300e4a6f0e2f90 0.2s done
#9 DONE 1.5s
#11 [linux/arm64 2/3] COPY [data.ms](http://data.ms/).snapshot /
#11 DONE 0.1s
#12 [linux/arm64 3/3] RUN ./meilisearch --no-analytics --ignore-snapshot-if-db-exists --import-snapshot data.ms.snapshot
#12 0.144 [2022-04-11T09:41:13Z INFO  meilisearch_lib::index_controller] Loading from snapshot "data.ms.snapshot"
#12 1.229 Error: Function not implemented (os error 38)

Hello @fritzfr
We have M1 internally and we did not succeed to reproduce your issue. Can you detail the commend you launched to have this problem?

Hey @curquiza
I believe everything works fine on M1, I have an M1 Macbook too. The issue I am describing is happening on a x86 machine, that is our Gitlab runner. It has a pipeline that is building a multi-arch docker image using docker buildx.
The Dockerfile looks like this:
FROM getmeili/meilisearch:v0.26.1
COPY data.ms.snapshot /
RUN ./meilisearch --no-analytics --ignore-snapshot-if-db-exists --import-snapshot data.ms.snapshot

and the Pipeline contains:
variables:
  CONTAINER_RELEASE_IMAGE: ${CI_REGISTRY_IMAGE}
  CONTAINER_TAG_RELEASE_IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_TAG}
  CONTAINER_PLATFORMS: linux/arm64,linux/amd64

    - docker run --rm --privileged multiarch/qemu-user-static --reset -p yes
    - docker buildx create --use
    - docker buildx build --platform $CONTAINER_PLATFORMS --push --tag $CONTAINER_RELEASE_IMAGE .

Thanks for the details 🙂
We are not CI experts, and docker experts either, but we succeeded to deploy CI creating cross-platform image for Meilisearch without any issue. We had this issue before providing a docker image for M1, but now we don't have any problem. Meaning you probably have an issue regarding your docker settings, but I cannot help you more...
Maye be you should take a look at our CI manifest to reproduce it into your own CI?

I close this issue due to a lack of answer, feel free to ask to reopen if needed

Hello @curquiza,
I am also encountering a similar issue:
➜  docker-env docker run -it --rm -p 7900:7700 -v meili_dump:/dumps -v meili_db_upd:/data.ms getmeili/meilisearch:latest meilisearch --import-dump /dumps/20220511-141824941.dump
[2022-05-11T14:19:59Z INFO  meilisearch_lib::index_controller::dump_actor] Loading dump from 2022-05-11 14:18:24.943074016 +00:00:00, dump database version: 0.26.1, dump version: V4
[2022-05-11T14:19:59Z INFO  meilisearch_lib::index_controller::dump_actor::loaders::v4] Loading dump from 2022-05-11 14:18:24.943074016 +00:00:00, dump database version: 0.26.1, dump version: V4
[2022-05-11T14:20:07Z INFO  meilisearch_lib::index_controller::dump_actor::loaders::v4] Loading indexes.
Error: Meilisearch (v0.27.0) failed to infer the version of the database. Please consider using a dump to load your data.

What I did prior:

Attach a meili_dump volume to my previous meili instance that was running getmeili/meilisearch:v0.26.1 (I am trying to upgrade to 0.27)
Create a dump (POST /dumps; which yielded 20220511-141824941.dump)
Start another container to import the dump (see above)

Hello @deroccha
If I'm correct this is related to https://github.com/meilisearch/meilisearch/issues/2389
Let's discussion in the open issue instead of here


Dynamic table for country distribution

See #25

There should be a way for the user to sort table by number of cases or continent, for example.  Check jQuery-ui library?

Found a lightweight option on stackoverflow jsfiddle for the code. Is there a functional table to implement this code on?

latest commit generates non reactive table on bead click  with country:case count, will make it smart tomorrow

Place table in a "details" collapsible box
add continent for sorting, maybe with color?
most recent date? (per country)

Refactoring this with d3

Refactoring complete in commit 37ffe8f906c6cd2d2580a3c7e1c60f2b5e2c51b8
but still need the following:

[ ] let user sort rows in table by clicking on header
[ ] alternate row coloring
[ ] improve overall look (padding, etc.)

Got sort working locally! Will clean up & push tomorrow

Intermittent issue:
Rows at bottom of table missing highlight on mouseover+ sorting functionality on table generation. However regenerating the table (i.e. clicking tip on tree again) activates these rows.

Todo (QoL):

[ ] add ascending/descending arrow for header
[ ] some type of visual feedback (maybe just arrow ok) when header selected


Implement mouse scrolling

This PR adds mouse scrolling, but currently this requires a beta version of the flutter engine as scrolling was implemented only very recently.
As this is a change from the flutter beta, this is still a WIP and might need more testing or be changed in the near future.

Hi, 999eagle, nice work. I'd suggest we move flutter beta dependent changes to development branch and merge into master when that is released. What do you think?

Yeah that might be useful. I'll change the target branch, but for now I'd like to implement a bit more mouse logic here before this is merged anyway :)

Merged


Baikal backend with Time Zones

Just wanted to share in case any others have the same issue I was having with Time zones and Baikal.  When I would set the time zone in environment variable, it would display in my calendar incorrectly. I had to remove the Time Zone variable from the config for everything to display correctly.  If the Time Zone variable was empty "" instead of non existent it wouldn't create the DSTART time correctly, it was missing the trailing Z at the end of the timestamp.
So either set a time zone or remove the variable and you should be good to go!

Thanks for the report. This should be fixed with a59454b.


Updated to v1.5.0

Kindly update the Docker images in the docker hub. Just updated the dockerfile and README to help you with it.

hi waldek, waiting for your review. So that you could release a latest image to DockerHub. I tested the build in  Docker mirror and it worked.

Dear Valdek,
You also need to understand the need of accepting when someone tries to help you with a pull request. I understand because of pride, you don't want to consider my pull request to be merged with yours.
If you can't accept other person to contribute, why did you even put it up in a public github repo?

@nithinmohantk sorry to hear you feel that way. I simply missed the PR and it was definitely not my intention not to accept it.
Please bear in mind, that it's not my full-time job to maintain GitHub repos. I have a job and family and this repo is not the only thing I'm doing. If you don't get my response in what you think is a timely matter, I'd suggest you try to reach out to me, rather than jumping to conclusions. Since there are other repos and projects I'm working on publicly, and for which I'm accepting and encouraging all kinds of help, you should know better than calling me out on my pride.


Underflow errors occur when using gp_minimize

I consistently get underflow errors when using this library, I've included the stack trace below. (Usually these percolate all the way down to _continuous_distns.py in the scipy library, but I've already patched the code in there and the problem persists.) I believe this should be resolved using sanitization to ensure that values are not smaller than np.exp(-35) or greater than np.exp(35). Based on my tests, these seem to be approximately the limits that numpy's float64 type can hold.
[....]skopt\optimizer\gp.py in gp_minimize(func, dimensions, base_estimator, n_calls, n_random_starts, acq_func, acq_optimizer, x0, y0, random_state, verbose, callback, n_points, n_restarts_optimizer, xi, kappa, noise, n_jobs)
    226         n_restarts_optimizer=n_restarts_optimizer,
    227         x0=x0, y0=y0, random_state=rng, verbose=verbose,
--> 228         callback=callback, n_jobs=n_jobs)

[....]skopt\optimizer\base.py in base_minimize(func, dimensions, base_estimator, n_calls, n_random_starts, acq_func, acq_optimizer, x0, y0, random_state, verbose, callback, n_points, n_restarts_optimizer, xi, kappa, n_jobs)
    252
    253         next_y = func(next_x)
--> 254         result = optimizer.tell(next_x, next_y)
    255         result.specs = specs
    256

[....]skopt\optimizer\optimizer.py in tell(self, x, y, fit)
    411                 y[1] = log(y[1])
    412
--> 413         return self._tell(x, y, fit=fit)
    414
    415     def _tell(self, x, y, fit=True):

[....]skopt\optimizer\optimizer.py in _tell(self, x, y, fit)
    470                     X=X, model=est, y_opt=np.min(self.yi),
    471                     acq_func=cand_acq_func,
--> 472                     acq_func_kwargs=self.acq_func_kwargs)
    473                 # Find the minimum of the acquisition function by randomly
    474                 # sampling points from the space

[....]skopt\acquisition.py in _gaussian_acquisition(X, model, y_opt, acq_func, return_grad, acq_func_kwargs)
     48     elif acq_func in ["EI", "PI", "EIps", "PIps"]:
     49         if acq_func in ["EI", "EIps"]:
---> 50             func_and_grad = gaussian_ei(X, model, y_opt, xi, return_grad)
     51         else:
     52             func_and_grad = gaussian_pi(X, model, y_opt, xi, return_grad)

[....]skopt\acquisition.py in gaussian_ei(X, model, y_opt, xi, return_grad)
    282     cdf = norm.cdf(scaled)
    283     pdf = norm.pdf(scaled)
--> 284     exploit = improve * cdf
    285     explore = std[mask] * pdf
    286     values[mask] = exploit + explore

FloatingPointError: underflow encountered in multiply

@BenEgeIzmirli thanks for reporting this! Could you share an example code where this happens? This would help to confirm where the issue is.

Hi @BenEgeIzmirli ,
I tried to reproduce your issue with the following code:
from skopt.space import Real
from skopt import gp_minimize

gp_minimize(
    lambda x: x[0] ** 2,
    [Real(1e+37, 1e+38)],
    n_calls=50,
    acq_func='EI',
)

gp_minimize(
    lambda x: x[0] ** 2,
    [Real(1e-38, 1e-37)],
    n_calls=50,
    acq_func='EI',
)

However, I do not observe an exception like in your case.
If the error still happens in your case or if you think my example could be improved to actually cause the exception, let me know.  I close this issue for now.

@iaroslav-ai check if these instructions help: https://github.com/scikit-optimize/scikit-optimize/issues/918#issuecomment-1051325603


Autoroom on roborock s5

This pull request adds an automatic retrieval of roomIDs via an inactive timer for room cleaning set up. It was suggested in issue #149. Instructions on how to set the config file and how to set the timer are in the README.md
The PR introduces a new member variable saving the room mapping. This is since the HomeKit services need to be created before the robot can be queried for room ids. This way it is possible to change the after service creation as soon as it is known.

@afharo You are the man!
You're doing a really great job here. I would be happy if you continued to manage this plugin. Make changes, edit issues and merge pull reqeuests. I'm out. I sign me out of all notifications for this plugin. You are also registered as a collaborator with miio and also with both NPM packages.
Good luck und thanks.


Exit-code

Fixes https://github.com/Tufin/oasdiff/issues/74

Codecov Report

Merging #75 (529de98) into main (1d529c3) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main      #75   +/-   ##
=======================================
  Coverage   92.08%   92.08%
=======================================
  Files          68       68
  Lines        3489     3489
=======================================
  Hits         3213     3213
  Misses        195      195
  Partials       81       81

Flag
Coverage Δ

unittests
92.08% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

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 1d529c3...529de98. Read the comment docs.


Result query set expired error occurs in Hue with k8s

Bug
I currently use hue application on kubernetes cluster.
I connect to hive session using beeswax.
beesawx attribute values are as follows.
[beeswax]
  hive_server_host=< hiveserver host >
  hive_server_port=10000
  hive_conf_dir=< hive conf directory >
  server_conn_timeout=12000
  download_row_limit=10000000
  download_cell_limit=10000000
  download_bytes_limit=350000000
  close_queries=true
  max_number_of_sessions=300

When i executed hive query, the following screen is repeated, and the result is that the query result is unsuccessful.
Picture

network status is like below. It seems to keep checking the status.
I wonder if it has something to do with readinessProbe.

Have you ever experienced a similar situation?
Thanks.
Hue Version
Opensource 4.9.0

Are you connections to HS2 sticky? Same for you users if using multiple Hue
https://docs.gethue.com/administrator/administration/reference/#impala-and-hive-ha

Yes. I use HS2 sticky.
Is it a sticky session issue? I wonder if it's a load balancing problem, so even if I change to a single host, the same error occurs.

https://gethue.com/how-to-optimally-configure-your-analytic-database-for-high-availability-with-hue-and-other-sql-clients/
I've been testing separating property values for hue according to the documentation.

It works!
As shown in the figure, I separated the haproxy port and configured it, and it worked properly.
One thing to note is that the following error occurred,
TSocket read 0 bytes (code THRIFTTRANSPORT): TTransportException('TSocket read 0 bytes',)

It was an error that occurred because the SSL setting was added to the server while setting the new port.
If this error occurs, you may check the following.

Check if SSL settings are applied to the server.
Make sure SSL is turned off in hue hiveserver or Impala beeswax settings.
If set, check if the SSL key file is set properly.

I have all the SSL settings turned off in Hue I run.


Delete default firewall rules

Hi,
I'm trying to delete the default firewall rules by "default" network.
If I try the following code on a new project:
resources:
- name: default-allow-rdp-delete
  action: gcp-types/compute-beta:compute.firewalls.delete
  properties:
    firewall: default-allow-rdp
  metadata:
    runtimePolicy:
    - CREATE

I've the error:
$ gcloud deployment-manager deployments create resources --project "$DMPROJECT" --config resources.yaml
The fingerprint of the deployment is oDv7WHIA0lxF3zD2ag7WtA==
Waiting for create [operation-1518687221117-5653cec56f04c-e57265ab-09aff176]...failed.
ERROR: (gcloud.deployment-manager.deployments.create) Error in Operation [operation-1518687221117-5653cec56f04c-e57265ab-09aff176]: errors:
- code: RESOURCE_ERROR
  location: /deployments/resources/resources/default-allow-rdp-delete
  message: "{\"ResourceType\":\"gcp-types/compute-beta:compute.firewalls.delete\"\
    ,\"ResourceErrorCode\":\"404\",\"ResourceErrorMessage\":{\"code\":404,\"errors\"\
    :[{\"domain\":\"global\",\"message\":\"The resource 'projects/<projectID>/global/firewalls/default-allow-rdp'\
    \ was not found\",\"reason\":\"notFound\"}],\"message\":\"The resource 'projects/<projectID>/global/firewalls/default-allow-rdp'\
    \ was not found\",\"statusMessage\":\"Not Found\",\"requestPath\":\"https://www.googleapis.com/compute/beta/projects/<projectID>/global/firewalls/default-allow-rdp\"\
    ,\"httpMethod\":\"GET\"}}"

And from logs it seems that the action is executed twice (9 seconds between them) by DM.
Is a bug?
Thanks

You need to set the field project to the action
project: {{ env["project"] }}

Hi @aljim ,
I've recreated manually the firewall rule and added the field project:
resources:
- name: default-allow-rdp-delete
  action: gcp-types/compute-beta:compute.firewalls.delete
  properties:
    firewall: default-allow-rdp
    project: {{ env["project"] }}
  metadata:
    runtimePolicy:
    - CREATE

but the result is the same:
$ gcloud deployment-manager deployments create resources --project "$DMPROJECT" --config resources.yaml
The fingerprint of the deployment is _YT3gm46P07otSkZwhG9Uw==
Waiting for create [operation-1519027018942-5658c09de4630-1dfc66bd-3c422754]...failed.
ERROR: (gcloud.deployment-manager.deployments.create) Error in Operation [operation-1519027018942-5658c09de4630-1dfc66bd-3c422754]: errors:
- code: RESOURCE_ERROR
  location: /deployments/resources/resources/default-allow-rdp-delete
  message: "{\"ResourceType\":\"gcp-types/compute-beta:compute.firewalls.delete\"\
    ,\"ResourceErrorCode\":\"404\",\"ResourceErrorMessage\":{\"code\":404,\"errors\"\
    :[{\"domain\":\"global\",\"message\":\"The resource 'projects/<projectID>/global/firewalls/default-allow-rdp'\
    \ was not found\",\"reason\":\"notFound\"}],\"message\":\"The resource 'projects/<projectID>/global/firewalls/default-allow-rdp'\
    \ was not found\",\"statusMessage\":\"Not Found\",\"requestPath\":\"https://www.googleapis.com/compute/beta/projects/<projectID>/global/firewalls/default-allow-rdp\"\
    ,\"httpMethod\":\"GET\"}}"

I can't understand the double execution in logs of the action.
Thanks

Hi @davidebelloni, in which log did you see double execution of the action? can you share the log?

Hi, here are the logs:
---
insertId: 1io2rkufrq1l0w
jsonPayload:
  actor:
    user<EMAIL_ADDRESS>  event_subtype: compute.firewalls.delete
  event_timestamp_us: '1519201021586900'
  event_type: GCE_OPERATION_DONE
  operation:
    global: true
    id: '1117529425821340699'
    name: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
    type: operation
  resource:
    global: true
    id: '8301844294128407597'
    name: default-allow-rdp
    type: firewall
  trace_id: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
  version: '1.2'
labels:
  compute.googleapis.com/resource_id: '8301844294128407597'
  compute.googleapis.com/resource_name: default-allow-rdp
  compute.googleapis.com/resource_type: firewall
logName: projects/[projectId]/logs/compute.googleapis.com%2Factivity_log
receiveTimestamp: '2018-02-21T08:17:01.700464641Z'
resource:
  labels:
    firewall_rule_id: '8301844294128407597'
    project_id: [projectId]
  type: gce_firewall_rule
severity: INFO
timestamp: '2018-02-21T08:17:01.586900Z'
---
insertId: -cr9nwge1gpai
logName: projects/[projectId]/logs/cloudaudit.googleapis.com%2Factivity
operation:
  id: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
  last: true
  producer: compute.googleapis.com
protoPayload:
  '@type': type.googleapis.com/google.cloud.audit.AuditLog
  authenticationInfo:
    principalEmail<EMAIL_ADDRESS>  methodName: beta.compute.firewalls.delete
  requestMetadata:
    callerIp: <IP_ADDRESS>
    callerSuppliedUserAgent: GoogleCloudDeploymentManager Google-API-Java-Client Google-HTTP-Java-Client/1.23.0-SNAPSHOT
      (gzip)
  resourceName: projects/[projectId]/global/firewalls/default-allow-rdp
  serviceName: compute.googleapis.com
receiveTimestamp: '2018-02-21T08:17:02.445878901Z'
resource:
  labels:
    firewall_rule_id: '8301844294128407597'
    project_id: [projectId]
  type: gce_firewall_rule
severity: NOTICE
timestamp: '2018-02-21T08:17:01.519Z'
---
insertId: v2r8crfsju1mt
jsonPayload:
  actor:
    user<EMAIL_ADDRESS>  event_subtype: compute.firewalls.delete
  event_timestamp_us: '1519201012439233'
  event_type: GCE_API_CALL
  ip_address: ''
  operation:
    global: true
    id: '1117529425821340699'
    name: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
    type: operation
  request:
    body: 'null'
    url: https://www.googleapis.com/compute/beta/projects/[projectId]/global/firewalls/default-allow-rdp
  resource:
    global: true
    id: '8301844294128407597'
    name: default-allow-rdp
    type: firewall
  trace_id: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
  user_agent: GoogleCloudDeploymentManager Google-API-Java-Client Google-HTTP-Java-Client/1.23.0-SNAPSHOT
    (gzip)
  version: '1.2'
labels:
  compute.googleapis.com/resource_id: '8301844294128407597'
  compute.googleapis.com/resource_name: default-allow-rdp
  compute.googleapis.com/resource_type: firewall
logName: projects/[projectId]/logs/compute.googleapis.com%2Factivity_log
receiveTimestamp: '2018-02-21T08:16:52.541456472Z'
resource:
  labels:
    firewall_rule_id: '8301844294128407597'
    project_id: [projectId]
  type: gce_firewall_rule
severity: INFO
timestamp: '2018-02-21T08:16:52.439233Z'
---
insertId: -cha6pod9j4e
logName: projects/[projectId]/logs/cloudaudit.googleapis.com%2Factivity
operation:
  first: true
  id: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
  producer: compute.googleapis.com
protoPayload:
  '@type': type.googleapis.com/google.cloud.audit.AuditLog
  authenticationInfo:
    principalEmail<EMAIL_ADDRESS>  authorizationInfo:
  - granted: true
    permission: compute.firewalls.delete
  methodName: beta.compute.firewalls.delete
  requestMetadata:
    callerIp: <IP_ADDRESS>
    callerSuppliedUserAgent: GoogleCloudDeploymentManager Google-API-Java-Client Google-HTTP-Java-Client/1.23.0-SNAPSHOT
      (gzip)
  resourceName: projects/[projectId]/global/firewalls/default-allow-rdp
  response:
    '@type': compute.googleapis.com/operation
    id: '1117529425821340699'
    insertTime: '2018-02-21T00:16:52.199-08:00'
    name: operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
    operationType: delete
    progress: '0'
    selfLink: https://www.googleapis.com/compute/beta/projects/[projectId]/global/operations/operation-1519201011784-565b48ca65942-7e5f6d7b-07eece93
    status: PENDING
    targetId: '8301844294128407597'
    targetLink: https://www.googleapis.com/compute/beta/projects/[projectId]/global/firewalls/default-allow-rdp
    user<EMAIL_ADDRESS>  serviceName: compute.googleapis.com
receiveTimestamp: '2018-02-21T08:16:53.209693102Z'
resource:
  labels:
    firewall_rule_id: '8301844294128407597'
    project_id: [projectId]
  type: gce_firewall_rule
severity: NOTICE
timestamp: '2018-02-21T08:16:51.863Z'

I can not understand if they reference the same operation, but the issue from DM remain!
Thanks

@davidebelloni the issue is when polling the operation for completion, DM tries to get the actual value of the resource but the resource is deleted by then. This is a bug in DM and we have an internal bug to track the fix (ETA next 2 weeks). Currently for any action which deletes a resource, you have to set the "runtimePolicy" to DELETE to make it work properly.

Hi @shuainie-google ,
the issue remain also with "runtimePolicy" set to DELETE.
Is there an ETA also for runtimePolicy and action DM documentation?
Thanks

Hi @davidebelloni here is the config I'm using which is working:
resources:
- name: default-allow-rdp-delete
  action: gcp-types/compute-v1:compute.firewalls.delete
  properties:
    firewall: default-allow-rdp
    project: shuainie-project0
  metadata:
    runtimePolicy:
    - DELETE

This will only delete the firewall when you delete the deployment.
Unfortunately we don't have a ETA for the action feature documentation since the release is currently blocked internally.

Hi @shuainie-google ,
what I want is to delete a firewall rule from default network when I create (or update) the deployment, not in deletion!
Is there a workaround for the behaviour above?

@davidebelloni, unfortunately we don't have a workaround for this now. A fix is in progress and the ETA in 2 weeks.

@davidebelloni, the fix is released and I have validated the scenario. Closing this now.


Explore Merging Aync and IO into a unified construct

Summary from larger conversation on discord:
I may be confusing that there is a different pending effect for Async as with IO. In other effect systems and by (at least my) intuition usually IO is considered the "biggest" effect type (as in capable of doing the most things). With Async and IO split you can get significantly different effect types depending on which actions are called.
Motivating example:
for {
 result: Int <- IO{...}
 _ <- Async.sleep(10.second)
 _ <- Console.println("Done sleeping")
} yield (result)

The addition of a sleep changes the type from IO -> Sync, which changes the signature from Int < IO -> Int < Async. This is a pretty minor change in code bases where you control the signature, but may be difficult to satisfy in instances where the modification is not within the users control.
Copying some background reasoning from @fwbrasil in the discord thread

... I like the more fine-grained effect tracking because it makes it easier to reason about the properties of some code. A good example is the distinction in Kyo between Queue and Channel. While the other effect systems bundle both in the same primitive, Kyo separates them so Queue can depend only on IO as a regular concurrent queue and Channel introduces Async to be able to park fibers if necessary. If I see a method with only IO, I wouldn't expect the execution to be able to park, which is a good guarantee if performance is a concern. That said, I think that's something the majority of users don't want to worry about that and the tendency is for the boundary between IO and Async to become more unclear due to Loom. ...

Alternative solutions:
If it's determined that this split between Async and IO must continue and the concepts must be distinct - and alternative path is to rename the current values. Exact naming may change but it may be better to rename Async -> IO and rename the current IO -> Sync (or something else). I believe this keeps in line with "IO" being the biggest type while also preserving the reasoning for splitting the original types. Additionally - this might be me - I've always associated Async with being under the umbrella of IO

Thank you for the details @Luka-J9! There's also this relevant comment by @steinybot in #contributors:

Jason Pickens — 09/26/2024 3:00 PM
When this came up my gut feeling was to keep them separate. I think it is important to know what is synchronous and asynchronous. This is especially true in Scala.js. With React you need to know when your state updates are going to happen. E.g. If you have a button onClick handler which updates two bits of state and one update is synchronous and the other is asynchronous but you don't know then you will likely render an inconsistent state.
I don't think merging them even solves the issue Luka had of deciding whether to define an interface in terms of IO or Async. You can extend that example to any number of effects such as whether to include Abort or not. Isn't the real solution to this problem to define your traits to take the effect as a parameter? Then the implementation can choose the effect. Dare I say it but something akin to tagless final although I think this is way better with Kyo.

I was sympathetic to merging Async into IO but I'm not sure anymore. Even after the cleaning up of IO.run calls in https://github.com/getkyo/kyo/pull/702, having to handle async even for code that only performs side effects seems an important limitation of Kyo's capabilities. For example, we can now call IO.run(value: A < IO) and get an A directly. If we merge the effects, we'd need to return a Fiber[Nothing, A] but its methods will introduce IO suspensions again when used. @steinybot also makes a good point that, although Loom might blur the distinction between IO and Async, that's likely not the case for other platforms like JS.

Dare I say it but something akin to tagless final although I think this is way better with Kyo.

Yeah, parametrizing effects is simpler in Kyo. I'd reserve this kind of pattern for libraries and advanced users, though. I think a major trap I see with people using tagless final is over abstraction. If using Async in an API serves the user's need, adding a type parameter to be able to use the API with only IO as well doesn't have much benefit and can scare newcomers away.

Exact naming may change but it may be better to rename Async -> IO and rename the current IO -> Sync (or something else). I believe this keeps in line with "IO" being the biggest type while also preserving the reasoning for splitting the original types. Additionally - this might be me - I've always associated Async with being under the umbrella of IO

That should be the case for most of the people adopting Kyo initially since many will have experience with other effect systems. That's a product of the low composability of other effect systems, though. They have to bundle async in the same monad that suspends side effects because that's the only option. I don't like the renaming from IO to Sync since it obscures its meaning but I wonder if there are other names that might work well.

Said another way Int < (IO & Abort) can exist, but Int < (IO & Async) would not (unless I'm mistaken).

I think your intuition is in the right direction. Async is currently encoded as:
opaque type Async <: (IO & Async.Join) = Async.Join & IO

It's possible to have Int < (IO & Async) but IO is redundant because it's already included in Async. I'd say that's more a property of the current encoding than a fundamental aspect, though.

I think having the name still contain IO might make it more clear e.g. SyncIO instead of IO and Async -> IO

Thanks for giving it some more thought :) I like Async => IO and  IO => SyncIO. I think people will naturally end up selecting IO, which is probably what is best for most users. If the more fine-grained effect tracking is necessary for example to ensure a computation has no async operations, which can be beneficial in JS, or because the user sees value in the distinction, then they can decide to use SyncIO.

I could be totally wrong but I think the reason Async includes IO is more for convenience.

Exactly! 🎯 We could, for example, suspend all async operations in a custom effect and then introduce IO suspensions only when Async.run is called.

When you run an Async you get an IO so there is no way to escape it (although now I'm starting to wonder why this is, I would have expected the same thing to be true of Var but it is not)

That's because Var is 100% based on pure function composition! There's no mutability in its implementation other than the kernel's safepoint mechanism for stack safety and tracing. The execution of the Var operations is based only on pure functions.

Let me try to phrase it in a different way. I think we have three main concerns:

Users coming from other effect systems expect IO in include Async capabilities. That's a product of effect composability limitations that aren't present in Kyo but seems a problem for adoption.
More advanced users like library authors can leverage the distinction between IO and Async and merging the effects would be an important limitation of Kyo's capabilities as @steinybot elaborated.
The majority of users will write code where the distinction between IO and Async doesn't matter. If you're building a backend system and calling a few services to perform a few transformations, using Async directly shouldn't introduce any limitation.

It seems we're aligned regarding the need to cater to all these audiences. We don't want to merge the effects since that'd be an important limitation for advanced users but we can mitigate the implications for the other audiences. A naming change like @Luka-J9 suggested paired with documentation suggesting the equivalent of Async in the new naming as the recommended effect users rely on seems a good path for that.
I must be honest that naming isn't my forte so please feel free to suggest naming schemes! Suggestions I could identify in our discussions:

Rename Async to IO to satisfy the expectation of users coming from other effect systems and IO to SyncIO
Keep Async and rename IO to something else other than Sync.

Consider whether Async should still include IO. I suspect yes but maybe the documentation should show it the verbose way without aliases.

Reducing the tracking overhead is a major challenge for usability. We need to find a good balance that works well for the different potential users of the library. It seems the majority of the users wouldn't benefit from the additional tracking if we don't include IO in Async and the inclusion doesn't seem to introduce limitations.

Speaking strictly from the user perspective of Kyo, IO is only confusing due to the misuse of it's name by other effect systems. When I was first reading the new core, it took me a minute to understand that: A < IO is equivalent to A < Any with a specific Tag. For this reason, we should aim to clearly communicate 'what' IO is doing, which is suspending the computation.
I much prefer Defer as it can be used to represent 'pure' suspensions as well (not that IO couldn't be). My only issue is now we have a longer signatures for the same functions.

A < Defer
A < Async

Perhaps users can also make an alias if they so choose...

A < IO is equivalent to A < Any with a specific Tag.

To be more precise, A < IO is actually A < (IO & Any) but the Any can be omitted.
I think it's confusing because of the mental model of how other effect systems work. A computation of type A < Any essentially means a computation without effect suspensions (besides the kernel's internal mechanisms, more details below). It can't perform any side effects since it would require IO suspensions and thus a pending IO effect. It's something other effect systems can't represent in their base monad and why they need separate monads like ZPure.
This approach enables kyo-prelude to offer a relatively complete set of effects without any side effects, which is a remarkable property given that it's possible to express fully deterministic computations with advanced effects like Var, Batch, Abort, and Choice based only on pure function composition. In theory, such computations could even be compiled to a physical chip.
I agree this distinction doesn't matter for most users but, although we try to keep a down-to-earth approach to usability, ensuring Kyo is able to represent a wide range of computations with fundamental properties like this one can yield interesting results in the long term. For most users, I'm hoping our recommendation of Async as the effect people typically select can mitigate usability issues. We should also be careful not to design too much around the expectations of users coming from other effect systems since we should have a more diverse user base over time.

Huh I did not catch onto that either although I haven't fully groked the kernel stuff yet. So does that mean that it is eval that is actually running the suspended computations not IO.run?

Yes, the kernel also introduces internal suspensions to ensure stack safety. The internal effect used for that is called Defer, we'll need to rename it. When eval is called, the computation can only not be an A in case an internal suspension was required to unwind the stack. Calling eval should never execute side effects since it's not possible to call eval on a computation with a pending effect like IO.

This is a great point that I agree with completely. I like Defer. Far better to have a slightly longer name with a more accurate meaning IMO. As has been mentioned, people are going to generally end up using Async or a custom alias anyway.

I agree with the rename to Defer, especially in this initial phase where it can be confusing to people coming from other effect systems, but I'd argue it's less descriptive. People associate suspension with side effects but in Kyo's case, suspensions are the basis of all functionality, not only side effect management. IO properly expresses that the computation interacts with the "external world". The issue is the baggage of the "IO monad".

Any concerns regarding proceeding with the renaming from IO to Defer? I think we can rename the current internal Defer in the kernel as Unwind since it's meant to unwind the stack.

For what my opinion is worth, I think the most user friendly and recognizable naming would be IOSync and IO. IO has been since long recognized as synonym for side effects -- we can use this established terminology for our advantage.

IOSync is a special kind of, more constrained side effect and the name even suggests it's constrained in it being merely "synchronous"
IO just the most generic and all encompassing and all powerful side effect, subsumes anything, because anything can happen


Add filter for new parties only

With the blue dots :large_blue_circle:
:smile:

You can easily scan it, why do you need filters :)?

Lazy? haha

It's open source, you're welcome to help.

Yeah for sure.. I think I could get started but without all the keys, may need your help to finish..


Roll Flutter Engine from 1da070c57c87 to db3d28d47559 (2 revisions)

https://github.com/flutter/engine/compare/1da070c57c87...db3d28d47559
2023-03-24<EMAIL_ADDRESS>[impeller] runtime effect doesnt accept opacity (flutter/engine#40579)
2023-03-24<EMAIL_ADDRESS>Roll Skia from 32ffab0c9432 to 86228d7534de (7 revisions) (flutter/engine#40586)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-engine-flutter-autoroll
Please CC bdero@google.com,rmistry<EMAIL_ADDRESS>on the revert to ensure that a human
is aware of the problem.
To file a bug in Flutter: https://github.com/flutter/flutter/issues/new/choose
To report a problem with the AutoRoller itself, please file a bug:
https://bugs.chromium.org/p/skia/issues/entry?template=Autoroller+Bug
Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md

Commit queue failed; closing this roll.


Fix multi-robot demo (partially)

I was not able to push directly to https://github.com/ros-controls/ros2_control_demos/pull/187, because the setting Allow edits and access to secrets by maintainers is not set.
Make the example work with rolling until the last step

new spawner syntax
new controller-manager syntax
add list_hardware_components output
apply feedback from the original PR

Something is still not working properly with the cleanup in the last step. The service controller_manager_msgs/srv/CleanupHardwareComponent is not available (I cannot find it in the history, was it ever?). I tried to bring it into finalized state
ros2 service call /controller_manager/set_hardware_component_state controller_manager_msgs/srv/SetHardwareComponentState "
name: RRBotSystemPositionOnly
target_state:
 id: 0
 label: finalized"

but get the following error now, and joint_state_broadcaster can't be activated again.
[ros2_control_node-1] [WARN] [1691260478.510570255] [resource_manager]: (hardware 'RRBotSystemPositionOnly'): 'rrbot_joint1/position' command interface not in available list. This should not happen (hint: multiple cleanup calls).
[ros2_control_node-1] [WARN] [1691260478.510572441] [resource_manager]: (hardware 'RRBotSystemPositionOnly'): 'rrbot_joint2/position' command interface not in available list. This should not happen (hint: multiple cleanup calls).
[ros2_control_node-1] [WARN] [1691260478.510574080] [resource_manager]: (hardware 'RRBotSystemPositionOnly'): 'rrbot_joint1/position' state interface not in available list. This should not happen (hint: multiple cleanup calls).
[ros2_control_node-1] [WARN] [1691260478.510575651] [resource_manager]: (hardware 'RRBotSystemPositionOnly'): 'rrbot_joint2/position' state interface not in available list. This should not happen (hint: multiple cleanup calls).

I was not able to push directly to ros-controls#187, because the setting Allow edits and access to secrets by maintainers is not set.

This is usually the issue with organizations - it doesn't work with organizations.

Something is still not working properly with the cleanup in the last step. The service controller_manager_msgs/srv/CleanupHardwareComponent is not available (I cannot find it in the history, was it ever?). I tried to bring it into finalized state

I had this on a working branch (at least), but we decided to remove those services and use "SetHardwareState" as general service.

but get the following error now, and joint_state_broadcaster can't be activated again.

This error is known to me, I dug already in, but it was not trivial to solve and not easy to fix. Regarding reactivation of the JSB, what's the error there? I am not sure if we did clean implementation of the reactivation. It could be that we are not cleaning something properly.

I realized now that all four joint_state_publisher publish on /joint_states. Is this the intention? I guess not because after configuring the FakeThreeDofBot rviz already shows a still-standing robot and it is not broken any more as written in the readme.

but get the following error now, and joint_state_broadcaster can't be activated again.

This error is known to me, I dug already in, but it was not trivial to solve and not easy to fix. Regarding reactivation of the JSB, what's the error there? I am not sure if we did clean implementation of the reactivation. It could be that we are not cleaning something properly.

There is no error message from ros2_control_node, it just does not activate it. I thought that not being able to reactivate JSB is a consequence of the other error.

Closing in favor of https://github.com/ros-controls/ros2_control_demos/pull/417


SliverAppBar as a drop-in AppBar replacement

The usage for the current implementation of SliverAppBar is unclear.  There are two different ways of populating a material appbar:
new Scaffold(
  // 1
  appBar: new AppBar(),
  body: new CustomScrollView(
        slivers: [
          // 2
          new SliverAppBar(
            title: new Text('ScrollViewContents'),
            floating: true,
          ),
          new SliverList(
            delegate: myItems0.sliverChildListDelegate(),
          ),
        ],
    ),
  );

In client code, having two different ways of doing this makes code

much more difficult to maintain (bugs may happen in one page but not another b)
much harder to change between appbar models (switching requires migrating between the scrolling models instead of dropping in a different implementation)

In leafy, this dual interface issue and the associated code complexity is a blocker to us adding scrollable appbar behavior.

Would it feel more natural if SliverAppBar was defined as an appbar container, so you'd use it like:
new SliverAppBar(appBar: new AppBar(...)) ?

Our concern isn't so much whether the approach is natural as there simply being two different ways of doing the same thing with no simple path between the two approaches.
From a developer usability standpoint, we tend to build Scaffolds like so:
new Scaffold(
  appBar: new AppBar(app title content),
  body: new PageContent(),
);

class PageContent extends StatelessWidget{
  build(context) {
    return new SingleChildScrollView(viewcontents)
  }
}

This separates the concerns for our page from our page's contents.
However, the difference in API for Slivers introduces a catch-22:
If we try to port some of our pages to Sliver APIs without changing the page content widgets, then the change would lead to doubly-nested scrollviews, which are harder to reason about and could introduce bugs.
If we try to port and do redesign our page contents to be compatible with slivers, then we now have pages that only work in slivers and pages that only work under regular appbars.

@Hixie

They're not the same thing at all -- in one case, you have a static toolbar with no relationship to the list, and in the other case you have an active participant in scrolling, which can be affected by the scroll offset, etc. (This will become much clearer once we remove the last few reasons why the "appBar" slot has to take an AppBar rather than any arbitrary widget.)

I recognize that the dependencies that are necessary for the types of appbar are very different.
Our concern has to do with how to provide the dependencies instead of what dependencies need to be provided.  The current implementation goes against the structure of the Scaffold interface.  We'd like an implementation that works with the existing Scaffold architecture instead of against it.

Suppose I were to write a 2-step tutorial on building an app to show the complete script for Romeo and Juliet with Flutter.
Part 1 would look something like this:

The great part about Flutter is that once you have your development tools set up, all you need to remember to put your app together is new Scaffold().  The Dart analyzer is smart enough to help you fill in the rest:
return new Scaffold(
  appBar: new AppBar(title: new Text('Romeo and Juliet'),
  floatingActionButton: new MyAppFab(),
  drawer: new MyAppDrawer(),
  body: new RomeoAndJulietScript(),
);

Going on from here, we can fill in each of these widgets on their own to give the app the functionality it needs.
Note that the Scaffold takes care of all of the major behavior associated with Material design.  For example:

If you add the drawer field to your Scaffold, it will automatically add a hamburger menu icon to the left hand side of your appbar.
If you add pages to your app that have or do not have floating action buttons, the Scaffold will conveniently take care of transition animations to add or remove the FAB.

This example highlights the extreme simplicity and ease of use of the conventional Scaffold interface.  Each widget is modular, so a change to the FAB affects the FAB and only the FAB, while a change to the AppBar affects the AppBar and only the AppBar, and a change to the Body affects the Body and only the Body.  More importantly, the interface to each constructor guides a developer through all the steps to build their app.  The app practically writes itself.
The simple design and focused utility of this structure make Flutter very appealing to a first-time user, and the simplicity it affords was one of the essential motivating factors to convincing PMs and high-level stakeholders in leafy's organization that it was worth exploring as an alternative to native app development.
Part 2 of this tutorial would be a bit more complicated:

Now, let's give the user more screen space by collapsing the appbar when the user scrolls down.  While adding the drawer or the FAB to the app are steps that practically write themselves, making the appbar collapsible is more complicated.
To collapse the appbar, we need to go against the grain of the Scaffold interface, and remember a few more steps than we did to get started:

We will place our RomeoAndJulietScript widget inside of a CustomScrollView, and make the CustomScrollView the body of the app
We will remove the appBar field on the Scaffold
We will place a SliverAppBar inside the CustomScrollView with the script widget

There should no longer be a top-level appBar declaration.

Make sure you keep your SliverAppBar at the top of the scrollview list, or you could get strange effects with the appbar showing up at the bottom of the page.

Your code should now look something like this:
return new Scaffold(
  floatingActionButton: new MyAppFab(),
  drawer: new MyAppDrawer(),
  body: new CustomScrollView(children: [
    new SliverAppBar(...),
    new RomeoAndJulietScript(),
  ]),
);

In the resulting code, the structure is no longer modular like it was previously, where every widget was able to define the things it needs to build.  Now, the CustomScrollView is a dependency of the SliverAppBar, but the dependency is provided in the widget hierarchy instead of the parameters to the SliverAppBar.
As a consequence, the development tools no longer help the app write itself.  Instead, this pattern goes against the grain for how Scaffold is implemented.  The end-user of the framework now needs to understand how Flutter is implemented to know what to do.  They need to know that Scaffold asks for an AppBar but that dependency has to be ignored.  They also need to know that SliverAppBar must be hosted inside of a CustomScrollView and that it must be provided as the Scaffold's body.  This deviation from the established pattern sends the message that the collapsing appbar was not created as a first-class citizen in Flutter.
This contrasts with the workflow for adding tabs to an app.  The pattern of constructing TabBar, TabBarView, and TabBarController still makes all the dependencies that need to be provided clear, even though they depend on being built at different places in the widget tree to operate.  The excellent sample in the documentation works with the architecture of Flutter and the Scaffold instead of working against it.

I realize that preserving the existing implementation pattern is easier said than done, but the existing pattern is extremely simple and usable.  It differentiates Flutter from other frameworks and even native development for either Android or iOS.  From a product excellence and user adoption perspective, the framework's simplicity is a feature, and its value is on par with engineering feats like the fast graphics pipeline.
Because of the potential benefit to future usage and adoption, I believe it's worth investing time and effort here to iterate on the interface for SliverAppBar and make it more consistent with how we currently add other things to the Scaffold.

I hear what you're saying, but the trade-offs are significant. I don't see a sane path to having the app bar in the scaffold rather than in the list, given that we want it to physically be in the list. The scrolling refactor was in a large part directly intended to fix all the problems that having the app bar in the scaffold were causing.
I suppose we could have an inherited widget that publishes slivers to add to the top of whatever lists want them; . I'm not sure it would really be simpler. It would lead to weird things like the widgets not appearing because the developer didn't put in a list but still used the "scrollingAppBar", or the widgets appearing twice because they happened to have two lists, or whatnot.
I'm not really convinced that the new code is that much more complicated than the old code.

@DaveShuckerow thanks very much for the nice depiction of the problem. One additional issue with the current API is the use of different layout widgets (namely SliverGrid and SliverList) inside the body of the scaffold. Basically, this implementation detail (Sliver*) spreads to the rest of the app which becomes a problem when body content is to be reused in various scaffolds.
@Hixie, I hear you. This is a lot to ask and it does not seem like it provides a lot of benefit because of a lack of sane approach. Android native also has this problem. Only two of their scrollviews support collapsible app bars (recyclerview and nestedscrollview). If you use one of the other scrollviews, the collapsing action does not work.
The main issue for both Flutter and Android is the fact that collapsing toolbars is an afterthought.  So what if we turned the problem upside down?
 Would we be able to:

keep the scaffold API the same?
avoid special treatment of the body of the scaffold?
make all scroll widgets support this behavior by default (again so that you would not need apps to use special components in the body of the scaffold to make it work).

Imagine you did this. Would it then be easier to allow apps to disable the collapse action with a param?
I think this is the right way to think about it because in material design, it is expected that the toolbar collapses to allow more information to be displayed. It is part of the default appbar behavior (https://material.io/guidelines/patterns/scrolling-techniques.html#scrolling-techniques-behavior).
We are willing to wait for the right solution if we can agree on one. The absolute date where this needs to be resolved is end of this year. Please think about this a while and see if you can solve this problem with the 3 constraints laid above from app point of view. If no such thing exists, we will bite the bullet and come up with a pattern that allows us to develop reusable page body's while respecting the behavior dictated by scaffold for appbar.

The main issue for both Flutter and Android is the fact that collapsing toolbars is an afterthought

I assure you that's not the problem for Flutter, since the entire scrolling mechanism was designed specifically for the purpose of making collapsing toolbars possible in a non-buggy way. :-)

Imagine you are rewriting scaffold and you want the default behavior to be a collapsible app bar.

That doesn't really make sense. What would a collapsible app bar mean in a scaffold where the contents are scrollable?

Would we be able to:
keep the scaffold API the same?

Same as what?

avoid special treatment of the body of the scaffold?

I'm not sure what you mean here. Special in what sense?

make all scroll widgets support this behavior by default (again so that you would not need apps to use special components in the body of the scaffold to make it work).

The scrolling infrastructure in Flutter is build from many components that fit together. At the core you have a viewport. There's three kinds of viewport: single-child, multi-child, and multi-child shrink-wrapping. The single-child viewport is an optimisation for the case of a single (box) child with no scroll effects, so it doesn't support having special scroll effects. The other two both support scroll effects such as collapsing app bars.
Above the viewport you have various ways at the widgets layer to specify the children for the viewport. There's ListView, which is optimised for the case of just box children that render as a list. There's GridView, which is optimised for the case of just box children that render as a grid. And then there's CustomScrollView, which takes a list of arbitrary scroll-effect children (aka slivers) such as SliverList, SliverGrid, SliverPadding, or SliverAppBar.
ListView is essentially just a CustomScrollView with a SliverPadding and a SliverList.
GridView is essentially just a CustomScrollView with a SliverPadding and a SliverGrid.
If you want to mix lists and grids and appbars or whatnot, you just specify the children you want with a CustomScrollView.

Synced with @Hixie offline.
He understands our concerns and gave a suggestion for the app to always live in the sliver world (as opposed to Box world as it is today). I will give this a shot. Ian believes it should not be too complex.
If we run into complexity and API problems, we will reopen this issue and see if we can framework help.

After attempting to migrate our app to Sliver world, I ran into some issues that we were afraid of before. First a confession: I could not make the app entirely live in the sliver world. The regular widget tree setup (no sliver) is just too darn nice and if the appbar does not need to collapse, I prefer to keep it (for instance form edit pages).
As a result of this, I had to make changes like this:

CardContainer which "used to be" just a list which applied standard padding and accepted a list of cards to scroll became infected with Sliver and thus is not usable anymore for non-Sliver applications. (Rename it SliverCardContainer, I suppose?)
If a widget (such as OfferingList) happens to be the body of a scaffold (which the widget did not know before), all of its direct descendants have to be sliver'ed. This causes a problem since most of these widgets return a particular result depending on their data state (data not found, loading indicator, the actual data) so all of these needed to be converted to SliverFills and SliverLists (and once again, the widget now cannot be used in the box layout world). Moreover, most of these paths are seldom touched (and sometimes tests miss them too) so it creates hidden runtime bombs inside the app:

I/flutter ( 2652): ══╡ EXCEPTION CAUGHT BY WIDGETS LIBRARY ╞═══════════════════════════════════════════════════════════
I/flutter ( 2652): The following assertion was thrown building OfferingList(state: _OfferingListState#654384312()):
I/flutter ( 2652): type 'RenderPositionedBox' is not a subtype of type 'RenderSliver' of 'child' where

This duality creates a problem for API support. For instance, a SliverPadding is introduced because normal padding does not work. ListView supports setting padding in between list items, SliverList does not. I am worried that as more and more widgets become fragmented as Sliver vs Box, the overhead of maintaining both worlds will cause headache for both Flutter and apps teams.

All this + the bugs I had filed spooked me enough that I am putting off moving onto this functionality for now.
I am reopening this issue as a discussion thread (which it already is). Please consider merging Sliver and Box worlds somehow and make collapsing app bar an attribute of scaffold (or appbar) similar to what we had before (appBarBehavior: AppBarBehavior.under). I understand this is far from trivial but many apps will not like the list of issues listed here and I am not sure how much of it is fixable. I feel like sliver's are now like async. They infect the code and you can stop them at predefined boundaries (such as delegates).

I don't really see what we can do here. I understand that this is new complexity relative to what we had before, but what we had before was extremely buggy and what we have now is much more correct. I don't see a way to be both correct and interchangeable with RenderBox.

What we have now is much more correct.

Does that imply the RenderBox will be deprecated eventually?

Not just eventually, we've in fact already removed all the RenderBox-based logic that we used to have.

(RenderBox remains for rendering, well, boxes, which is the common case. It's correct for that.)

That's great. I suppose what this issue is for then is my final comment:

make collapsing app bar an attribute of scaffold (or appbar) similar to what we had before (appBarBehavior: AppBarBehavior.under).

IOW, we are not asking for Sliver to be interchangable with RenderBox. What we are asking is to be able to collapse AppBar w/o converting everything to Sliver. You have so far done such an awesome job with API design that our 30k LOC UI code is currently "sliver-free" even though underneath the ListViews etc it is all Slivers. As documented in my migration story above, I would much rather not have a collapsible AppBar if we can't have this.

@mehmetf One thing that might solve your problem for you is to create a Scaffold-like widget whose build function does the CustomScrollView dance for you, so that everywhere else it would just appear that you were using box-like widgets.

Thanks @Hixie. It has been a year since I attempted this. I could try it again and see where I get to.


fix the figsize segfault bug

plt::figure_size is known to sometimes cause segfaults if called
without a preceding plt::figure
as suggested in the issues this is fixed by calling
detail::_interpreter::get() at the beginning of the function

Very nice, thanks for contributing!

Sure, it's a pleasure to work with your framework!


Listbox z-index edge case when using 2 elm-selects

Hello! First off, I just want to say that I really appreciate the time and effort that went into developing this component! I'm a big fan of its usability.
I noticed while trying it out that when you have one elm-select's listbox displaying over another elm-select you can see multiSelectTag close buttons through the overlapping listbox. See screenshot for reference.

It looks like bumping up the listbox's z-index to 2 fixes this issue.
https://github.com/Confidenceman02/elm-select/blob/d9520a3f38a6c4e4f884170b6d7963cd7a754c0c/src/Select.elm#L1760
Currently I'm fixing this by overriding the css. If you'd like, I'd be happy to create a PR. Thanks again!

Hi Kevin!
Many thanks for opening an issue and the kind words!
Yes absolutely, please feel free to open a PR. Otherwise, I can get to this this weekend if you can wait.
👋

Fixed in release 4.1.1


FEATURE: MPNT-28 Prepare gdc-public-demos repository

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-oss-check/2/ : SUCCESS in 8s

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-oss-check/4/ : SUCCESS in 11s

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-oss-check/9/ : SUCCESS in 8s

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-oss-check/11/ : SUCCESS in 6s

Build succeeded (check pipeline).

https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-oss-check/12/ : SUCCESS in 8s

Sonar scan result

No issue found. Congratulations!

More detail, see in https://sonarqube-gate.intgdc.com/dashboard?id=gdc-public-demos-gate-PR2
To scan for vulnerabilities in dependencies and run unit tests (to get coverage report in sonar) please comment your PR with 'extended check sonar'.

Build succeeded (gate pipeline).

https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-fossa-scanning-zuul-el7/2/ : SUCCESS in 1m 14s (non-voting)
https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-sonarqube-scan-zuul-gate/2/ : SUCCESS in 40s
https://checklist.intgdc.com/job/compliance/job/gdc-public-demos-merge-compliance-check/3/ : SUCCESS in 21s


Add global path or workspace folder name to the venv entries

I have a multi-root workspace with a separate virtualenv in two of the directories, both named as env. The extension shows me this list:

The two environments are indistinguishable here (apart from the different packages they contain). Arguably this is not an ideal folder structure and naming, but having the absolute path to the env or the executable and/or some indication which workspace folder contains each environment (or basically any other solution that makes these entries unique) would help identifying them.
(Regardless of this the extension is great and fills in a huge gap.)

@somiandras On the version I'm using (1.2.4) on Windows, there's a property in that list called "Folder" that seems to show the full root OS location of the selected environment. Is this not what you're seeing with yours, or am I using the tool or creating environments differently than you?


Don't know if the toggles are on

You don't know whether Toggle Chooseable Underline and Toggle Fan Colored Illustrations are on

It's very obvious if the underline is enabled or not, but for the illustrations less so, because not all volumes have them. We'll look into making the toggle visible in the button.

The toggles have been updated with new text that says "Turn On/Off ". This should help clear up the confusion


Remove Detections File from Config and Alert on Orphaned Files

Updates to detection testing.
First, it removes some legacy options from testing and the "detections_file" argument from the command line and test_config.json Config file.  This is no longer used.
Second, when running a test, it ensures that all detections have an associated test and all tests have an associated detection.  For non-SSA detections, this will generate an error.  For SSA detections, by default, this will generate a warning.
The following PR should be merged first, which takes care of non-SSA test files which should be moved:
https://github.com/splunk/security_content/pull/2061

Due to the bin folder refactor, it's easier to close this PR and reopen a new one with the changes manually copied over than update this one.  Closing and will reopen,


variable name overlaps with keywords

if we create a variable called "first=0" then the lexer will return four tokens 1. fi, 2. rst, 3. =, 4. 0. Lexer should return only three tokens: 1. first, 2. =, 3. 0

the issue is fixed by changing the lexer algorithm. The reason for this issue is that the tokenizer uses regular expressions to match tokens, the new algorithm checks every character and tokenizes text.


demo not working  when using geo coordinates based test field.

Hello @SteveMacenski and team ,
I have been testing demo_row_coverage example and working well with cartesian test filed. But when running the demo with irregular _test_field.xml ( https://github.com/open-navigation/opennav_coverage/blob/main/opennav_coverage/test/irregular_test_field.xml ), it's not as expected and gives out an error as shown below.
[component_container_isolated-4] [INFO] [1707987164.529318727] [row_coverage_server]: Generating coverage path in EPSG:4258 frame for field of 10 rows (9 swaths).
[component_container_isolated-4] [INFO] [1707987164.621530841] [controller_server]: Received a goal, begin computing control effort.
[component_container_isolated-4] [ERROR] [1707987164.621992034] [controller_server]: Resulting plan has 0 poses in it.
[component_container_isolated-4] [WARN] [1707987164.622049720] [controller_server]: [follow_path] [ActionServer] Aborting handle.
[component_container_isolated-4] [ERROR] [1707987164.650015999] [bt_navigator]: Goal failed
[component_container_isolated-4] [WARN] [1707987164.650070816] [bt_navigator]: [navigate_complete_coverage] [ActionServer] Aborting handle.
[demo_row_coverage-7] Task with failed with status code: 6
[demo_row_coverage-7] Goal failed!
I have already replaced the field file in the demo_row_coverage.py with irregular_test_field. and also set coordinates_in_cartesian_frame to  false in demo_params.yaml
Am I missing any other parameters to be set or should i do some workaround for that?
working environment:
Ubuntu 22.04
ROS Iron

Did you add your gps localization, adjust the starting pose for the robot, and all the other necessary changes to make the demo work for another arbitrary field?
does the actual action server for coverage work? I expect so, so need to adjust the things around it.

Yes, I tried adding gps location to the world. I also tested changing the intial pose of the robot near to the field. It shows Goal succeeded in no time(expected behavior). I think I need to do some work around. Thanks for the clarification.
Yes, no significant issues are found with server so all seems good with that.
I'll keep you posted.

Note that if you provide a GPS field, the path published I believe will also be with respect to GPS coordinates, which this simple demo giving the GPS coordinates to the controller won't necessarily work with. Check the data that is publishing out. If working with GPS the expectation is that you're doing other things than the most simplistic demo that is shown in the demo package.

HI @SteveMacenski ,
The path is being publlised in cartesian CS (transformed to UTM) after providing the GPS field and adding GPS localisation but the values are large. I also changed the robot intial pose w.r.t the path published. I tried various approaches like changing controller but the no positive outcome. I'm confused with this frame "EPSG:4258" as in the fields2cover package this is harcoded as it is standard but is there any relation between this frame and the gps sensor frame? or it's just a frame to represent GPS field.
@SteveMacenski , if possible and if available, Could you please provide me some documentation/tutorial to execute GPS based demo? it would be of a great help.
also, if there is any approach that you want to suggest, I'm pretty much open to do that. Thanks in advance.

Again, the demo is built for a cartesian field that is specifically chosen to have the robot model start at the beginning of the path that the coverage generates. There's no reason you should expect that demo works for your arbitrary other field, regardless if its in GPS or not. Please read over the demo code and you'll understand, its just a demo.
I can't tell you if the coordinates are realistic or not, its based on the coordinate system and inputs you provided it.. Coordinate system in = coordinate system out.

@NK1807 Did you find a solution for using the GPS coordinate with the plugin? Thanks in advice

The demo takes in the Nav Path part of the message to execute. The coordinate system in = coordinate system out. Thus, if you want to use Nav2, your coordinate system in needs to be the cartesian coordinate system of navigation -- and if you're not starting at the edge of the field where the coverage path starts, navigating to that pose first before executing it.
If you want to use full GPS, you need to provide your own capability to navigate using that information -- or later convert it to cartesian for Nav2, for example. This server is completely generic so that you can use it outside of Nav2 as well -- it really is fully generic for any F2C ROS 2 users and all their applications. I wrote extensive documentation of all the parameters and action options and its been tested at length in both GPS and cartesian environments. If you have confusion about how to handle GPS data, I suggest you pause on this server and take some time to learn that before continuing (certainly, I had to in my own education).
Tl;dr:

Its your responsibility to decide what frame you want to operate in and what the outcomes of that are for your system. Luckily its a one time setup that once you setup, will just work forever.
The demo is just that: its a demo for a particular field, with a particularly known starting point, as a demonstration that the server works and how one could use it in the most simplistic case with Nav2. If you want to use GPS, another field, etc you need to adapt the demo as you would need to do for any demo.
I provide the coverage path as well - not just the nav path - that contains the key points of interest. Many serious users of this work will be using the GPS coordinates of the row endings an then the turns rather than naively following a nav_msgs/Path.

@SteveMacenski , Thanks for the detailed information.

@NK1807 Did you find a solution for using the GPS coordinate with the plugin? Thanks in advice

@mattiadutto , Not really. But I found out that when the coordinates_in_cartesian_frame is set to false and given the gps coord gml file, the nav/msg/path published is in UTM frame(UTM coordinates) and the map frame is assigned for this data . So as @SteveMacenski said, a workaround need to be done. F2C need to be tweaked a bit to set frames that we need to work with.
I didn't go deep into it. for time being, I'm converting lat/lon to map point using robot_localisation_node and sending map cartesian coordinates to the server.
If you would like to tweak F2C and make it work with GPS, I'm open to work together.

F2C works fine for GPS, you may not be providing the correct data in the right frame


sorting

it is somewhat related to faceting (https://github.com/castorini/covidex/issues/46) but requires much less work and thinking.
one of the feedbacks we have received directly from the feedback form is the need of sorting the result based on publication dates. i agree this is an important feature, especially since our index is updated weekly. what people want is more of differential.
can we add it quickly?
cc @lintool @edwinzhng @nikhilro

since we don't want to break re-ranking too much, how about "chronologically sort top-50"?

This is actually a much harder problem then it seems... and dates back more than ~20 years, at the dawn of web search. The problem back then was how to combine a static prior (say, PageRank or HITS) with a relevance score (e.g., BM25). Since both are continuous qualities, you've transformed a simple linear ranking problem into a multi-objective optimization problem - the two dimensions being relevance and page quality.
This is exactly the same situation here, substitute PageRank for time...

Can we do like google scholar, i.e., "since 2020", "since 2019" ..., "custom range"?

@rodrigonogueira4 that's faceting ;)
... which brings us back to #46


Define Lifting Properties

Patch Description
This PR defines Lifting Properties, Injective and Projective Morphisms, and also proves a pile of lemmas about them.
Notes
I often find myself looking for the following definition, so I've added it:
record IsIso (from : A ⇒ B) : Set (ℓ ⊔ e) where
  field
    inv : B ⇒ A
    iso : Iso from inv

  open Iso iso public

This does somewhat violate the naming scheme we use in the library, but it lines up with the literature so I think it's a reasonable name.
I've also been using Retract Arrow for retracts of morphisms, which feels a bit klunky? Perhaps it might make sense to define that notion on it's own.

Also: I'm fine with IsIso. I don't have a better suggestion for Retract Arrow.

Sorry to take so long, I've been swamped.

No worries, so have I!


Invoice in mail

When you place a order, the invoice is not send in the mail.
when order is activated it's sends a mail with al the details..
I have adjusted the @mail template for cpanel url.. (default its server/cpanel).. whe use clientdomain/cpanel

Fixed in v2.2.6

Hello,
Is this version already availeble... I have version 2.2.1 installed.. no update feature in backend..
-----Oorspronkelijk bericht-----
Van: Development Team<EMAIL_ADDRESS>Verzonden: maandag 6 februari 2012 9:28
Aan: johanpeters
Onderwerp: Re: [BoxBilling] Invoice in mail (#16)
Fixed in v2.2.6

Reply to this email directly or view it on GitHub:
https://github.com/boxbilling/BoxBilling/issues/16#issuecomment-3824992

Thanks,
Already found it at the website.. update from backend is not working yet... / nu Update button shows up..
-----Oorspronkelijk bericht-----
Van: Development Team<EMAIL_ADDRESS>Verzonden: dinsdag 7 februari 2012 0:46
Aan: johanpeters
Onderwerp: Re: [BoxBilling] Invoice in mail (#16)
Yes this version is already available for download. You can follow us on Facebook https://www.facebook.com/boxbilling

Reply to this email directly or view it on GitHub:
https://github.com/boxbilling/BoxBilling/issues/16#issuecomment-3838806


data Maybe a = Just a | Nothing

ok here it is. i think there are still some gaps.

it is not possible to invoke Just.Nothing() because the placeholder-tail is wagging the ramda-dog. In order to present a consistent API, i have to _curry1(Nothing), effectivekly making Nothing a unary function instead of a nullary one. That just doesn't feel right. If I don't do this, then it fails an invariant test.

2. I don't think the tests are correct. It is passing the "foldable" test although reduce is not on Maybe (yet). So some investigation is required there.

I know we dropped #1749, but would it make sense to create tests that demonstrate how to use this to create a safeHead/safeFind?  Just dropping them in seems quite unmotivated: Why Maybe and not Future/Either/whatever?

Maybe I'm off-base, but I am struggling to see how this fits in with the project.  Why would I use Ramda's constructors instead of just using Folktale, or Sanctuary, or Ramda-Fantasy, or something else.  I could see the usefulness of the helper function that created a Maybe in #1749, but I can also understand the reasons it got nixed.
Now that that is gone, I am left wondering why Ramda should be providing type constructors at all.

Why Maybe and not Future/Either/whatever?

☝  I think this is a good question.  Maybe is a useful type, but so are the other container types.  Ramda provides functions for manipulating these objects, but does it need to provide the types themselves?
I could see providing constructors for custom types that get returned from Ramda's functions, but Ramda doesn't return any custom types at the moment due to the prior PR being eliminated.

@Bradcomp: This is still meant to fill the job of #1749.  The point was the complexity of adding a useful generic maybe function didn't seem worth it.  But by simply exposing Maybe, we can allow users to do the same thing where it makes sense to them.
My question was rhetorical.  I do understand why we want to add only Maybe and its subtypes ... it's simply to make it straightforward for users to add type-safe versions of their own functions or of Ramda functions, something similar to what Sanctuary does automatically, but on the users' own terms.  I asked the question only because without any examples of doing this, the PR seems very unmotivated.

The title is missing the type variable. It should read data Maybe a = Just a | Nothing.

The title is missing the type variable.

:zap:

Surprised to see most JS implementations of Maybe don't implement filter (Sanctuary being the notable exception), and following some Haskell detour, I was wondering if it's worth implementing honoring MonadPlus (chain + of + empty, in short) in ``R.filter`, here's a little demo:
http://goo.gl/V1XAk1
As you may see, I had to extend Maybe.prototype (of ramda-fantasy) to implement empty`. I then noticed this implementation of Maybe doesn't implement empty either. I don't think it would hurt to do so (Maybe.empty()returningNothing()`` seems intuitive). Question is, how much we want in-house types to strictly follow fantasy-land types.

Question is, how much we want in-house types to strictly follow fantasy-land types.

i think the benefits outweigh the costs.

Maybe.empty() returning Nothing() seems intuitive.

My own intuition here so often leads me astray that I've learned not to trust it too much.  Would we also want to implement concat at some point?  And if so, we're presumably trying to live with the Semigroup and Monoid laws, but I'm not sure if that is the best Monoid instance to work with or not.  There is certainly something to be said, when working on a Monoid of Maybe String, to have empty return Just('')`` or for a Monoid of Maybe Numberover addition to have it returnJust(0).  It's not that such is necessarily better, but it seems equally defensible.  The big trouble is that we want both for Maybeto be meaningful on its own, and for it to stand for a whole collection ofMaybe a` types.  I'm not sure we can really do that.

FWIW
λ mplus (Just 4) (Just 0)
Just 4