LAB 4 - Wildcard Usage for Level 3

Summary
Hi, I'm a little bit confused as to where I have to used wildcard types in the KeyableMap class, and when I simply declare the type explicitly? I'm trying to broadly implement the PECS framework, but I don't understand when I need to declare wildcard types.
#Details
Here is a screenshot of some errors I am facing when trying to compile:
KeyableMap.java:11: error: unexpected type
ImmutableMap<String, ? super Keyable> innerMap = new ImmutableMap<String, ? super Keyable>();
^
required: class or interface without bounds
found:    ? super Keyable
KeyableMap.java:21: error: incompatible types: Optional<CAP#1> cannot be converted to Optional
return this.innerMap.get(name);
^
where CAP#1 is a fresh type-variable:
CAP#1 extends Object super: Keyable from capture of ? super Keyable
KeyableMap.java:37: error: incompatible types: Entry<String,CAP#1> cannot be converted to Entry<String,Keyable>
for (Map.Entry<String, Keyable> a: this.innerMap) {
^
where CAP#1 is a fresh type-variable:
CAP#1 extends Object super: Keyable from capture of ? super Keyable
3 errors
Any help is appreciated, thank you!

ImmutableMap<String, ? super Keyable> innerMap = new ImmutableMap<String, ? super Keyable>();
i think youre not supposed to have ? super Keyable  when you initialise a new object

I don't recall using any wildcards for Lab 4. Anyone solved Lab 4 using wildcards?

instead of super, try extends. that is because you are tryign to create an immutablemap of objects that implement the Keyable interface.
hope this helps

Did not use wildcards, I think for wildcards probably dont use during assignment and in constructors but probably can use in your method parameters like map(Function<? super T>, <? extends U>) e.g.

Did not use wildcard for lab 4 as well

Agreed, for level 3 try sticking with the template given in the description:
class KeyableMap implements Keyable {
...
}

You only require declaration of the generic i.e. V extends Keyable at the top when declaring the class, other than that what I did was just use V for the methods

same i used Class for example because technically you can see it as a producer in a way that you are trying to produce this new class which is an implementation of the keyablemap, hence extends instead of super. I would think tha super would be used in a scenario where for example u want to take in something and read it, hence super because you consume it

I didnt use wilcard for this lab, just follow the template given .

highly agree with the rest, even though the description in codecrunch did state that the topic coverage includes generic class, i think that the suggested template of using "extend" will be easier to understand and complete this lab4

@walkaround54 I hope that all of these answered your query.
If it did, you might want to close this issue to declutter this forum. Thank you!


Support Rack v3

Rack v3 removed Rack::VERSION and replaced it with Rack.release
Master has Rack::VERSION added back  so this will probably be permanent.
Rack v3 lowercases all headers Response header keys can no longer include uppercase characters.  So i added support for lowercase headers.
The key points of supporting Rack v3 is the response array must be mutable, the status is an integer, headers are a mutable hash with lowercase keys.

I want to test a bit more today and over the next few days before merging

@metaskills  I want to run run tests against both rackv2 and rackv3 using
https://github.com/thoughtbot/appraisal
I think this will help since all tests pass using rackv2 however using rackv3 tests fail. Having both will hopefully avoid some issues.
Do you have any issues with that?
I want to separate tests into to dir's testRackv2 and testRackv3. Then in the bin/test  run both (v2 is commented out since they pass v3 does not pass so working on that)

All tests are passing locally now.
@metaskills  to give you an overview of the changes
In bin/setup i added bundle exec appraisal install which bundle installs rails 7.0 with rack 2.2.8 this also bundle installed rails 7.1 which uses rack 3.1.7
In bin/test Im running tests again rack v2 and then after those are finished rack v3.
in the test/ dir i created two additional folders testRackv2 and testRackv3 these just have the hander test and proxy server test. I had to copy over the dummy app and test helpers as well since they are separate.
Since there are opinions littered in the PR would like to get your say haha. I do strongly want to test over rack v2 and rack v3 though. I am not attached to the way i went about doing it but its the cleanest way i could think of.

which the names look odd to me. Yea my bad i pushed to snake cased them and make them have a better name
my question is should we just cut Lamby v6 and say that is rack v3 and up? For me it does feel right to cut a v6 and drop rack v2 since it works fine. The only thing that is different is the tests.
we can do like Rails and create a 5-stable branch again its just hard to justify adding that since it works with both rackv2 and v3.
The two tests that are different it the hander_test and the proxy_server_test the other stuff on those dir's are just helper files. I cleaned up the code a bit so now it might look a bit better to you. Now in test/rackv2 and test/rackv3 there are only 3 files  handler_test, proxy_server_test and test_helper

For me it does feel right to cut a v6 and drop rack v2 since it works fine. The only thing that is different is the tests.

Yup, it seems odd but I like it. A few reasons why. 1) if all the tests change, then I think that makes the case 2) It is not like we are doing massive development here. 3) Lamby is essentially a rack web server. It is listed on Rack as such.

again its just hard to justify adding that since it works with both rackv2 and v3.

Making the branch is easy. The idea is how much work are we going to do on that branch afterward. I'm guessing not that much. I like following Rails here since it too is a Rack app. IE, Pick a version where v3 is supported. Declare that as a hard dep. Move forward with good backward compatibility. Oh... that means 5-stable branch would need a v2 lock down in the gemspece and version push too.

Ok sounds good, do you mind doing the v5-stable branch and I’ll fix this PR and add the rack 3 lock. Hopefully tomorrow 👍.

Yup, just pushed it up and created 5.2.2. How does it look to you? If good, I can push that to Rubygems.

Looks good to me, send it!

@metaskills  Ok just pushed to set the version to 6.0.0, drop support for rack v2, and add support for rack v3.

Looks good to me, send it!

Ok, I just pushed v5.2.2 from the 5-stable branch.

Sweet, most of the changes are from tests.
The code is just to_s body/headers, use add lowercase headers and use either rack version or rack release.


Wrong generics on Tree.transform()

The current Tree.transform() method has a wrong generic type signature:
// Is
<U> U transform(Function<? super Tree<? super T>, ? extends U> f);

// Should be
<U> U transform(Function<? super Tree<T>, ? extends U> f);

The following code currently doesn't compile, but would compile if you adapted the signature:
Node<Integer> tree = Tree.of(1, Tree.of(2, Tree.of(3), Tree.of(4)), Tree.of(5, Tree.of(6)));

Function<Tree<Integer>, Tree<String>> toStringInt = i -> i.map(Objects::toString);
Function<Tree<? extends Number>, Tree<String>> toStringNumber = i -> i.map(Objects::toString);
Function<Tree<?>, Tree<String>> toStringAny = i -> i.map(Objects::toString);

System.out.println(tree.transform(toStringInt)); // Doesn't compile
System.out.println(tree.transform(toStringNumber)); // Doesn't compile
System.out.println(tree.transform(toStringAny));

I'm not sure what value the ? super T currently adds... Is there any specific use-case you've had in mind?
I haven't checked other transform() methods, but the same thing probably applies.

Good morning!
Yes thanks, is saw that yesterday and filed #1100 - the current signature makes no sense.
I think in our case we can even replace ? extends U with U, because method return types are co-variant in Java - but I'm not 100% sure.

I think in our case we can even replace ? extends U with U, because method return types are co-variant in Java - but I'm not 100% sure.

Those are differemt beasts. Right now, I can write:
Node<Integer> tree = Tree.of(1, Tree.of(2, Tree.of(3), Tree.of(4)), Tree.of(5, Tree.of(6)));
Function<Tree<?>, Tree<Object>> toStringAny = i -> i.map(Objects::toString);
//                     ^^^^^^ Not String
System.out.println(tree.transform(toStringAny));

This wouldn't be possible if you change ? extends U to U

Yep, you are right!

Duplicate to #1100 but contains additional information

Fixed with #1104


Adds support for SPFx v1.17.1. Closes #4761

Adds support for SPFx v1.17.1. Closes #4761

Merged manually, thank you!


(slack-catalog-backend): please upgrade the dependency backend-common, currently: ^0.20.1 which is quite outdated

Description

(slack-catalog-backend): please upgrade the dependency backend-common, currently: ^0.20.1 which is quite outdated

At the time of writing @backstage/backend-common is on 0.22.0:
https://www.npmjs.com/package/@backstage/backend-common

hey, just bumped some deps to latest which you should see reflected in<EMAIL_ADDRESS>any specific deps that are an issue for you? please submit a PR if you would like any of these changes on a quicker cadence. we're just now getting around to migrating our backstage instance to the new backend.


[TRIVIAL] Don't print a large error in the pretty logs for missing config files

This removes the $error interpolation from a log message where the error is not usually useful for the user. This changes the startup logs from
$ _build/default/src/app/cli/src/mina.exe daemon -seed
2021-03-15 23:17:59 UTC [Info] Coda daemon is booting up; built with commit "48401e92d94948c066c03ca76326c065e5cbfc92" on branch "feature/catch-seed-list-url-errors"
2021-03-15 23:17:59 UTC [Info] Created daemon lockfile "/home/matthew/.mina-config/.mina-lock"
2021-03-15 23:17:59 UTC [Info] Registering async shutdown handler: "Remove daemon lockfile"
2021-03-15 23:17:59 UTC [Info] Booting may take several seconds, please wait
2021-03-15 23:17:59 UTC [Info] Reading configuration files [ "/home/matthew/.mina-config/daemon.json" ]
2021-03-15 23:17:59 UTC [Warn] Could not read configuration from "/home/matthew/.mina-config/daemon.json": $error
        error: {
  "commit_id": "48401e92d94948c066c03ca76326c065e5cbfc92",
  "exn_name": "Async_kernel__Monitor.Error_",
  "exn": [
    "monitor.ml.Error",
    [
      "Unix.Unix_error", "No such file or directory", "open",
      "((filename /home/matthew/.mina-config/daemon.json) (mode (O_RDONLY O_CLOEXEC)) (perm 0o0))"
    ],
    [
      "Raised at file \"src/result.ml\", line 158, characters 17-26",
      "Called from file \"src/deferred1.ml\", line 17, characters 40-45",
      "Called from file \"src/job_queue.ml\" (inlined), line 131, characters 2-5",
      "Called from file \"src/job_queue.ml\", line 171, characters 6-47",
      "Caught by monitor try_with_or_error"
    ]
  ]
}
2021-03-15 23:17:59 UTC [Info] Initializing with runtime configuration. Ledger name: null
2021-03-15 23:17:59 UTC [Info] Using the compiled constraint constants
2021-03-15 23:17:59 UTC [Info] Found genesis proof file at $path
        path: "/home/matthew/.mina-config/genesis/genesis_proof_6a58187abb23eeff53488b4c53c13ca7290f8c28006c93dc59f4216f94463d2d"
2021-03-15 23:17:59 UTC [Info] Loaded ledger from $ledger_file and genesis proof from $proof_file
        ledger_file: "/home/matthew/.mina-config/genesis/genesis_ledger_test_aa18bcdc63c20e16897300c1d05b71170080d3f8eaad4b2b6a492ac5694c98c8.tar.gz"
        proof_file: "/home/matthew/.mina-config/genesis/genesis_proof_6a58187abb23eeff53488b4c53c13ca7290f8c28006c93dc59f4216f94463d2d"
2021-03-15 23:17:59 UTC [Info] Cleaning up old epoch ledgers with genesis state $state_hash at locations $staking and $next
        state_hash: "3NKjfe8qKZfpzGdP53ycKwLxZ4kbA856zBr5Hrq3HAyREVXkEB8b"
        staking: "/home/matthew/.mina-config/epoch_ledgerdd86ee3e-4bcb-3808-9930-f5e1d28f7165"
        next: "/home/matthew/.mina-config/epoch_ledger4498c61b-c1cb-3031-db44-d1628eb0d8e6"
2021-03-15 23:17:59 UTC [Info] Starting node as a seed node
2021-03-15 23:17:59 UTC [Info] Setting current protocol version to "2.0.0" from config
2021-03-15 23:18:00 UTC [Info] Daemon started process of kind "Prover" with pid 20419
2021-03-15 23:18:00 UTC [Info] Registering async shutdown handler: "Close transition frontier, if exists"
2021-03-15 23:18:00 UTC [Info] libp2p peer ID this session is $peer_id
        peer_id: "12D3KooWED5aukSFiuCt2jYNg4jeEjVbZ9ML5cpXvZCNuXMGCGuM"
2021-03-15 23:18:00 UTC [Info] Network not instantiated when node status requested
2021-03-15 23:18:00 UTC [Warn] GCLOUD_KEYFILE environment variable not set. Must be set to use upload_blocks_to_gcloud
2021-03-15 23:18:00 UTC [Info] Mina daemon is connecting

to
$ _build/default/src/app/cli/src/mina.exe daemon -seed
2021-03-15 23:23:54 UTC [Info] Coda daemon is booting up; built with commit "48401e92d94948c066c03ca76326c065e5cbfc92" on branch "feature/unnoisy-config-logs"
2021-03-15 23:23:54 UTC [Info] Created daemon lockfile "/home/matthew/.mina-config/.mina-lock"
2021-03-15 23:23:54 UTC [Info] Registering async shutdown handler: "Remove daemon lockfile"
2021-03-15 23:23:54 UTC [Info] Booting may take several seconds, please wait
2021-03-15 23:23:54 UTC [Info] Reading configuration files [ "/home/matthew/.mina-config/daemon.json" ]
2021-03-15 23:23:54 UTC [Warn] Could not read configuration from "/home/matthew/.mina-config/daemon.json"
2021-03-15 23:23:54 UTC [Info] Initializing with runtime configuration. Ledger name: null
2021-03-15 23:23:54 UTC [Info] Using the compiled constraint constants
2021-03-15 23:23:54 UTC [Info] Found genesis proof file at $path
        path: "/home/matthew/.mina-config/genesis/genesis_proof_6a58187abb23eeff53488b4c53c13ca7290f8c28006c93dc59f4216f94463d2d"
2021-03-15 23:23:54 UTC [Info] Loaded ledger from $ledger_file and genesis proof from $proof_file
        ledger_file: "/home/matthew/.mina-config/genesis/genesis_ledger_test_aa18bcdc63c20e16897300c1d05b71170080d3f8eaad4b2b6a492ac5694c98c8.tar.gz"
        proof_file: "/home/matthew/.mina-config/genesis/genesis_proof_6a58187abb23eeff53488b4c53c13ca7290f8c28006c93dc59f4216f94463d2d"
2021-03-15 23:23:54 UTC [Info] Cleaning up old epoch ledgers with genesis state $state_hash at locations $staking and $next
        state_hash: "3NLnNpAw6TPQDwLeyMXrzPe5FjNRiNRUwhT8xo77ZyNkdk2Ed6jF"
        staking: "/home/matthew/.mina-config/epoch_ledger105d4ee0-2df2-3efd-6180-d2f8cdee0022"
        next: "/home/matthew/.mina-config/epoch_ledger6e038c71-922e-36cf-af69-4fc0991c8429"
2021-03-15 23:23:54 UTC [Info] Starting node as a seed node
2021-03-15 23:23:54 UTC [Info] Setting current protocol version to "2.0.0" from config
2021-03-15 23:23:54 UTC [Info] Daemon started process of kind "Prover" with pid 22382
2021-03-15 23:23:54 UTC [Info] Registering async shutdown handler: "Close transition frontier, if exists"
2021-03-15 23:23:55 UTC [Info] libp2p peer ID this session is $peer_id
        peer_id: "12D3KooWLaHeYCFjj444VZ1X7L9pWiiDYLUyGcP9SyoM9yKPSb4D"
2021-03-15 23:23:55 UTC [Info] Network not instantiated when node status requested
2021-03-15 23:23:55 UTC [Warn] GCLOUD_KEYFILE environment variable not set. Must be set to use upload_blocks_to_gcloud
2021-03-15 23:23:55 UTC [Info] Mina daemon is connecting

Checklist:

[ ] Document code purpose, how to use it

Mention expected invariants, implicit constraints

[ ] Tests were added for the new behavior

Document test purpose, significance of failures
Test names should reflect their purpose

[ ] All tests pass (CI will check this if you didn't)
[ ] Serialized types are in stable-versioned modules
[ ] Does this close issues? List them:

@mrmr1993 - I think this should go against compatible since this doesn't really meet the hotfix criteria

@aneesharaines done

!approved-for-mainnet


Update Pypi with latest build packages

I am getting pycrypto error while installing PyCovenantSQL .
As I have updated pycrypto to pycryptodome .
please build python package  by this latest code and publish it on Pypi.

@laodouya


Use exit code to signal if there are unused dependencies

Addresses part of https://github.com/bnjbvr/cargo-machete/issues/13.
The application now returns 0 if no unused dependencies are found, 1 if unused dependencies are found, and 2 for any other errors (propagated via Result).
What could still be improved in a separate PR:

Error handling (it looks like syntax errors in some Cargo.toml files are skipped instead of causing an error; not sure if intended)
Machine-readable, stable output

Somewhat related, do you plan on releasing a new cargo-machete binary soon, which includes those semantics?
I plan on using it in CI, and having the exit code would help greatly.
If not, I'll go with cargo install --git for now; this might not work well with caching artifacts though.

Yep that's a good idea, will do that in the upcoming days!

And now done, published as 0.3.0!


littlebituicorrect

before and after changing the code

Summary by CodeRabbit

New Features

Enhanced styling and layout of the mobile navigation menu for improved usability.
Updated the Login button to be more prominent with new styling.
Increased font sizes for menu links to improve visibility.

Style

Adjusted font sizes and margins in the main header for better readability.
Added emphasis to the introductory text with updated styling.

@kasinadhsarma can you please review my code bro
You can check the before changing the code
https://github.com/user-attachments/assets/a359243e-1942-4b0f-a11c-8eeed285b3b8

After changing the code


hadoop-lakefs align implementation with s3a contract test

Aligned the lakeFS fs contract test with s3a: https://github.com/apache/hadoop/blob/branch-3.3.1/hadoop-tools/hadoop-aws/src/test/java/org/apache/hadoop/fs/s3a/ITestS3AFileSystemContract.java

rename file to directory behaviour: a/b/c.txt (file) -> newa/newb (dir): newa/newb/c.txt. previous behavior moved the complete path: newa/new/b/a/b/c.txt
exists: when the path is empty, check branch exists - behaves like root folder
get file status: when the path is empty we check branch exists - branch behaves like root folder
contract test code - align with s3a
working directory is not handled in this PR

Part of #2309

Still looking into the test fail - by the s3a.xml contract file, the s3a supports rename a file into a non-exists subdirectory when you specific target filename.
But from the filesystem contract, it looks like it should fail.

Hadoop s3a v2.7 implementation doesn't support rename-creates-dest-dirs while v3.1.x supports it.
Update the contract to be like the base test and 2.7 and turned it into false.


community: image_url download + image_url.url

Description:

adding actual image_url support by downloading the image using requests.get
support for nested urls

Issue:
HumanMessage(
    content=[
        {"type": "text", "text": "Describe the image:"},
        {
            "type": "image_url",
            "image_url": {
                "url": "https://images.unsplash.com/photo-1682687220777-2c60708d6889"
            },
        },
    ],
)

This was not possible because actual urls were not supportet and url objects inside the image_url was not supported.

why do we want to do this inside the chat model as opposed to outside?

the openai api does it internally so if the chat model client does not do it I think langchain should handle this somewhere automatically

closing due to merge conflicts as well as a larger discussion around how to handle multi modal input


Migrate resource ec_deployment_traffic_filter_association to terraform-provider-framework

This ports the ec_deployment_traffic_filter_association resource to terraform-provider-framework.
A migration test is still missing. This will be an acceptance test, because mocking will not work with an old, external provider.

Description

Related Issues

Motivation and Context

How Has This Been Tested?

Types of Changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Refactoring (improves code quality but has no user-facing effect)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Documentation

Readiness Checklist

[ ] My code follows the code style of this project
[ ] My change requires a change to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] All new and existing tests passed

@dimuon This branch is based on the latest feature/530/ec-deployment. Should I remove the unneeded changes from there so we can merge into feature/530/migrate-to-plugin-framework without the deployment changes?

Closing in favor or #5.


[Logging v2] - Deploy to control plane nodes is always active even then unchecked when installing

Rancher version master-head (09/19/2020) bd88c23

Install Rancher HA k8s.
Downstream cluster is RKE DO or k3s/rke2/EKS
Navigate to Dashboard and Apps
Click rancher-logging
Chart Options leave Deploy to control plane nodes unchecked
Preview YAML

Values YAML generates:
additionalLoggingSources:
  eks:
    enabled: false
  k3s:
    container_engine: systemd
    enabled: true
  rke:
    enabled: false
  rke2:
    enabled: false
.....

Old UI PR: https://github.com/rancher/dashboard/pull/1511

https://github.com/rancher/charts/pull/739

I am unable to reproduce this issue with master head dfe81bf.  On a rke cluster with 1 controlplane, 1 etcd, 3 workers, I see 5 fluentbit containers with the box check and 3 without.  I also verified with helm template that the tolerations are being properly written and no "default" tolerations are set.

Rancher version: master-head (10/01/2020) cb9e8a1
For RKE this is true.
k3s and RKE2 (federal/government), checking or unchecking the box fluentbit is found on all nodes.
RKE 2 cluster:
kubectl get nodes -o wide
NAME                                         STATUS   ROLES         AGE   VERSION               INTERNAL-IP    EXTERNAL-IP      OS-IMAGE           KERNEL-VERSION   CONTAINER-RUNTIME
ip-172-31-1-99.us-east-2.compute.internal    Ready    etcd,master   26m   v1.18.9-beta22+rke2   <IP_ADDRESS>    x.x.x.x       Ubuntu 20.04 LTS   5.4.0-1009-aws   containerd://1.3.6-k3s2
ip-172-31-13-11.us-east-2.compute.internal   Ready    <none>        19m   v1.18.9-beta22+rke2   <IP_ADDRESS>   x.x.x.x    Ubuntu 20.04 LTS   5.4.0-1009-aws   containerd://1.3.6-k3s2
ip-172-31-13-53.us-east-2.compute.internal   Ready    etcd,master   21m   v1.18.9-beta22+rke2   <IP_ADDRESS>   x.x.x.x    Ubuntu 20.04 LTS   5.4.0-1009-aws   containerd://1.3.6-k3s2
ip-172-31-5-62.us-east-2.compute.internal    Ready    <none>        19m   v1.18.9-beta22+rke2   <IP_ADDRESS>    x.x.x.x   Ubuntu 20.04 LTS   5.4.0-1009-aws   containerd://1.3.6-k3s2

kubectl get nodes -o wide
NAME          STATUS   ROLES    AGE   VERSION        INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION       CONTAINER-RUNTIME
k3s-master    Ready    master   17m   v1.18.9+k3s1   <IP_ADDRESS>   <none>        Ubuntu 18.04.5 LTS   4.15.0-118-generic   containerd://1.3.3-k3s2
k3s-worker1   Ready    <none>   16m   v1.18.9+k3s1   <IP_ADDRESS>    <none>        Ubuntu 18.04.5 LTS   4.15.0-118-generic   containerd://1.3.3-k3s2

@paynejacob I'm not sure there's any way to make dedicated control plane / etcd nodes in k3s, master nodes usually allow scheduling of pods. Rancher Ember UI shows Control Plane instead of the master role observed with kubectl.
In the case of RKE2 the role etcd, master shown with kubectl it is displayed as etcd Control Plane by the Ember UI and I can schedule pods in them.

Rancher version: master-head (10/01/2020) 1b0778b
rancher-logging 3.6.000
All the following was installed from Dashboard

RKE with 1 dedicated etcd, 1 dedicated control plane and 3 workers.

All nodes had a container for collecting logs
After installing I increased the scale of the etcd nodes to 3 and the fluentbit daemonset scaled properly
Logs were flowing to a configured Output

EKS this was installed properly, all nodes had their fluentbit log collector.
k3s this was installed properly, all nodes had their fluentbit log collector.
RKE2 this was installed properly, all nodes had their fluentbit log collector.


[multistage][hotfix] add special column escape test cases

adding the missing test cases for dash/dot column naming and table escapes
we use to only have quoted identifier tests on LexicalStructure test cases but only on columns.

Codecov Report

Merging #11737 (ef93fbc) into master (78fc66b) will decrease coverage by 48.69%.
Report is 3 commits behind head on master.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master   #11737       +/-   ##
=============================================
- Coverage     63.12%   14.43%   -48.69%
+ Complexity     1118      201      -917
=============================================
  Files          2342     2342
  Lines        125889   125919       +30
  Branches      19360    19362        +2
=============================================
- Hits          79462    18182    -61280
- Misses        40783   106201    +65418
+ Partials       5644     1536     -4108

Flag
Coverage Δ

integration
?

integration1
?

integration2
?

java-11
14.43% <ø> (-48.63%)
:arrow_down:

java-17
14.42% <ø> (-48.56%)
:arrow_down:

java-20
14.42% <ø> (-48.54%)
:arrow_down:

temurin
14.43% <ø> (-48.69%)
:arrow_down:

unittests
14.43% <ø> (-48.68%)
:arrow_down:

unittests1
?

unittests2
14.43% <ø> (+0.01%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.
see 1515 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


chore(package.json): update @upstash/redis version

Close #425

@ImBIOS I'd rather wait for the version to be published as stable, is that fine for you?


Optional Parameters

Hello I’ve been trying to access the optional parameters, but I don’t know where to put the command in the readme that sets them all to true.

Sorry @PrismaticCode, I missed the notification of the issue you raised.  The only optional parameters in barnowl-minew are for the specific listener interfaces (i.e. HTTP Listener) which you'll find here.
If that answers your question, kindly close the issue, otherwise can you provide more details of what you're trying to do?


It would be more useful to import the compiled template than the generated text

ejs templates are meant to be used with different render data, and when importing them, there is no way to pass render data.
I think it will be more useful to import the compiled template instead.
How it works currently
<button><% buttonText %></button>

import rendered from './template.ejs';

results in error: buttonText is not defined
The Suggestion
With the same ejs file,
import template from './template.ejs';
const rendered = template({
    buttonText: 'Click Me'
});

This change would be a matter of changing this line from return compiled(); to return compiled;.

I very much agree with your suggestion.
I'm trying to use parcel from webpack.Now, i get a trouble about parcel-plugin-ejs:  names is not defined.
<% if (names && names.length) { %> 	<% names.forEach(function(src,index){ %><video class="advideo" data-tag="<%= index %>"style="position:absolute;top:0;left:0;display:none;" poster="http://p1.ifengimg.com/a/2016/1021/loading0.jpg" src="<%= src %>" id="adPlayer" preload="auto"></video><% }) %> <% } %>
How to solve this problem now...

@thoughtbyte any thoughts about this? Take in mind that this is how webpack's ejs-loader works, and it seems to be a much better use for this plugin.

fixed in 0.2.0


bst2: CASCacheError: Timed out waiting for buildbox-casd to become ready

Some examples of this failure here:

https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/2681685721
https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/jobs/2687429185

This probably affects buildbox-casd, but as the timeouts are set by buildstream, we decided the primary issue to track this should be here
Downstream issue: https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/issues/1444

For reference, some performance improvements that have alleviate the situation but not completely fixed it:

https://github.com/apache/buildstream/pull/1678
https://github.com/apache/buildstream/pull/1677
https://github.com/apache/buildstream/pull/1680

15 second timeout between sigterm and sigkill also seems a bit on the low side since it actually triggering will result in issues starting BuildStream next time. How about bumping this to one minute?

Bumping the timeout may be reasonable as it may prevent issues on next start and BuildStream at least already mentions what it's doing.
However, we should still improve the underlying issue. @abderrahim mentioned that a likely cause is BuildStream attempting to terminate buildbox-casd when buildbox-casd is in the middle of cache expiry and I agree. If that's indeed the case, we should modify buildbox-casd to stop cache expiry when receiving SIGTERM.

Yeah, I wasn't suggesting not fixing the actual performance issues.

https://gitlab.com/BuildGrid/buildbox/buildbox-casd/-/merge_requests/274 should reduce buildbox-casd shutdown time in case of running cleanup.

I'm leaning towards backporting the fix for freedesktop-sdk CI while we wait for merge and release. We seem to be still losing pipelines due to random errors when there's load.

@jjardon I guess this can be closed now?

I think so, yes

@jjardon I think you have permissions to close as the creator.


Question: Is it possible to order by apply-function result?

I am trying to order items by apply-function result, like:
var outletsAggregationSet = provider.AggregationSet<Outlet>();

var result = outletsAggregationSet
            .Apply(x => ApplyFunctions.GeoDistance(x.RecordShell.Location, myLon, myLat), "Distance")
            .OrderBy(/*How to order by Distance?*/);

Is there anyway I can sort the results by calculated "Distance" as done in the following command:
FT.AGGREGATE outlets-index '@Name:baskin @Location:[55.397 25.123 10 km]' LOAD 2 @Name @Location  APPLY 'geodistance(@Location,"55.397 25.123")' AS distance SORTBY 2 @distance ASC

var outletsAggregationSet = provider.AggregationSet<Outlet>();

var result = outletsAggregationSet
            .Apply(x => ApplyFunctions.GeoDistance(x.RecordShell.Location, myLon, myLat), "Distance")
            .OrderBy(x=>x["Distance"]);

should work.

var outletsAggregationSet = provider.AggregationSet<Outlet>();

var result = outletsAggregationSet
            .Apply(x => ApplyFunctions.GeoDistance(x.RecordShell.Location, myLon, myLat), "Distance")
            .OrderBy(x=>x["Distance"]);

should work.

It works, thank you
But, it is hard for me to debug the issues I am facing:
Adding .Where(x => x.RecordShell.Name == "baskin") before Apply()
debugging args are ["outletsindex","","APPLY","geodistance(@Location,55.3974726,25.1232973)","AS","Distance","SORTBY","2","@Distance","ASC"])  Note the second is empty string
results in 0 records
While adding .Where(x => x.RecordShell.Name == "baskin") after Apply()
debugging args are
["outlets-index","*","APPLY","geodistance(@Location,55.3974726,25.1232973)","AS","Distance","FILTER","@Name == baskin","SORTBY","2","@Distance","ASC"]
Note now the second is "*"
And results an exception : {"Missing (or badly formatted) value for expr->pred.right"}
at StackExchange.Redis.ConnectionMultiplexer.ExecuteSyncImpl[T](Message message, ResultProcessor`1 processor, ServerEndPoint server) in /_/src/StackExchange.Redis/ConnectionMultiplexer.cs:line 2886
at StackExchange.Redis.RedisBase.ExecuteSync[T](Message message, ResultProcessor`1 processor, ServerEndPoint server) in /_/src/StackExchange.Redis/RedisBase.cs:line 54
at StackExchange.Redis.RedisDatabase.Execute(String command, ICollection`1 args, CommandFlags flags) in /_/src/StackExchange.Redis/RedisDatabase.cs:line 1227
at StackExchange.Redis.RedisDatabase.Execute(String command, Object[] args) in /_/src/StackExchange.Redis/RedisDatabase.cs:line 1223
at Redis.OM.RedisConnection.Execute(String command, String[] args) in ...\redis-om-dotnet\src\Redis.OM\RedisConnection.cs:line 27
at Redis.OM.Aggregation.AggregationEnumerator`1.StartEnumeration() in ...\redis-om-dotnet\src\Redis.OM\Aggregation\AggregationEnumerator.cs:line 212
at Redis.OM.Aggregation.AggregationEnumerator`1.MoveNext() in ...\redis-om-dotnet\src\Redis.OM\Aggregation\AggregationEnumerator.cs:line 134

Not sure, if it is expected, or should file a bug with these details!

Hi @tariqalardah can you share your Outlet class here? I would think the first way at least should work as that's going to the main query.
Interestingly I found that if it's string equality in the FILTER predicate, the expression Parser is not wrapping the strings with single quotes which is causing the exact error you are referring to, clearly that's a bug, you can work around it for the moment by wrapping the query with ' yourself when the where clause is after the apply clause. e.g.
.Where(x => x.RecordShell.Name == "'baskin'")

If you could share the Outlet class with me though that would be helpful, I had no problem when I had the Where clause first, it was properly building the query for me.
thanks!

Hi @slorello89, thank you for the response
Here is the outlet class:
[Document(IndexName = "outlets-index")]
public class Outlet
{
    [RedisIdField]
    public int Id { get; set; }
    [Searchable(Aggregatable = true)]
    public string Name { get; set; }
    [Indexed]
    public string Merchant { get; set; }
    [Indexed]
    public string Logo { get; set; }
    [Indexed(Aggregatable = true)]
    public GeoLoc Location { get; set; }
}

Wrapping the filter term with '' eliminated the exception, but I am still trying to figure out why it is returning 0 results (it is not being evaluated correctly).
Another question please, is there a way to override the general query defaulted to "*" instead of adding filter when working with RedisAggregationSet?

Hi @tariqalardah, had a chance to look into this a bit more.
If you put the Where clause before anything else it will automatically apply that clause as the query, e.g.:
foreach(var result in set
            .Where(x=>x.RecordShell.Name == "baskin")
            .Apply(x=>ApplyFunctions.GeoDistance(x.RecordShell.Location, loc), "distance")
            .OrderBy(x=>x["distance"]))

yields:
1643321051.932273 [0 <IP_ADDRESS>:51242] "FT.AGGREGATE" "outlets-index" "@Name:baskin" "APPLY" "geodistance(@Location,55.3974726,25.1232973)" "AS" "distance" "SORTBY" "2" "@distance" "ASC"

As to the reason you aren't getting results, can you run an FT.INFO. I would guess one of two things are happening

1: You are not setting an Id for the objects you are inserting into Redis, if you do not use a Guid or Ulid, Redis.OM will NOT attempt to generate an Id for you and you will need to register an IIdGenerationStrategey with the DocumentAttribute. Because no one is setting your ids they are falling back to the integer default of 0 for everything so only a single record is being indexed
2: There's some odd indexing failure occurring when you insert objects into Redis, if you see any indexing failures please share an example of some of the objects stored in Redis so I can take a look.

Hi @slorello89,
Thank you for the time you put into this.
Regarding issues in indexing, I don't think there are issues, as the integer id is being used.
Ex (keys *):
   1) "RedisTests.Outlet:3192"
   2) "RedisTests.Outlet:95106"
   3) "RedisTests.Outlet:57983"
...

Here is index info
*.cloud.redislabs.com:*> FT.INFO outlets-index
 1) index_name
 2) outlets-index
 3) index_options
 4) (empty array)
 5) index_definition
 6) 1) key_type
    2) HASH
    3) prefixes
    4) 1) RedisTests.RedisOutlet:
    5) default_score
    6) "1"
 7) attributes
 8) 1) 1) identifier
       2) Name
       3) attribute
       4) Name
       5) type
       6) TEXT
       7) WEIGHT
       8) "1"
       9) SORTABLE
    2) 1) identifier
       2) Merchant
       3) attribute
       4) Merchant
       5) type
       6) TAG
       7) SEPARATOR
       8) |
    3) 1) identifier
       2) Logo
       3) attribute
       4) Logo
       5) type
       6) TAG
       7) SEPARATOR
       8) |
    4) 1) identifier
       2) Location
       3) attribute
       4) Location
       5) type
       6) GEO
       7) SORTABLE
 9) num_docs
10) "2654"
11) max_doc_id
12) "2654"
13) num_terms
14) "2642"
15) num_records
16) "24746"
17) inverted_sz_mb
18) "0.12707996368408203"
19) total_inverted_index_blocks
20) "5607"
21) offset_vectors_sz_mb
22) "0.016357421875"
23) doc_table_size_mb
24) "0.277923583984375"
25) sortable_values_size_mb
26) "0.25993251800537109"
27) key_table_size_mb
28) "0.09801483154296875"
29) records_per_doc_avg
30) "9.3240394592285156"
31) bytes_per_record_avg
32) "5.3848299980163574"
33) offsets_per_term_avg
34) "0.69312214851379395"
35) offset_bits_per_record_avg
36) "8"
37) hash_indexing_failures
38) "0"
39) indexing
40) "0"
41) percent_indexed
42) "1"
43) gc_stats
44)  1) bytes_collected
     2) "0"
     3) total_ms_run
     4) "0"
     5) total_cycles
     6) "0"
     7) average_cycle_time_ms
     8) "-nan"
     9) last_run_time_ms
    10) "0"
    11) gc_numeric_trees_missed
    12) "0"
    13) gc_blocks_denied
    14) "0"
45) cursor_stats
46) 1) global_idle
    2) (integer) 0
    3) global_total
    4) (integer) 0
    5) index_capacity
    6) (integer) 128
    7) index_total
    8) (integer) 0

I believe there is an issue in Redis.OM handling Where at the beginning. Here is an example of query I captured in redis-cli monitor where the query is obviously "", and also, I don't know why the following 2 commands:
1643470072.187264 [0 *.*.*.*:63872] "FT.AGGREGATE" "outlets-index" "" "APPLY" "geodistance(@Location,55.3974726,25.1232973)" "AS" "Distance" "SORTBY" "2" "@Distance" "ASC"
1643470072.239264 [0 *.*.*.*:63872] "SELECT" "0"
1643470072.239264 [0 *.*.*.*:63872] "FT.CURSOR" "DEL" "outlets-index" "-1"

Regarding, why no results while using Where after Apply, it is my mistake may be as I thought .Where(x=>x.RecordShell.Name == "baskin") will work as @Name:baskin in the query to result in all names starts with baskin! But apprently it translate to "FILTER" "@Name == 'baskin'" and dont work like this, it only return outlet where exact name is 'baskin'

Hey @tariqalardah can you share the exact query you used that produced
1643470072.187264 [0 *.*.*.*:63872] "FT.AGGREGATE" "outlets-index" "" "APPLY" "geodistance(@Location,55.3974726,25.1232973)" "AS" "Distance" "SORTBY" "2" "@Distance" "ASC"

So that I can try to trace the issue, for me:
foreach(var result in set
            .Apply(x=>ApplyFunctions.GeoDistance(x.RecordShell.Location, loc), "distance")
            .Where(x=>x.RecordShell.Name == "'baskin'")
            .OrderBy(x=>x["distance"]));

produces
1643632346.505311 [0 <IP_ADDRESS>:51876] "FT.AGGREGATE" "outlets-index" "*" "APPLY" "geodistance(@Location,55.3974726,25.1232973)" "AS" "distance" "FILTER" "@Name == 'baskin'" "SORTBY" "2" "@distance" "ASC"

and
foreach(var result in set
            .Where(x=>x.RecordShell.Name == "baskin")
            .Apply(x=>ApplyFunctions.GeoDistance(x.RecordShell.Location, loc), "distance")
            .OrderBy(x=>x["distance"]));

(Notice I dropped the ' around baskin) Produces:
1643632859.266886 [0 <IP_ADDRESS>:51884] "FT.AGGREGATE" "outlets-index" "@Name:'baskin'" "APPLY" "geodistance(@Location,55.3974726,25.1232973)" "AS" "distance" "SORTBY" "2" "@distance" "ASC"

I wonder if somehow how the translator is unpacking your query it's just getting an empty string.
As for the SELECT/Cursor commands, the SELECT is done by the underlying client library to select a database in Redis (0 is the default database), and FT.CURSOR is part of the internal pagination engine of Redis.OM.

Hey @slorello89,
I finally found where the problem is!
It is in:
public static RedisAggregationSet<T> Where<T>(this RedisAggregationSet<T> source, Expression<Func<AggregationResult<T>, bool>> expression)
And all what you need to reproduce it is to only store the search query term in a string variable instead of using constant string in .Where().
.Where(x=>x.RecordShell.Name == "baskin")
In your code snippet try .Where(x=>x.RecordShell.Name == term) where var term = "baskin";

Hey, @tariqalardah thanks for bearing with me, yep that's definitely it, there is an issue in how it's unpacking the frames in the expression parsers #62 should fix this.

Hi @tariqalardah, this should be fixed by #62 in v0.1.6, which is rolling out now.

@tariqalardah I'm going to close this issue now as it should be resolved, feel free to re-open if you still see the problem. Thanks!


Incorrect info

The page says "Must be set to ".al". Required by Visual Studio Code."
That is incorrect.  It should say;
"Must be set to "al". Required by Visual Studio Code."
I have removed the fullstop.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5b9e8228-e083-4965-22d3-0df35c09ac5d
Version Independent ID: 3707c154-ea6e-c317-217d-6d0e75570c1e
Content: JSON Files - Business Central
Content Source: dev-itpro/developer/devenv-json-files.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: solsen

Thanks for catching this. The issue will be fixed with the next doc refresh.


Replace 'gray-add' algorithm

We need to be able to do a series of experiments with different colour transforms for confidence marking, rather than a preset 'add gray'. Replace with a function  that does a general HSL transform

#49 Saturation


Inquire if image captioning tasks are supported

Excuse me, author!
May I ask if this supports image captioning tasks, especially for generating text descriptions of fine-grained images?
Thank you! Looking forward to your reply!

Thank you for your interest in our work. We support generating text descriptions. For this task, you can prompt BLIVA to describe the image in detail.

Thank you for your interest in our work. We support generating text descriptions. For this task, you can prompt BLIVA to describe the image in detail.

Thank you very much for your reply. How can I use your code to implement image captions? May I ask if you can be more specific?
Thank you!

Specifically, first setup BLIVA according to the readme. Then run the evaluate.py using the option --answer_qs
--model_name bliva_vicuna \ --img_path specify your image here
--question "Describe the image in detail."

具体来说，首先根据自述文件设置 BLIVA。然后使用选项 --answer_qs --model_name bliva_vicuna \ --img_path在此处指定图像来运行 evaluate.py --question “详细描述图像”。

Thank you very much!


R.evolve turns arrays into objects

Look here: http://bit.ly/1GqXFQu
Now I know this is also a known characteristic of R.assoc, which was addressed by the addition of update and adjust, but personally I find both quirks very surprising.

Handling arrays closer to what one would expect in the concrete example could be done. But I'm a bit wary about using evolve to recurse into arrays. I think doing something like this would be much better:
var o = { a: [{ f: 0, g: 3 }] };
R.evolve({ a: R.adjust(R.always(1), 1) }, o)

Please, if it's not too long, include the source code with the issue.  It makes for an easier discussion.
This was the example:

var o = { a: [{ f: 0, g: 3 }] };
R.evolve({ a: [{ f: R.always(1) }] }, o)
//=> {"a": {"0": {"f": 1, "g": 3}}}

I agree that this is not something to be loved.  But I agree with @paldepind (how's that for a change?!) that recursing into arrays may not be a great idea.
I just don't see any great alternative to @paldepind's not-so-pretty solution.

For the record, to get the same effect as in my example using @paldepind's approach, you need to call evolve within adjust as well as on the outside, like this:
var o = { a: [{ f: 0, g: 3 }] };
R.evolve({ a: R.adjust(R.evolve({ f: 1 }), 0) }, o);

I agree that generally speaking, evolving arrays isn't a great idea, but consider 1-element arrays or even manipulating the output of toPairs. Here's something I've to do quite often:
var a = [[new Date(), 1], [new Date(), 1]];
R.map(([date, data]) => [date.toISOString(), data], a);

Getting the same effect with adjust:
var a = [[new Date(), 1], [new Date(), 5]];
R.map(R.adjust(R.invoker(0, "toISOString"), 0), a);

If evolved worked:
R.map(R.evolve([R.invoker(0, "toISOString")]), a);

Note that evolve already recurses into arrays, in the sense that apart the object class (in ecmascript terms), everything works as expected:
[{"0": "2015-06-21T04:04:27.963Z", "1": 1}, {"0": "2015-06-21T04:04:27.963Z", "1": 5}]

Good points all.  I'd welcome a PR on this.  I think there would be some serious discussion on this, as we've found that diving into arrays is not a pleasant experience.  But this clearly shows that the existing function has significant room for improvement.

I think the examples given here are a bit deceiving. If you only want to modify from the beginning of an array then yes, this looks desirable. But as soon as that is no longer true then you have to fall back on another approach anyway.
What if instead of this:
R.map(R.evolve([R.invoker(0, "toISOString"), R.inc]), a);

We only wanted to increment the last value of the array and the array had four items instead of two. Then the solution would grow into this:
R.map(R.evolve([R.identity, R.identity, R.identity, R.inc]), a);

Which looks quite horribly. Which to me shows that using evolve on arrays was an inadequate solution to begin with.
I think what we might want instead is a function like this that is more general and can handle more than just a small subset of the problem:
R.map(R.adjustMany({0: R.invoker(0, "toISOString"), 3: R.inc}), a);

Here adjustMany is a mix between adjust and evolve. This has the advantage that both functions are kept simple and small in scope (evolve is only for object and adjustMany is only for lists). Compared to the proposed solution this one is more powerful and IMO is more explicit and thus easier to understand.

All of these examples can be expressed in terms of lenses:
var o = {a: [{f: 0, g: 3}]};

R.set(R.compose(R.lensProp('a'), R.lensIndex(0), R.lensProp('f')), 1, o);
// => {a: [{f: 1, g: 3}]}

var a = [[new Date(), 1], [new Date(), 5]];

R.map(R.over(R.lensIndex(0), R.invoker(0, 'toISOString')), a);
// => [['2015-06-21T16:10:31.385Z', 1], ['2015-06-21T16:10:31.385Z', 5]]

var update = R.compose(R.over(R.lensIndex(0), R.invoker(0, 'toISOString')),
                       R.over(R.lensIndex(1), R.inc));

R.map(update, a);
// => [['2015-06-21T16:10:31.385Z', 2], ['2015-06-21T16:10:31.385Z', 6]]

I think what we might want instead is a function like this that is more general and can handle more than just a small subset of the problem

It seems lenses already satisfy these needs, and have the advantage of being composable.

I'm not sure lenses can easily take the place of the general idea of evolve, especially for the simpler cases it handles.  But it does seem a good fit for this examples.  @asaf-romano: I'm assuming these were simplifications?  Would the new suggested formulation of lenses fit your real-world scenarios too?

Honestly I'm not too familiar with lenses, esp. not with the upcoming API changes for them*, but at a glance this does seem to address my general use case. However:
(1) for simple stuff like address pairs, I do find the evolve syntax much more straight forward, esp. when the operation isn't reusable and should rather be inlined.
(2) Regardless of whether or not it's a good practice to use assoc, assocPath or evolve this way, the current behavior is very surprising, to the point that I'd rather prefer an exception thrown. Since the returned object still behaves like an array to some extent, it's easy to pass over the broken array deeper in your application, not realizing what you did until someone tries to iterate it.

On a side note, the reason I didn't want to get into them so far was their current awkward syntax. The new stuff looks promising.

I have one more concern with uses lenses in place of evolve here:
This show the shape of the relevant input data with ^^ representing the structure and -- representing the values:
var o = { a: [{ f: 0, g: 3 }] };
//      ^^^  ^^ ^ ---

Here's how the (unfortunately broken) code looks as it tries to create an updated object, altering that part of the structure:
R.evolve({ a: [{ f: R.always(1) }] }, o)
//       ^^^  ^^ ^  -----------

Here's how it looks with lenses:
R.set(R.compose(R.lensProp('a'), R.lensIndex(0), R.lensProp('f')), 1, o);
//                    ^^^^^^^^^        ^^^^^^^^        ^^^^^^^^^  ---

This doesn't show that there's something wrong with lenses, but the isomorphism between the input structure and the change shows there's something really right with evolve.

Lenses provide a general purpose, composable solution to many problems. It's not surprising that a specialized function such as R.evolve provides a more convenient API in contexts where it's applicable.
One could, though, write a helper function to create lens compositions. One could then write:
R.set(lensFromPath('a[0].f'), 1, o);

Lenses provide a sound foundation for many transformations. I'd rather provide a handful of supporting functions than a handful of one-off functions which provide similar or identical functionality to one of the new lens functions (R.view, R.set, and R.over).

I'm still not totally sold on the lenses API.  I'm still mulling it over.  Part of it is that reading the Haskell Lens stuff is awful.  There are so many variants of so many functions.  And abstractions that have so many properties simply scare me.  I absolutely understand how strange our current lens implementation is in the context of our other functions.  It hasn't bothered me that much because I also haven't found that much need for lenses.
Obviously, you're the one finding that need at he moment, and I'm likely to defer to you.  But I really want to understand this better first.  I've been off reading Haskell Lens and Prism tutorials, which make my brain bleed.  I don't feel I've gotten the basics completely down yet.  And I'm especially concerned with how well all this translates to JS, where nested property access is not, in fact, a challenge.
Part of the problem is that Ramda has really not tried before to introduce types to our users.  We simply operate on a few built-in types such as Lists (via arrays), Objects, Strings, and Numbers.  For anything else, we simply dispatch to user implementations.  So introducing not only a new type but a complicated one at that is a scary prospect.
I do agree that we should build general-purpose, composable solutions.  But we have to make sure that our building blocks are solid, and that those who will use them really can understand how to put them together.

The nature of the value returned by R.lens is not important to a user of the API. It would be fine to say the return type is Thing, and that R.view :: Thing -> Object -> *.

The nature of the value returned by R.lens is not important to a user of the API. It would be fine to say the return type is Thing, and that R.view :: Thing -> Object -> *.

Not to me.  I don't want magic in our codebase.  I don't want to say that to use R.over or R.view, you need to pass it the output of R.lens or one of the helper functions.  That's why I'm hesitating.  Although the simplification proposed by @scott-christopher would make it more palatable, it's (a) still complex and (b) a bit of a lie, as the true types are substantially more complex still.
I really believe each Ramda function should stand on its own.  If view and over and get mean nothing without lens, then we are fundamentally changing the nature of Ramda.

If view and over and get mean nothing without lens, then we are fundamentally changing the nature of Ramda.

To be fair, the same could be argued about transducers with transduce and friends.
Personally, I really look forward to the new lens API, as it greatly simplifies (in my mind) interacting and updating deeply nested structures – the updating part being a major part of what lenses offer over plain old Object property accessors for immutable objects, not to mention the possibility for other non-linear paths.
Having said that, I do wonder whether they would have more freedom to grow in their own ramda-lens-like repo.
And just for giggles, evolve could be implemented using lenses:
var evolve = R.curry(function (updates, obj) {
  function _evolve(_updates) {
    if (R.is(Function, _updates)) return _updates;

    if (R.isArrayLike(_updates)) {
      return R.reduce(R.pipe, R.identity, R.zipWith(function (k, v) {
        return R.over(R.lensIndex(k), _evolve(v));
      }, R.range(0, _updates.length), R.values(_updates)));
    }

    if (R.is(Object, _updates)) {
      return R.reduce(R.pipe, R.identity, R.zipWith(function (k, v) {
        return R.over(R.lensProp(k), _evolve(v));
      }, R.keys(_updates), R.values(_updates)));
    }

    return R.always(_updates);
  }
  return _evolve(updates)(obj);
});

var o = { a: [{ f: 0, g: 3 }] };
var a = [[new Date(), 1], [new Date(), 5]];

evolve({ a: [{ f: 1 }] }, o);
// { a: [ { f: 1, g: 3 } ] }

R.map(evolve([R.invoker(0, 'toISOString')]), a);
// [ [ '2015-06-22T03:17:59.965Z', 1 ],
//   [ '2015-06-22T03:17:59.965Z', 5 ] ]

R.map(evolve([R.invoker(0, 'toISOString'), R.inc]), a);
// [ [ '2015-06-22T03:17:59.965Z', 2 ],
//   [ '2015-06-22T03:17:59.965Z', 6 ] ]

Having said that, I do wonder whether they would have more freedom to grow in their own ramda-lens-like repo.

This is certainly an option, though our efforts might be better spent contributing to an existing lens library.
To me Ramda feels a bit like Python in that it comes with "batteries included". I like this. I see the appeal of single-purpose packages and have written several myself, but use of any given Ramda function would drop significantly were it moved to a separate package. Ramda has a fairly large audience, but I imagine a spin-off lens library would not. It would be a shame to move the lens functions to a separate package if the result is fewer JavaScript programmers discovering lenses.

It would be a shame to move the lens functions to a separate package if the result is fewer JavaScript programmers discovering lenses.

I like the sentiment, but I don't know if I would be too worried about that, once you start learning functional programming, you're going to run into lenses sooner or later.
I like the idea of a lens library (not surprising I'm sure, having argued for separating out dispatching).
There could even be a ramda-batteries-included library that ties ramda, dispatching, lenses, etc (sanctuary? not sure if that makes sense of if you like the separate S namespace). If I'm just getting started with functional programming (which I am!) and I import R from 'ramda'; and then I really start to understand all this stuff (which I don't yet!), I could then simply import R from 'ramda-batteries'; and all my code still works (unless of course I have a Cartographer who likes to map, but that can be documented) and now I can use lenses etc.
I'm planning to start using Sanctuary soon and it doesn't bother me at all that it is not part of ramda. For one thing, I've browsed your docs and I really love them, and I don't think there would be such a nice place to read about that stuff if it were all part of ramda. I can see the same thing happening with lenses. Along these lines, there's been quite a bit of time now spent discussing dispatching (and now lenses) but a lot of the talk is focused on grafting and comparison to other ramda functions and the like.. instead of how to actually make awesome dispatching and lenses.

Perhaps my concern is unwarranted. Having a family of compatible packages could work well. We'd need to restructure the Ramda website to be more like this:

Ramda at the centre with related packages orbiting it. ramda-lenses could be one such electron.

Having said that, I do wonder whether they would have more freedom to grow in their own ramda-lens-like repo.

In their current latest form I think having lenses in Ramda is just fine. But if there is a desire for them to grow further then a separate repository might be adequate. I also think @CrossEye's reasonings here are great arguments for a separate repository.

_https://speakerdeck.com/garann/code-is-a-job?slide=31

i say keep 'em in. @CrossEye 's point about functions that only consume lenses is a good one, though.

This discussion went off on an interesting tangent. What's your position on the original issue, @paldepind?

I think R.evolve and R.adjust or lenses are nice solutions to the problem.
I think an R.evolve that handled both arrays and objects would be neat. But I also think it would be too implicit and hard to tell what was going on. I like how the other solutions makes it explicit what kind of structure one is working with.

const evolveArray = R.zipWith(R.call)

@GingerPlusPlus, it is very good, but for my case i was needed something more complicated, so i wrote this:
`
// Takes list if arrays and returns array that consists of equally-positioned pairs
// Note: The returned list is truncated to the length of the longest of the input arrays
// Examples:
// zipLongest([1,2], [10,20,30]) -> [[1,10],[2,20],[undefined,30]]
const zipLongest = R.pipe(
R.unapply(R.identity),
R.juxt([
R.curryN(1)(R.flip(R.pluck)),
R.pipe(R.map(R.length), R.apply(Math.max), R.range(0))
]),
R.apply(R.map)
);
// Takes default value and predicate function and returns function that returns default value
// when predicate function returns true
// Examples:
// defaultToWhen(R.identity, R.complement(R.is(Function)))(null) -> R.identity
// defaultToWhen(R.identity, R.complement(R.is(Function)))(R.inc) -> R.inc
const defaultToWhen = R.curry((defaultValue, predicate) =>
R.when(predicate, R.always(defaultValue))
);
// Takes array of functions and array of values and returns array where corresponding
// functions were applied to corresponding values
// Examples:
// evolveArray([,R.inc,,R.always(50)], [1,1,1]) -> [1,2,1,undefined,50]
const evolveArray = R.curryN(2)(
R.pipe(
zipLongest,
R.map(
R.pipe(
R.adjust(defaultToWhen(R.identity, R.complement(R.is(Function))), 0),
R.apply(R.call)
)
)
)
);
`
This is very handy with this function:
// Takes mapper function and function and returns new function that pass its arguments // to mapper and call the second one with transformed arguments // Examples: // mapArgs(evolveArray([,R.inc]), (a, b) =>${a}_${b})(1, 1) -> '1_2' const mapArgs = R.curry((mapper, fn) => R.pipe(R.unapply(mapper), R.apply(fn)));

@zhtbcgtw off topic, but mapArgs with evolveArray sounds like R.useWith.

@GingerPlusPlus, sorry for offtop. Yes, it sounds very close in this case. Except R.useWith is curried to transformers length, so this example will not work:
R.useWith((a, b, c) => `${a}_${b}_${c}`, [R.identity, R.inc, R.defaultTo(42)])(1, 1) // -> function (t){return n.apply(this,arguments)}

mapArgs generally don't limits you with the way you want to transform args (you can change order, or sum them, or convert to object). Using evolveArray here is one of the ways, but in some cases R.useWith is very similar.


Changes on the English and Chinese version of principled-people.mdx

Attention (CC)

Summary of changes
Correct a minor typo in English version of principled-people.mdx;
Create and update Chinese Translation for principled-people.mdx.
There aren't any dependencies.
This change didn't break functionality or introduce any risk.
Relevant Context
For now, no relevant context.
How Has This Been Tested?
It's language and character change, so no debugging and test has been done.
But I have checked the language again after the doc is created.
Screenshots (if appropriate):

Further comments
don't have further comments for now.

Types of changes

[x] Content edit, File upload, content addition
[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Technical Documentation Update
[ ] Other (please describe):

Does this introduce a breaking change?
Breaking change is defined as "A fix or feature that would cause existing functionality to change."

[ ] Yes
[x] No

Checklist:

[ ] My code follows the code style of this project.
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have added/changed necessary documentation (if appropriate)
[ ] All new and existing tests passed.

This is wonderful, thank you :pray:
In the background, I have been looking for someone to review this, but - if I can't find anyone in the next week - we can merge as is.
I really appreciate your work, thank you @notthere-2023 :heart:

It's my pleasure Andy, and it's great for me to learn and create with Kernel along the translation.


Learning spam from all users

As stated in the FAQ spam from .Junk/ can be used to train spamassassin. But this is on a per user basis. Is it possible to use .Junk/ from all users?

Duplicate of #592 closing this issue.


Move SSO Permission sets to MP from Root

User Story
As an MP engineer
I need to run single sign on bootstrap
Without it failing due to API limits
Value / Purpose
By moving the SSO permissions sets we use from Root account to MP, we won't need to do a data source which is going over the SSO API limits, as we can query the state of the MP TF which holds the sso permission sets.
Useful Contacts
No response
Additional Information
No response
Proposal / Unknowns
Proposal
Move these permission sets - https://github.com/ministryofjustice/modernisation-platform/blob/main/terraform/environments/bootstrap/single-sign-on/main.tf#L14
To MP
Unknowns
Need to decide where to put them
Definition of Done
Example - [ ] Documentation has been written / updated

[ ] Permission sets moved
[ ] bootstrap single sign on job can now run in parallel
[ ] Another team member has reviewed
[ ] Tests are green

I'd be interested in helping with this for sure.

PR in draft https://github.com/ministryofjustice/modernisation-platform/pull/6047

New PR raised https://github.com/ministryofjustice/modernisation-platform/pull/6081 to reference the MP permission set resources that have now been migrated in to MP state.

https://github.com/ministryofjustice/modernisation-platform/pull/6086 raised to further reduce the amount of data calls made to the sso api.

https://github.com/ministryofjustice/modernisation-platform/pull/6097 added. new workflow to run the new single-sign-on TF folder in the MP repo

@davidkelliott removed the relevant sso permission set resources form the root account state and then merged https://github.com/ministryofjustice/aws-root-account/pull/859 which removes these resources from the Terraform as they are now managed in the MP repo.

Summary of changes made:

Created new 'single-sign-on' TF directory to manage SSO permissions sets in the MP repo
Migrated MP-specific SSO permission set resources from root account state to MP state
Updated data calls for permissions sets in the bootstrap code to query outputs from MP remote state rather than AWS SSO API (which is getting throttled) - we are still doing data calls to the SSO API for the generic permissions sets but these are ran once and stored in to outputs for the bootstrap code to query
Created new workflow to manage the new SSO TF directory in MP Repo
Removed MP-specific SSO permission set resources from root account terraform/state


Use unambiguous float values in additional-properties test

Updated expected float value of 2.71828 to 2.71875, a value that can be exactly represented as IEEE754 (http/type/property/additional-properties).
Same rationale as for #611.
More detailed explanation: the spec says the type is float32: https://github.com/Azure/cadl-ranch/blob/56f07cf86f006cba5c2e3024eae8581721791be4/packages/cadl-ranch-specs/http/type/property/additional-properties/main.tsp#L73
In terms of 32-bit floating points, 2.71828 and 2.7182800769805908203125 are the same thing (second one is what you get after trying to represent 2.71828 as 32-bit IEEE754). C++ codegen uses 32-bit foats for float32. Not float64. So, C++ codegen does serialize 2.7182800769805908203125, because it is what it sees. Now, the problem is that mockapi.ts is TypeScript, so it reads values as numeric. Practically, that means that it will deserialize the number it receives as 64-bit floating point number. So when it receives 2.7182800769805908203125 it can be reprsented as 64-bit floating point number, but when mockapi tries to compare it with expected 2.71828 value, that value was never converted to 32 bits. And as far as 64-bit representation for 2.71828, it is 2.71828000000000002955857780762016773223876953125. So, the test sees that 2.7182800769805908203125 !== 2.71828000000000002955857780762016773223876953125, and fails.
I am updating the expected value to 2.71875. 2.71875 can be exactly represented as 32-bit floating point number (which means, it also can be represented as exactly the same 64-bit floating number). And the comparison of 2.71875 === 2.71875 will succeed, no matter if different floating point precisions were used on client and server, or the same precision.

I cannot think of an approach to lint/verify. The numeric is in ts file.

I've been fixing as much of them as I know of and can find. The problem is, such constants are not that much searchable.
As I am going through implementation, I am fixing the ones that I encounter, and eventually this way I should encounter them all.
I mean, to my knowledge, we have fixed all of them, but I've been thinking the same after a previous PR, and before that - there's been 3 or 4 similar PRs from me :)
As for prevention: this could be a good tool to test floating point constants: https://www.exploringbinary.com/floating-point-converter/ : if you type 2.71828, there, and check both "single" and "double" precision, it will give you both representations: 2.7182800769805908203125 and 2.71828000000000002955857780762016773223876953125.
Speaking of choosing a new value, it could be helpful to understand how the fractional part should be a number that can eventually be represented as sum of 1/(2^n)s: the same way that ints are a sum of 2^ns, IEEE754 floating point numbers continue that axis to the other side, below 1, and go into fractions; and the "exponent" part is basically another int number which tells what's the n of the leftmost bit - that is what makes them "floating". To better understand the internal composition of floats, you can play with https://www.h-schmidt.net/FloatConverter/IEEE754.html.


How can we switch between inEar and External speaker?

When I run the react native demo app, I can only access inear speaker but I can't switch to loudspeaker mode. How can we achieve that?

Hello,
You can use chooseAudioDevice and listAudioDevices to do this (Android iOS). You will also have to update the bridge so that you can call these from React Native (Android iOS). Let us know if you have further questions

@alnlau I am new to Native android and IOS. Can you please send me just the steps to follow like in https://github.com/aws-samples/amazon-chime-react-native-demo/issues/122#issue-1096035760. That will help a lot.
Thanks

Hi @sthapa1 could you take a look at https://github.com/aws-samples/amazon-chime-react-native-demo/pull/93?


Drop Python 2.7 and Python <=3.5 support

Drops Python 2.7 and Python <=3.5 support as discussed in https://github.com/renatopp/liac-arff/issues/107
This should not be merged before a last Python 2 supporting release is made.
Also closes https://github.com/renatopp/liac-arff/issues/103
Update made by running pyupgrade --py36-plus followed by some manual fixes.

Not sure why the CI is not triggering..

For some reason the interaction with CI in the Github UI is broken and it doesn't show the CI status but it does run successfully in this PR in https://travis-ci.org/github/renatopp/liac-arff/builds/723477357

This looks good to me. Unfortunately, I cannot check what's going on with the CI.


Suggestion: Channel in M.O.S.S

MOSS is an Discord for Minecraft Open-Source Software with a lot of big plugins: prism, essentialsX, factionsuuid and many more.
You could ask for a channel and role like the other developers so you we can easier chat with you. Would be really fun to see you there.
Keep up the really really good work

Thanks, I'm not sure if my plugin is big enough to have a spot on that Discord but if you need to contact me you can add me on Discord (Joe#5782)

I did but you never answer :)


[BUG] Keep volume when VM deletion does not work for restored VMs

Describe the bug
Keep volume when VM deletion does not work for restored VMs
From current observation, normal VMs (VM -> Create) does not have this issue.
Note that we observe same behavior on v1.3.2 too, is this by-design?
To Reproduce
https://github.com/user-attachments/assets/f144c8bd-4bdd-4323-af4c-61a5a246a955
Expected behavior
Should be able to decide keeping volume or not when deleting VM.
Support bundle
supportbundle_KeepVolumeNotWorkOnRestoredVMs_2024-09-27T09-13-11Z.zip
Environment

Harvester ISO version: v1.4.0-dev-20240918
Underlying Infrastructure (e.g. Baremetal with Dell PowerEdge R630): Single node QEMU/KVM, 8C/16G/500G

Additional context

Note that we observe same behavior on v1.3.2 too, is this by-design?

Hi @albinsun
Because the restored PVC has an owner reference pointing to the VMRestore CR, and VMRestore CR has an owner reference pointing to the restored VM.
So once you delete the restored VM, it will trigger the deletion flow:
restore VM deletion -> VMRestore CR deletion -> PVC deletion
That's why you found that all the volumes were eventually deleted.
We have a ticket to redesign the owner references among restoring related resources https://github.com/harvester/harvester/issues/6408


Hiccups in data reading (based on "thermalcam.py")

Hello all
running some code based off AdaFruit's examples using AMG8833 module + Raspberry Pi Zero W.
The python code below reads the pixels in as quickly as it can, formats it as an OSC message and sends to a designated IP where I'd like to signal process in Max to compose some responsive media.
`
from Adafruit_AMG88xx import Adafruit_AMG88xx
from time import sleep
from os  import putenv
from OSC import OSCClient, OSCMessage
from socket import gethostname
putenv('SDL_FBDEV', '/dev/fb1')
#get socket/hostname
id = gethostname()
#initialize the sensor
sensor = Adafruit_AMG88xx()
sleep(.1)
#initialize OSC client
client = OSCClient()
client.connect(('<IP_ADDRESS>', 9876))
#<IP_ADDRESS>
#run code, read sensor
while(True):
    client.send( OSCMessage("/thermal/"+id, sensor.readPixels()))

`

However I am running into a hiccup, and I am not sure the source (it could be the python code, streaming over the network, or some interrupting background process in the Raspbian stretch OS)
After receiving the data, I receive at a smooth frame rate (~80ms) for about 4 seconds, then a hiccup. This is entirely regular. See the screenshot of the visualization of the frame rate in Max Msp (attached).
I have tried experimenting with a time.sleep in the while loop at different intervals but the frame rate decreases and the hiccup persists. I have also tried experimenting with some overclocking settings, etc. I am wondering if anyone has run into a similar problem and knows what the source of the hiccup is and how to fix it! Thanks.

hey @garrett-laroy-johnson I don't think this is an issue with this library.
The stock raspbian operating system is doing lots of stuff in the background as you've noted, and isn't always going to be able to run your threads at the exact time you want.
The best place to get help with your projects is the Adafruit forums, please make a post there :)


Add License?

This extension seems really cool, and it's awesome you've made the source code public!  Would you consider adding a license to the project?

Public repositories on GitHub are often used to share open source software. For your repository to truly be open source, you'll need to license it so that others are free to use, change, and distribute the software.

GitHub: Licensing a Repository

Added a license (mit)

Thanks!


ci: Make new docker image for db-migrations

Context
In MLP, there is a db-migrations folder, which is sim-linked in charts dir from the main repo and is used in some templates like configMap and volume mount in deployment for migration init container and mlp container.
Question
When we remove the chart from the MLP repo, How would we get these db-migrations?
Changes done:
Create another DockerFile to publish an image extending golang-migrate/migrate and add the db-migrations folder with it
This image can be used
Alternatives thought of:
golang-migrate has the ability to add GitHub as a source for migration SQLs Ref. This would've been better, but the source needs the username and access token to get the files, and also there would also be limitations with this approach if the place of installation of the helm chart doesn't have access to GitHub.

I think it would be good to debate this approach in more details. Publishing DB migrations in a separate image is definitely feasible, but it's not a common approach.
caraml-dev/turing handles this by bundling db-migration scripts together with the app binaries inside the same Docker image and then by running the migration programatically from the Golang code. This isn't great either, because multiple replicas of the app may attempt to run the same migration multiple time (it's the same with the current way of using initContainers), but it's fine assuming that running the migration is an idempotent operation.
Publishing migration scripts in a separate image adds the complexity to the versioning/publishing/deployment pipeline and requires pinning the tag of the migration scripts image to the same version as the tag of the main app image.

Agree to add more details on why this approach was chosen:
Approaches
1. Use GitHub as a source for migration SQLs
golang-migrate has the ability to add GitHub as a source for migration SQLs Ref.
Pros

No need for extra docker image

Cons

Need to provide a username/access token to download the SQLs.
If helm install is being done in an environment with restricted access to internet, Installation wouldn't be able to download the files from GitHub

2. Add the migration script alongside app binaries
Form your previous comment

caraml-dev/turing handles this by bundling db-migration scripts together with the app binaries inside the same Docker image and then by running the migration programatically from the Golang code. This isn't great either, because multiple replicas of the app may attempt to run the same migration multiple time (it's the same with the current way of using initContainers), but it's fine assuming that running the migration is an idempotent operation.

Pros

No need for extra docker image

Cons

Need to ensure that the migrations are idempotent
Need to programmatically ensure that if the migration fails, The applications shouldn't get started
Need to add retries for running migration if application pod tries to start before Postgres ( Or leave the pod to go to a crash loop, Let it restart, and with time it restarts when Postgres pod is ready)

3. Create another DockerFile to publish an image extending golang-migrate/migrate
Add the db-migrations folder with it. This image can be used
Pros

No need to worry about the connectivity issues, like in approach 1
We can set this up to run as init-containers or via helm hooks

If via helm hooks: We need to ensure Postgres gets started before the migration job runs. [This eliminates the problem with init containers being run for every pod]

App developers can ensure how many migrations were needed corresponding to the app version. Eg: If an experimental feature is added with app-version 1.4.0 and is removed in 2.0.0, Users installing app:1.4.0 will get migrations until the point where they see the experimental feature. Users installing app:2.0.0 would not see the feature because the migrations would run till 2.0.0

Cons

Publishing migration scripts in a separate image adds complexity to the versioning/publishing/deployment pipeline and requires pinning the tag of the migration scripts image to the same version as the tag of the main app image. [Form your previous comment]

The only overhead is to maintain the extra image.
My References:

https://itnext.io/database-migrations-on-kubernetes-using-helm-hooks-fb80c0d97805
https://bitfieldconsulting.com/blog/db-migration-kubernetes

@romanwozniak
I see Helm hooks + Kubernetes jobs to be a commonly advocated approach for DB migrations. For this to work, i think It definitely needs an image published.

Publishing DB migrations in a separate image is definitely feasible, but it's not a common approach.
By this statement, Do you mean pushing multiple images is not a common approach? If so, How would the Helm hooks approach work?

For this to work, i think It definitely needs an image published.

Not necessarily, if the migration scripts are made available to your Job as a ConfigMap, but for this these scripts must be distributed with chart.

Do you mean pushing multiple images is not a common approach?

Okay, maybe I shouldn't have said that it's "uncommon". What I meant is that this is not have migrations are handled in any of the CaraML components, hence no matter what the chosen approach will be, we should have an explicit goal of making this approach standard for the rest of the platform components/charts.

Not necessarily, if the migration scripts are made available to your Job as a ConfigMap, but for this, these scripts must be distributed with the chart.

Yeah, Since we are pulling the charts to a central location, This wouldn't be possible without duplicating the scripts. So, This is not an ideal option.

What I meant is that this is not have migrations are handled in any of the CaraML components, hence no matter what the chosen approach will be, we should have an explicit goal of making this approach standard for the rest of the platform components/charts.

@romanwozniak,  I agree that the approach should be common across all CaraML components.
@mbruner  Any thoughts here? Should we standardize this approach as the way to go for other components too? Or, Should we get a vote on what would be an ideal approach for all the components?

@ariefrahmansyah  What is your opinion on this one?

@maniteja6799 my preference is to have migration scripts bundled into the app image and run on startup. however, it may require some time to agree and spread this approach over mlp and merlin. so I would continue with merging this PR because it solves the current problem with helm charts and doesn't overlap with the way we deploy apps internally, meanwhile, we should initiate a discussion with other teams

@maniteja6799 my preference is to have migration scripts bundled into the app image and run on startup. however, it may require some time to agree and spread this approach over mlp and merlin. so I would continue with merging this PR because it solves the current problem with helm charts and doesn't overlap with the way we deploy apps internally, meanwhile, we should initiate a discussion with other teams

There are only three components that use automation to run DB migrations – MLP, Merlin and Turing.

Turing - bundling migration scripts with the app and run them at startup
Merlin - bundling migration scripts with the app and run them at startup
MLP – bundling migration scripts with the chart and run them via initContainers

@maniteja6799 Since you need to change MLP anyway, because its chart will be migrated to caraml-dev/helm-charts, I would suggest to update it to follow Turing/Merlin and bundle migration scripts with the app.

Makes sense. Let me work on the relevant changes.

@romanwozniak, @mbruner : Made the discussed changes.

btw, I wanted to know, how will the app version be incremented for this? Do I have to do anything? I see there is a script to generate the version, But not sure what changes I need to do to mark it as a version upgrade.

btw, I wanted to know, how will the app version be incremented for this? Do I have to do anything? I see there is a script to generate the version, But not sure what changes I need to do to mark it as a version upgrade.

CI configuration and release rules on this repo need to be improved. For now, there is no way to release a "nightly" or "dev" release and you have to cut a release tag on the main branch to trigger publishing of the artefacts with a newer version.
So,

Merge this MR
Create a new Release in this repo (I believe, it would be v1.7.1)

Going to merge this MR. thanks @romanwozniak  for the approval.
cc: @ariefrahmansyah


12 create docker container only web app folder

Closes #12

@harikishantk Update the README file too. Add command

Current update: Frozen the dependencies in the requirements.txt. While building the image, following packages:

dlib
cmake
pyaudio
not able to install, due to some dependency error. Working on that part. If the dependency error resolved, the container can be run flawless.

Resolved the errors.

@harikishantk I'm still waiting for your update.


Version 10.42.0 crashing when launching for iOS 12.4.1

How frequently does the bug occur?
Always
Description
Summary
Hey
I have updated my project from version 10.38.0 to the latest version available 10.42.0 since i currently have Realm and realmSwift installed through Framework and i wanted to support Xcode 15 (more specifically Beta 5 since is the one supported by the framework).
Before testing the RealmSwift Framework for 15.0 Xcode, i first tested only updating the version to see if using Xcode 14.1 with most updated version everything was ok and noticed that on iOS 12.4.1 version i get a crash as soon as the app starts.
Also noticed if it was using other iOS version like 12.5.1 it was everything fine.
After all of this, simply tried to have it using pod and by using Xcode 14.1 everything was fine but as soon as i tested it on Xcode 15.0 beta 5 i also got a crash on start using only iOS 12.4.1.
Details
Note that for every test done i always perform a clean build, then delete Derived Data folder and restart Xcode.
Framework used on for Xcode 14.1:

Crash when using Realm and RealmSwift as Framework with Xcode 14.1 on iOS 12.4.1:

Crash when using Cocoapods with Xcode 15.0 Beta 5 on iOS 12.4.1:

Impact
Users using iPhone with iOS 12.4.1.
Stacktrace & log output
No response
Can you reproduce the bug?
Always
Reproduction Steps
No response
Version
10.42.0
What Atlas Services are you using?
Local Database only
Are you using encryption?
Yes
Platform OS and version(s)
iOS 12.4.1
Build environment
Xcode version: 14.1 and 15.0 Beta 5

This was fixed in Xcode 15.1.


Show Sensors That were Previously "Online" on Map

One improvement I have been thinking about is maybe a good task for anyone looking to help do more web development on! Right now the web dashboard only shows sensors that return data that have sent data within the latest query time. However, there are lots more sensors that come on and offline that contributes valuable data. We could improve the site such that it displays all sensors that have previously been online!

I'm starting to look into this!