Improve dark mode

Current dark mode works as expected, but do not offer the best combination of colors. This ticket is about providing a good quality dark mode, which people might want to use.
It should also detect if a user has his device configured in dark mode and copy such behavior by default.
Current implementation does not allow to enable/disable darkmode if a use does not have an account, aka within the getStarted views. This might be also possible.

Looks OK, will be closed for now and improved in a future version when someone mention it.


Can not find eosio/eosio.hpp while compiling with eosio-cpp

I used the documentation provided by EOSI. I made all the required installation as suggested in the docs. While writing the hello world contract, I face this issue when running the following command eosio-cpp -abigen -o hello.wasm hello.cpp. Please help. I am using Ubuntu 18.04 Machine (As I saw in some posts that this error is machine specific)
hello.cpp:1:10: fatal error: 'eosio/eosio.hpp' file not found
#include <eosio/eosio.hpp>
         ^~~~~~~~~~~~~~~~~
1 error generated.

Can you provide which version of eosio-cpp you are currently using?
Example:
~ $ eosio-cpp --version
eosio-cpp version 1.6.1

Also, what is in your /usr/local/eosio.cdt/include/eosiolib/contracts/eosio/ directory?
Example:
/usr/local/eosio.cdt/include/eosiolib/contracts/eosio $ ls
action.hpp    dispatcher.hpp  multi_index.hpp  privileged.hpp         singleton.hpp  transaction.hpp
contract.hpp  eosio.hpp       permission.hpp   producer_schedule.hpp  system.hpp

I've just upgraded to 1.6.1 from 1.5.0 and now can't compile anything.  on OSX the directory you refer to is /usr/local/Cellar/eosio.cdt/1.6.1/opt/eosio.cdt/include/eosiolib/contracts/eosio/ and mine contains:
-rw-r--r--  1 ekkis  staff  21043 Mar 22 16:03 action.hpp
-rw-r--r--  1 ekkis  staff   2672 Mar 22 16:03 contract.hpp
-rw-r--r--  1 ekkis  staff   4074 Mar 22 16:03 dispatcher.hpp
-rw-r--r--  1 ekkis  staff    671 Mar 22 16:03 eosio.hpp
-rw-r--r--  1 ekkis  staff  85064 Mar 22 16:03 multi_index.hpp
-rw-r--r--  1 ekkis  staff   9326 Mar 22 16:03 permission.hpp
-rw-r--r--  1 ekkis  staff   9040 Mar 22 16:03 privileged.hpp
-rw-r--r--  1 ekkis  staff   1837 Mar 22 16:03 producer_schedule.hpp
-rw-r--r--  1 ekkis  staff   4161 Mar 22 16:03 singleton.hpp
-rw-r--r--  1 ekkis  staff   1427 Mar 22 16:03 system.hpp
-rw-r--r--  1 ekkis  staff  10273 Mar 22 16:03 transaction.hpp

but I'm also getting all these other errors:
Error while trying to load a compilation database:
Could not auto-detect compilation database for file "token.cpp"
No compilation database found in /Users/ekkis/dev or any parent directory
fixed-compilation-database: Error while opening fixed database: No such file or directory
json-compilation-database: Error while opening JSON database: No such file or directory
Running without flags.
In file included from /Users/ekkis/dev/token.cpp:1:
/Users/ekkis/dev/token.hpp:3:10: fatal error: 'string' file not found
#include <string>
         ^~~~~~~~
1 error generated.
Error while processing /Users/ekkis/dev/token.cpp.
abigen error

there is no guidance on the release notes about initialising databases nor have I been able to find info by googling the errors.  any help would be much appreciated

Hi,
I am trying to complete the EOSIO tutorial for helloworld on Ubuntu 20.04 and I keep getting an error when trying to compile because I cannot #include the eosio.hpp file.
I don't think this issue has been resolved, can someone help me?

I don't know how are you trying to compile or install EOS blockchain or CDT. If you don't want to deal with that, you can use my development docker which includes a blockchain node (v2.0.6) as well as CDT (v1.7.0). The OP's example (https://developers.eos.io/eosio-home/docs/your-first-contract) works OK with it. The docker also includes tools like Vim and Midnight Commander.
In order to start with coding, first install docker, and 2nd do the following in a terminal:
$ docker run -it jalbiero/eosdev bash
After that, follow the given instructions in the aforementioned example.
If you want to know how to compile/install EOS and CDT you can see the docker build project here:
https://github.com/jalbiero/eos-dev-docker
I will be updating the docker image soon with the latest versions of EOS and CDT.

I will be updating the docker image soon with the latest versions of EOS and CDT.

FYI:
I updated the docker image to EOS 2.0.10:
https://hub.docker.com/r/jalbiero/eosdev
I also added some examples that show how to use the docker:
https://github.com/jalbiero/eos-dev-docker/tree/master/samples

I am trying to complete the EOSIO tutorial for helloworld on Ubuntu 20.04 and I keep getting an error when trying to compile because I cannot #include the eosio.hpp file.

@wfalcon3 One thing that I forgot to mention: Current official releases (2.0.x) don't support Ubuntu 20.04. You have to wait for EOS 2.1.x (currently 2.1.0-rc3).


[FEATURE] It might be a good idea to add a CONTRIBUTION file and a CODE_OF_CONDUCT

Is your feature request related to a problem? Please describe.
I'd like to contribute with the code of dblab, but I don't know very well golang
Describe the solution you'd like
Maybe could be a good idea to add a CONTRIBUTING file for new contributors to get some context of the project and for the environment setup, also could be a good idea to add a CODE_OF_CONDUCT to the repo, for the interaction between developers
Describe alternatives you've considered
I tried to run the code after I cloned, but I got an error Error: empty values required to open a session in database,
I'm using Goland, then I noticed that I'm running the app without parameters so when I added --help, the error disappear

Hi @israteneda. Glad you want to contribute to the project. You just discovered a dark corner of the project, what happen when you run the cli without params. I'm currently working on a solution: every time you run the project with no params, a form will be displayed asking for the right arguments.
If you would like to add contribute guidelines, that would be awesome and welcome, please do!

sure thing!
I'm going to add an initial commit for the contribution guideline in the coming days.
great I'd like to see that solution, another solution could be to show the help message by default.


webview_flutter support load finish callback

Please create a load finish callback at webview_flutter.
I need it to show CircularProgressIndicator.

Duplicate of #27013


Update HPO examples to pull unified container

Let's update the SageMaker, AzureML and AI Platfrom notebooks to use rapids-cloud-ml images for HPO

@zronaghi AI platform is probably not compatible. Google wants you to build from their base notebooks there.
See: https://github.com/rapidsai/cloud-ml-examples/blob/main/gcp/docker/Dockerfile.jupyter_notebook
FROM gcr.io/deeplearning-platform-release/base-cu110

Which example can we use this for then? https://github.com/rapidsai/cloud-ml-examples/blob/main/common/docker/Dockerfile.training.unified#L75

That works for launching jobs directly on the AI platform; I'll add a PR that updates the examples to use the cloud-ml images shortly.

There is an issue with the 0.17 cuda 11.0 unified container exceeding storage of the default docker volume in SageMaker during the pull (extraction stage). The unified 0.17 cuda 10.2 container seems to barely fit, should I go with that?

Would be good to add the PR with 11.0 and we can merge for SageMaker after reducing the size of the container


Default sort disabled in /collections/{collection}/items list so pagination is disabled

Here we are passing a None as sort:
https://github.com/stac-utils/stac-fastapi-elasticsearch-opensearch/blob/2d6cb4dabb5847fa22e4734187779dcbcb7b41b9/stac_fastapi/core/stac_fastapi/core/core.py#L337
As consequence the pagination is impossible since a token is not generated having:
https://github.com/stac-utils/stac-fastapi-elasticsearch-opensearch/blob/2d6cb4dabb5847fa22e4734187779dcbcb7b41b9/stac_fastapi/elasticsearch/stac_fastapi/elasticsearch/database_logic.py#L702

Ignore please this is a regression over our serverless implementation, apologize


maximum resolution of 11,000 is not applied to interpolated timeseries

What did you do?
I queried for an interpolated time series
$ curl -sg "http://localhost:9090/api/v1/query?query=rate(go_gc_duration_seconds_sum[5m])[60m:10ms]"

What did you expect to see?
I expected the "exceeded maximum resolution of 11,000 points per timeseries" error message. @brian-brazil
https://github.com/prometheus/prometheus/blob/6f3e664ae712850b020d95c5c8b8a6ff841803bd/web/api/v1/api.go#L434-L438
What did you see instead? Under which circumstances?
More than 11k points were returned:
$ curl -sg "http://localhost:9090/api/v1/query?query=rate(go_gc_duration_seconds_sum[5m])[60m:10ms]" | jq '.data.result[].values | keys' | wc -l
217020

Environment

System information:

Linux 5.11.0-1022-gcp x86_64

Prometheus version:

prometheus, version 2.28.1 (branch: HEAD, revision: b0944590a1c9a6b35dc5a696869f75f422b107a1)
  build user:       root@lcy01-amd64-016
  build date:       20210724-22:57:51
  go version:       go1.16.6
  platform:         linux/amd64

Alertmanager version: N/A

Prometheus configuration file:

# my global config
global:
  scrape_interval:     15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
  evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
  # scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
  alertmanagers:
  - static_configs:
    - targets:
      # - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
  # - "first_rules.yml"
  # - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:9090']

Alertmanager configuration file: N/A

Logs: None

The error you are pointing at is for query_range, while you are calling query.  This is why it is not applied.
I agree a similar limit should apply to vector results from instant queries.
The effect of the test in query_range is to bail out before starting work, but this may be difficult to achieve for the sort of case you have illustrated: a subquery can be inside an aggregation which makes the final result quite small.
Should be fairly easy to check the number after computing the result and error instead of sending it.

I think we could avoid running subqueries that large, by looking at subquery step and duration. We don't need to do anything fancier than that, and it is better to stop working before hitting the TSDB.

I was going on the comment which says "For safety, limit the number of returned points per timeseries."
It does not say the objective is to avoid doing large queries.

Historically this limit was to avoid running with a step of 1s since 1970
with query_range, which I did once by accident.
Samples per timeseries internally is different, and may break quite a few
users as this hardcoded value was chosen to be enough for realistic query
range use cases, not all range vectors or sub queries.
Improving the memory sample limits may be a better approach, for example it
currently handwaves some stuff as small enough not to matter due to the 11k
as that code predates subqueries.
On Fri 17 Dec 2021, 16:39 Bryan Boreham, @.***> wrote:

I was going on the comment which says "For safety, limit the number of
returned points per timeseries."
It does not say the objective is to avoid doing large queries.
—
Reply to this email directly, view it on GitHub
https://github.com/prometheus/prometheus/issues/9999#issuecomment-996861737,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABWJG5W5D2JOR4VT46KV35LURNRTLANCNFSM5J2A7P7A
.
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:
@.***>

Hello from the bug scrub!
We believe this issues indeed boils down to improving the memory sample limit and/or how we stop sub queries from creating an excessive amount of evaluation steps internally. The 11k limit for data points returned by the query API is a separate thing (and we want to keep it that way).


Fix Contributing Guide To Remove Need For Wiki Article

Pre-Submission Checklist

[x] Your pull request targets the staging branch of FreeCodeCamp.
[x] Branch starts with either fix/, feature/, or translate/ (e.g. fix/signin-issue)
[x] You have only one commit (if not, squash them into one commit).
[x] All new and existing tests pass the command npm run test-challenges. Use git commit --amend to amend any fixes.

Type of Change

[x] Small bug fix (non-breaking change which fixes an issue)

Checklist:

[x] Tested changes locally.
[x] Closes currently open issue: Closes #11006

Description
Following on from issue #11006 - this removes the need for the http://forum.freecodecamp.com/t/how-to-fork-and-maintain-a-local-instance-of-free-code-camp/19116 Wiki page, creating just a CONTRIBUTING document.
If someone wouldn't mind looking over the new CONTRIBUTING.md file, it would be great to get a second opinion to make sure I haven't missed anything 👍

Is this issue open now?

I think I fixed them all @dhcodes

LGTM! Thanks for making the fixes and thanks for contributing to freeCodeCamp 🎉


There's no error when streaming and the client disconnects

In the following exemple, if I disconnect the client before sleep() is done, it will still try to send "test" without outputting any errors.
Also it would be nice, for long streams with infrequent messages, to have an error as soon as the connection is closed (even if we don't send anything on the wire).
#[derive(Clone, Debug)]
struct Greet;

impl server::TestCase for Greet {
    type SubStream = Box<Stream<Item = Notification, Error = tower_grpc::Error>>;
    type SubFuture = future::FutureResult<Response<Self::SubStream>, tower_grpc::Error>;

    fn sub(&mut self, request: Request<Empty>) -> Self::SubFuture {
        let (tx, rx) = mpsc::channel(4);

        thread::spawn(move || {
            thread::sleep(time::Duration::from_secs(10));

            tx.send(Notification {
                value: "test".to_string(),
            }).wait()
                .unwrap();
        });

        let rx = rx.map_err(|_| unimplemented!());
        future::ok(Response::new(Box::new(rx)))
    }
}

@bbigras thanks for reporting this!
If I understand correctly, rx should be dropped when the client disconnects such that subsequent calls to tx.send fails (though i'm not sure this is guaranteed).
The easiest way to test this would be to wrap your rx with a newtype that implements Stream and Drop, where the drop() implementation logs something.
Also, you might consider changing your tx.send to if let Err(e) = tx.try_send(..) { -- i would expect this to fail if the receiver has been dropped. You can check TrySendError::is_disconnected() to verify this is the reason for the failure.

Thanks for the quick reply.
The send doesn't fail. The drop seems to happen after.
output
connected
sending
sending, done
Dropping!

code
struct MyType {
    rx: futures::sync::mpsc::Receiver<hello_world::Notification>,
}

impl Stream for MyType {
    type Item = hello_world::Notification;
    type Error = ();

    fn poll(&mut self) -> Poll<Option<Self::Item>, Self::Error> {
        self.rx.poll()
    }
}

impl Drop for MyType {
    fn drop(&mut self) {
        println!("Dropping!");
    }
}

#[derive(Clone, Debug)]
struct Greet;

impl server::TestCase for Greet {
    type SubStream = Box<Stream<Item = Notification, Error = tower_grpc::Error>>;
    type SubFuture = future::FutureResult<Response<Self::SubStream>, tower_grpc::Error>;

    fn sub(&mut self, request: Request<Empty>) -> Self::SubFuture {
        println!("connected");

        let (mut tx, rx) = mpsc::channel(4);

        thread::spawn(move || {
            thread::sleep(time::Duration::from_secs(10));

            println!("sending");
            if let Err(e) = tx.try_send(Notification {
                value: "test".to_string(),
            }) {
                println!("error: {}", e);
            }

            println!("sending, done");
        });

        let m = MyType { rx }.map_err(|_| unimplemented!());

        future::ok(Response::new(Box::new(m)))
    }
}

Ok. I think I see what's going on; and I think this should be fixed...
Currently, the rx stream isn't dropped until the grpc server tries to write data on the closed stream. So at least one item has to be sent on tx for the server to detect the disconnect.
@carllerche and @seanmonstar seem to have some thoughts on how to fix this. The basic gist is that h2 has this information, but it isn't wired through the various body/stream types yet.

yep. same issue here. this is a blocker.

@carllerche Here's what you said when we chatted about it:

basically, h2 needs to expose is_reset
and then tower-grpc needs to drop
it would check is_reset first
and eagerly drop the stream

...

in theory, you would call poll_capacity first
and that could error on reset
so you wouldn’t need a separate poll_reset

...

but, we aren’t using poll_capacity
so, we got dat infinite buffering ftw

This refers to the fact that Flush doesn't call poll_capacity yet.


refactor mixed density estimation

What does this implement/fix? Explain your changes
A couple of fixes and improvements around MNLE:

log prob for iid data is now much faster on the discrete data because we can actually just pass the iid data as sample dim to CategoricalNet. There is no need to do tricks with the repetitions in the categorical data (i.e., log_prob_iid can be removed (it was not used anyway)).
allow all kinds of flows, not just nsf for MNLE
unify z-scoring API for build_categoricalmassestimator
fix embedding net handling for MNLE. It did not allow for theta embeddings before. Now it does. Importantly, one has to use a "mixed embedding" for the conditioning of the flow because the condition contains embedded theta and "raw" discrete data.

Does this close any currently open issues?
Fixes #1134
Fixes #1136
Fixes #1172
Any other comments?
the first commit is for avoiding circular imports.

One more comment for the PartialEmbedding: I think we could also have the embedding_net as an attribute of MixedDensityEstimator instead of as an attribute of the DensityEstimator and the MassEstimator. Not fully sure if this would work, but it feels a bit wasteful to have the embedding_net twice.

Thanks a ton, this is awesome!
For now, this can only handle 1D discrete dimensions, right?
In the long run, the ultimate solution would be to have an Autoregressive abstraction which just concatenates a list of Estimators (can be DensityEstimator or MassEstimator) in an autoregressive way. No need to do this now ofc.

Yes, the CategoricalNet can only handle 1D because it's not straight forward to extend this. Maybe it would work better with @coschroeder 's Grassmann distribution? Although that one is only binary.
Yes, the autoregressive approach of just concatenating conditionals and using one Categorical Net for each dimension would be a really nice feature.

One more comment for the PartialEmbedding: I think we could also have the embedding_net as an attribute of MixedDensityEstimator instead of as an attribute of the DensityEstimator and the MassEstimator. Not fully sure if this would work, but it feels a bit wasteful to have the embedding_net twice.

I think both estimator need an embedding net because these are different embeddings. For the MassEstimator, it's the y / theta embedding that is sticked together with the potential standardizing net in build_categoricalmassestimator. For the DensityEstimator, it's the PartialEmbedding that contains both the discrete and the y / theta data.
But I am not sure whether that's what you mean?
Looking at this now, I think there is a problem: the density estimation build function, e.g., build_nsf will build a standardizing net for the PartialEmbedding using the entire batch of concatenated discrete and continuous data. So effectively, it will z-score the discrete data as well. E.g., when y is an image so that the y_batch passed to the embedding has shape (batch, 32, 32), including the expanded and repeated discrete x values, then the discrete x values will influence the z-scoring of the image, right?

Update: The PartialEmbedding and the expanding and repeating of discrete data is not needed anymore.
We now build the y-embedding inside of build_mnle so that we can pass the concatenation of the embedded y with the discrete data into the continuous density estimator. There, we also pass a combined_embedding_net that combines that two conditions.
This also enables us to handle sample_shape>1 by just repeating the embedded continuous condition accordingly, and concatenating it with the discrete input that has a sample_shape>1.


add packet length to str and format seq# two digits

@ps2 Two changes I'm suggesting:

add packet length to Packet str  to assist with research
format sequence number to be 2 characters wide to make output more consistent

LGTM!


after training on VoxCeleb1+2, How to do inference?

Dear all:
I succeed to train on VoxCeleb1+2 dataset:
100%|█████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████████| 3371/3371 [08:50<00:00,  6.36it/s]
speechbrain.nnet.schedulers - Changing lr from 0.00076 to 0.00072
speechbrain.utils.train_logger - epoch: 6, lr: 7.63e-04 - train loss: 2.98e+02 - valid loss: 18.50, **valid ErrorRate: 3.86**
speechbrain.utils.checkpoints - Saved an end-of-epoch checkpoint in results/xvect_augment/1987/save/CKPT+2021-09-11+08-48-12+00
speechbrain.utils.checkpoints - Deleted checkpoint in results/xvect_augment/1987/save/CKPT+2021-09-11+02-35-36+00
speechbrain.utils.checkpoints - Deleted checkpoint in results/xvect_augment/1987/save/CKPT+2021-09-11+08-36-01+00

But when I try to do inference on wav pairs, I feel confused on how to create modules and load checkpoint from hyperparams.yaml.
I know how to do inference from Huggingface hub as follows:
            self.speechbrain = EncoderClassifier.from_hparams(
                source="speechbrain/spkrec-xvect-voxceleb",
                savedir="pretrained_models/spkrec-xvect-voxceleb")

Anyone give some advice on how to loaded trained checkpoint and do inference? thank you very much.

@rohaantahir Thanks for your reply. I found the training procedure is extremely slow. When i trained on voxceleb1+2, it will takes me 25 hours for single epoches. I do not finished the total training yet. But there is no mean_var_norm_emp.ckpt generated in checkpoint directory.

There is a file named with nomalizer.ckpt available maybe this would be same but I am not sure about it.

@rohaantahir Thank for reply. How many hours you spent on training on single epoch? and how many gpu cards you used? thank you.

Hi @rohaantahir @dragen1860, I have trained on only vox2. But for the plda verification I see this line in speaker_verification_plda.py file. Now I have two questions:

Only the dev set of vox1 is used which I cannot understand why?
Why this dev set is again divided into two 90%-10% train and test?

Am I missing something or what?


Sanchonet feature request: Constitutional Committee Hot KeyHash Vs ScriptHash

From conway.cddl:
; Constitutional Committee Hot KeyHash: 0
; Constitutional Committee Hot ScriptHash: 1
; DRep KeyHash: 2
; DRep ScriptHash: 3
; StakingPool KeyHash: 4
voter =
  [ 0, addr_keyhash
  // 1, scripthash
  // 2, addr_keyhash
  // 3, scripthash
  // 4, addr_keyhash
  ]

but it seems (with db-sync v2.2.0) it is not possible to distinguish between Constitutional Committee Hot KeyHash and Constitutional Committee Hot ScriptHash.
It would be nice to have the ability to perform given distinction.
Thank you

Hi all,
it seems db-sync v3.0.0 doesn't introduce this ability.

Could you please confirm my assumption or tell me how to get the requested info?
In case my assumption is correct, do you have some time estimations?

Thank you


User Settings - Amazon S3 and figshare display OSF user's name instead of add-on accountholder

Steps

For all OSF add-ons, ensure that your name is the same (for me, "Jinlu Yuan" is the owner of each account)
Log into osf.io or staging.osf.io under a user that does not have the name of your add-on accounts' holder (or you can change the name of your current OSF account to something other than your add-on accounts' name)
Go to Account Settings
Configure all add-ons
Notice the name following "authorized by" for each add-on

Expected behavior
I expected that each "authorized by" name would be the same.
Actual behavior
The specific problem this issue covers is that Amazon S3 and figshare display the name of the OSF user (Susie Soo) instead of the add-on's accountholder (Jinlu Yuan).
(As already addressed by #2031, GitHub and Zotero display the username of the add-on accountholder, not the full name of the user.)

Known issue due to technical obstacles --

Is fixed with refactor.


tomcat:8.0-jdk8 is not available

Sorry, This is not an issue. Just a question.
May I know if there would be tomcat:8.0-jdk8
Currently, we only have tomcat:8.0-jre8.  based on it I cannot create customized docker image to let
 mvn package

work.  mvn package will call javac

See also https://github.com/docker-library/tomcat/issues/55 and https://github.com/docker-library/tomcat/pull/89 (one of which this is arguably a duplicate of).

Thank you so much
I add
apt-get install -y \
    openjdk-8-jdk="$JAVA_DEBIAN_VERSION" \
    ca-certificates-java="$CA_CERTIFICATES_JAVA_VERSION"

to make sure the jdk version is same as the existing jre.


IPv4 address autoconfiguration leaks TX packets/buffers

If I enable CONFIG_NET_IPV4_AUTO in my prj.cfg, the system will start leaking TX packets/buffers as shown by  "net mem" on the console shell (the Avail field of the "TX" row goes to zero over a couple of minutes).  Within a few minutes, the system runs out of TX packets/buffers and all network operations will fail.  I had CONFIG_NET_PKT_TX_COUNT=20, CONFIG_NET_BUF_TX_COUNT=30.  The leak also seems to happen if the application doesn't actually initiate anything network-related, even DHCP.  The problem goes away if I disable CONFIG_NET_IPV4_AUTO.  [I did also have DHCP4 enabled; I had no statically configured addresses.]
I haven't debugged this extensively and don't actually need CONFIG_NET_IPV4_AUTO, but it still took three days to figure out what was causing the network to fail in my application after initially working for a couple of minutes after boot.
I'm using a custom STM32F407ZG board using its native ethernet (CONFIG_ETH_STM32_HAL) (network aspects of the board are similar to olimex_stm32_e407).  I build using Ubuntu 22.4.
Since I don't actually need CONFIG_NET_IPV4_AUTO, this won't impact my work further, but losing packet buffers makes the whole network subsystem look bad and not ready for use (especially in combination with Zephyr apparently still answering PINGs with incorrect checksums! - cf. https://github.com/zephyrproject-rtos/zephyr/issues/7989), and made me almost ready to give up using Zephyr.  I think enabling CONFIG_NET_IPV4_AUTO is an an error Zephyr novices might easily make, and the error just makes Zephyr look bad more than being critical functionality.  [Incorrect checksums in PING replies still look very bad!]

There seems to be a regression related to the recent ARP rework (https://github.com/zephyrproject-rtos/zephyr/commit/771668cf91392ffba172102c6fadd68e75705a91) causing net_pkt leaks if IPv4 autoconfiguration feature is enabled. I'll provide a fix soon.

especially in combination with Zephyr apparently still answering PINGs with incorrect checksums! - cf. https://github.com/zephyrproject-rtos/zephyr/issues/7989

Can you please elaborate on the problem you see here? The 4-year-old issue you mention was provided with a fix after two days, and on my side I see no issues with ICMP checksum calculation with current main.

The ping problem manifested when I tried to ping the zephyr board at its IP address from my workstation on the same local network.  Ping on the workstation was not receiving replies, but tcpdump showed reply packets arriving.  I checked with Wireshark, which said the ICMP checksum was wrong in the received echo replies.  When I saw the 4-year-old issue I stopped analyzing it further.  However, I still see the same problem when I try to ping the board.
I'm running Zephyr 3.2.0-2838-g02b83892d2da on my board and Ubuntu 22.04 on my workstation.  TCP/IP traffic works on the board and DHCP, TCP connect, HTTP GET/POST work fine, so I assume hardware works.  Custom STM32F407ZG board.

The ping problem manifested when I tried to ping the zephyr board at its IP address from my workstation on the same local network. Ping on the workstation was not receiving replies

Have used nordic boards and stm32 board with non-st MACs and I have not seen this issue, pings have worked fine for me.

I've submitted a fix for the net pkt leak in IPv4 autoconf module: https://github.com/zephyrproject-rtos/zephyr/pull/53525.
The ICMP checksum calculation error I simply cannot reproduce, even with commit you reference.

Just checked an stm32 (nucleo f746zg) using the ST MAC with ping, even with autoconfig enabled, and it works fine, checksum is valid.


Add a better Extension handling system

Add a more robust extension loading and managing systems for Vulkan extensions.
So, I will have a class which will have a function which takes an extension name and then adds that function name to the device extension list and retrieve all of its functions. Then other classes can lookup those functions.

Added.


What's the language used in the template ?

Where does the function comes from ? how can i get something from the database ?
How can I interact with the database ? Is this project still alive ?

Hi,
it's twig.
https://twig.symfony.com/


Add Gradle snippets for build related samples to the reference documentation

We currently only show Maven variants of dependency declarations. It would be nice to also show the Gradle equivalents for that.

This has been solved by #300.


Edit tensorflow script mode training and serving notebook

Issue #, if available:
Description of changes:
Minor edits to markdown cells of notebook.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@icywang86rui Please review


Replace JSR 305 annotations

We want to move away from JSR 305 due to "split packages".
References:

Making JSR 305 Work On Java 9
Java 9 Migration Guide: The Seven Most Common Challenges
The Java Module System (book by Nicolai Parlog)
Dropwizard: maven-javadoc-plugin fails due to Automatic-Module-Name
Dropwizard: Migrate away from JSR305

Clsoed by fb47fe4bb6cdc70c9b2d84ef1bd56facf7af53e8

Duplicates #172


Open comments view from connector

As suggested by @thoffeller this would be a killer feature, it'll need some tech scoping but all the info needed should be available.
We can add an extra button in the comments view to open a corresponding view in the host app.

[x] #1827
[x] #1845
[ ] acad/civil
[ ] bentley

Implemented in Revit.
Up to @clairekuang and @Reynold-Chan or @connorivy if we can push this to any other DUI connector for 2.10, otherwise 2.11 will be!

Very cool, thanks!

Neither CSI + Tekla have camera views of the model.

Closing this and keeping these as suggestions for DUI3 cc @Gaschitz


prototype dynamic upgrade/downgrade of Kyma based on CR

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


updating to ED 1.13

Ember-data 1.13 was just released with some changes that affect EDA. You can read about the details here:
http://emberjs.com/blog/2015/06/18/ember-data-1-13-released.html
The first issue I found with when trying ED 1.13.4 with EDA 0.5.6 is that RESTAdapter.ajaxError() has been removed and EDA calls it through _super() (https://github.com/dustinfarris/ember-django-adapter/blob/v0.5.6/addon/adapters/drf.js#L76). While ED 1.13 does call ajaxError() on an adapter if it's present, this is a breaking change in ED 1.13 because RESTAdapter.ajaxError() is a public method that has been removed between ED 1.0.0-beta.19.2 and 1.13.0.
I want to decide on a plan for updating to ED 1.13. Should EDA 1.0 support the latest betas (e.g. 18, 19) and run with the deprecation warnings from ED? Or should we aim for EDA 1.0 to support the new conventions in ED 1.13 which means breaking compatibility with the 0.5.x? If we go this route, there isn't an issue with the breaking change in ED 1.13. On the other hand adding RESTAdapter.ajaxError() to EDA to maintain compatibility is easy enough.
My opinion is that EDA 1.0 should work with the new conventions in ED 1.13 but I wanted to see what you guys think before I start to work on this.

Thanks for digging into this.  ED 1.13 is a big release.  I am against supporting ED betas.  Let's fix up the breaking change with ajaxError and release 0.6.0.

Ok, we're on the same page. Is there a reason why you don't want to release EDA 1.0.0 that's compatible with ED 1.13? It's just a number to me but I'm just try to understand your thoughts.

Yeah, It's time for 1.0.  Let's do that, and follow the pattern outlined in The Ember 2.x Project—when Ember/ED bump to 2.x, so do we, when they bump to 3.x, so do we, etc.  We'll do it loosely, tracking only major version bumps to keep our support aligned, and keep minor/patch versions for our own improvements.

I noticed that after attempting to update to ED 1.13, IDs for newly created objects (For some of my objects IDs are set client-side) were not being serialized/sent to the server. Is this related to the above noted change? If not I'll open a new issue for it.
Appreciate everybody's work on this, this adapter has saved me a ton of time.

@bierdybard Thanks for letting us know. It's definitely information that I'll need when I tackle the upgrade to ember-data 1.13.

Hi guys, quick jump in here. I propose to have a Beta or RC release before final 1.0
I've seen this pattern with several addons and it is a good approach in my opinion, so people can try out the beta/rc and let us know of critical problems before closing the final release.
I would drop support for old ED beta versions and support 1.13 which is the first non-beta version, this way we are completely aligned with ember releases.
BTW, @benkonrath just wanted to say amazing work with supporting ED 1.13 and links PRs man!

Beta sounds good.  @benkonrath are you going to own the upgrade?  I'd like to ship sometime next week if possible if we are going to allow time for a beta period.  If you're busy @holandes22 or myself can take this one.

I'd like to work on this if it is ok with you guys. Waiting for your ack to avoid duplicate work

@holandes22 :+1:

Just found out that ED 1.13 works with ember 1.12.1 and later, meaning we will have to do so as well, any issues with this? usually people upgrades to latest ember versions, but might leave behind someone.
In my opinion is OK, if you use ember-data you want to have the stable version, and if that requires a fairly new ember version the request is reasonable

I have no problem dropping support for Ember <1.12.1.  Ember has been very clear about how core libraries (Ember, ED, etc) are going to stay in sync version-wise going forward.

@holandes22 Great, thanks! I briefly investigated the update a couple of days ago. The first thing I found was that ajaxError has been replaced by handleResponse.
https://github.com/emberjs/data/blob/0d603e964d62b581acc8f1268d19f7e69bdf64fd/packages/ember-data/lib/adapters/rest-adapter.js#L716
Here's what I have so far. It's not complete but it might help you get started.
// addon/adapters/drf.js
  handleResponse: function(status, headers, payload) {
    if (this.isSuccess(status, headers, payload)) {
      return payload;
    } else if (this.isInvalid(status, headers, payload)) {
      return new DS.InvalidError(payload);
    }

    let errors = this.normalizeErrorResponse(status, headers, payload);

    if (status === 500) {
      return new DS.AdapterError(errors, 'Internal Server Error');
    } else {
      return new DS.AdapterError(errors);
    }
  },

  isInvalid: function(status) {
    return status === 400;
  },

Dropping support for older version of ember is ok by me too. We can always do a 0.5.7 release now so that people can use this version with Ember < 1.12.1. Thanks!

Great, I'll start working on a PR

So it turns out that to get ready for ember data 2.0, the task is much bigger. Several normalization methods have been renamed and they now basically need to conform with the JSON API spec, which will become the default adapter in 2.0
I will make a PR to use the new error hooks and format now (so we can support 1.13) and open a separate ticket to get EDA ready for ED 2.0 (according to http://emberjs.com/blog/2015/06/18/ember-data-1-13-released.html there will be ember-watson helpers to help with the transition)

Yeah, it's a big change. A quick fix would be to add the old RESTAdapter.ajaxError() to our adapter and call it instead of this._super() in our adapter (https://github.com/dustinfarris/ember-django-adapter/blob/v0.5.6/addon/adapters/drf.js#L76).
// addon/adapters/drf.js
  restAdapterAjaxError: function(jqXHR, responseText, errorThrown) {
    var isObject = jqXHR !== null && typeof jqXHR === 'object';

    if (isObject) {
      jqXHR.then = null;
      if (!jqXHR.errorThrown) {
        if (typeof errorThrown === 'string') {
          jqXHR.errorThrown = new DS.Error(errorThrown);
        } else {
          jqXHR.errorThrown = errorThrown;
        }
      }
    }
    return jqXHR;
  },

This should give us ED 1.13 compatibility and we can do a full restructure for our 2.0 release. What do you think?

It's a nice approach, but I started already working on a PR to use the new handleResponse, I prefer working on that a little more and see how it goes. I should have something ready tomorrow for you guys to review.
If we get that working we will have 1.13 support but with deprecation warnings for all the other normalization methods, those we can fix in a separate ticket to support ED 2.0.0 (which should be coming out soon btw)
Anyway, let's see how it goes with my PR and decide

Sounds good. I think removing the depreciation warnings as soon as we can is probably a better approach anyway.

Seeking an opinion here. Previously, the error response contained camelizedNames, whereas now, ember-data just adds the payload as is producing reponse errors with snake_case names (just as they come from the server).
Should we keep this behavior? @benkonrath any idea where this was/is handled either in EDA or ED?

hmm, I think ED just expects that the json payload contains attr names in camelCase, but can't find confirmation of that

You can check WIP here https://github.com/holandes22/ember-django-adapter/tree/103-update-ember-data

I don't believe error response data has ever been modified by ED or EDA.  I have in the past relied on non_field_errors which were provided as is in response.errors, e.g.:
this.store.createRecord('user', data).save().then(function() {
  // Success ...
}, function(response) {
  var nonFieldErrors = response.errors.non_field_errors;
  // ...
});

The field errors should definitely be camelCase but ED should do this (it used to do it anyway). For the non field errors, we should just decide what we want to do (keep as snake_case or convert to camelCase) and add an acceptance test so we know if it ever changes.

It should be all one way or the other.  And yes, preferably camel-cased.

Yes agree. The error object contains now camelCase attributes. We modify this ourselves from the payload that gets to handleResponse, apparently if the response is successful, ED converts to camelCase up in the pipeline. I'll post a question at slack channel to see if this is correct behavior.
Another thing, I'm having one test failing in the command line (it passes in chrome), with this error:
TypeError: Requested property names of a value that is not an object. at http://localhost:7357/assets/vendor.js, line 76874
[object Object]

The test is
test('Server error', function(assert) {
  assert.expect(4);

  return Ember.run(function() {

    return store.findRecord('post', 2).then({}, function(response) {
      const error = response.errors[0];

      assert.ok(response);
      assert.equal(error.status, 500);
      assert.equal(error.details, '
Server Error (500)
');
      assert.equal(response.message, 'Internal Server Error');
    });
  });
});

Not much idea what the problem is, did you encounter something similar at some point?

I see the problem in the command line too. The problem comes from the fact that the 500 method doesn't return json. I changed it to json and it worked, however, that's not a good test because a 500 in django doesn't return json. Perhaps this is a bug in ED 1.13? Not sure.

@benkonrath ok, but weird is not failing on chrome.
I'm tempted to remove this test, my reasoning being that if you hit an API endpoint you are expecting json as content type and not html. What I usually do is add a global catcher so every exception that escapes the API gets converted to a proper json response. Is this a real case scenario?

@holandes22 The test was probably more relevant when the jqXHR object was being returned in the error case (as in ED beta.19). ED is now handling parse errors so removing the test should be ok.
https://github.com/emberjs/data/blob/v1.13.4/packages/ember-data/lib/adapters/rest-adapter.js#L958
It's still strange that it fails on the command line and not in browsers. Not sure what's going on there.

Forgot to point out that we currently have a similar try / catch block which is why the test is there.
https://github.com/dustinfarris/ember-django-adapter/blob/master/addon/adapters/drf.js#L81

I see, thank you.
According to https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/model/errors/invalid.js#L44 there is where the error names should be converted to camelCase

That comment might be out of date because the example has a reference to ajaxError() which has been removed. extractErrors is still in the json serializer so it's probably still useful:
https://github.com/emberjs/data/blob/2385a7c2e64467a1823b91795a07bf68d3940b4c/packages/ember-data/lib/serializers/json-serializer.js#L1261

yes, you are correct, found it after making the comment (missed that part in the docstring of handleResponse).
The problem is that for some reason the default implementation is not being able to map the properties in the payload to the DS.Model, so investigating that now

If I format the error array as ED expects it as explained here http://emberjs.com/api/data/classes/DS.InvalidError.html
(which is similar to a jsonapi error obj but with a key 'details' instead of 'detail', not sure if this is an overlook in ED) I see that extractError maps it properly.
For example:
// response from server 400
{'field_name1': ['error 1', 'error 2'], 'field2': ['error 1']}

adapter converts to:
[
  {details: 'error 1', source: { pointer: '/data/attributes/field_name1' }},
  {details: 'error 2', source: { pointer: '/data/attributes/field_name1' }},
  {details: 'error 1', source: { pointer: '/data/attributes/field2' }}
]

This gets converted by default extractErrors properly (camelCased) to the hash:
{fieldName1: ['error 1', 'error 2'], fiedl2: ['error 1']}

But, I though that the InvalidError.errors property was replaced with this hash and then returned to the request, but apparently this is only set in the record, and the InvalidResponse has the unmodified payload  in the errors attribute (the one that looks like a jsonapi error object).
So in the case of a 400, the record in error state will have an 'errors' property with an error array built upon the hash from extractErrors https://github.com/emberjs/data/blob/master/packages/ember-data/lib/system/store.js#L2188,
Which can be retrieved with:
post.get('errors.fieldName1') => [{attribute: 'fieldName1', message: 'error 1'}, {attribute: 'fieldName1', message: 'error 2'}]

This is somewhat counter-intuitive to me, instead of getting the validation issues from the error response, I need to fetch them from the record (and in a somewhat awkward manner).
I modified my branch to work this way, but does this sounds reasonable guys? I think I'm missing something here.

I don't think you're missing anything.  You have accomplished getting ED to set the errors on the model in the desired format.  That is important for users and esp. addons that expect these errors to be formatted that way.
Meanwhile, DRF's response gets returned raw to the user in response.errors, which is great for our users who may not necessarily understand the internals, but want to inspect the DRF response for whatever reason.

What happens with non_field_errors that don't have a field pointer?

@dustinfarris good point on non_field_errors, I overlooked that test case. I think since it has no key, naturally won't appear in the record (as ED cannot map it). But since the InvalidError object contains the original payload, it will be present there (which is annoying forcing us to use 2 different objects to form the errors). I'll add a test case for it
BTW, ED 1.13.5 was released last night, I'll update the branch for that version two
They fixed the inconsistency I mentioned with the jsonapi error object (using "detail" key instead of "keys")
https://github.com/emberjs/data/pull/3497

@holandes22 can you open a PR and add the "in progress" label.

@dustinfarris sure, wanted to the test my branch a little more before submitting the PR, but I'm ready no, sending it in a few minutes


Mocking demeter chain method erases class type

I'm trying to mock a Car object with a demeter chain for honking the horn (eg. $car->horn()->honk()).
For some reason $mockCar instanceof Car yields true for
$mockCar = Mockery::mock(Car::class)->shouldRequire('horn')->mock();
but false for
$mockCar = Mockery::mock(Car::class)->shouldRequire('horn->honk')->mock();
This makes it difficult to pass mock objects to functions such as function driveCar(Car $car) {...}
It seems to me that the methods that are mocked on an object should not affect the type of the object itself. If I add a method bar() to class Foo, that should not change its type from Foo to NotFoo.
The functionality works correctly when the horn() method is mocked separately to return an instance of Horn instead of using demeter chains in shouldRequire().
Some sample code from a test suite illustrates the problem:
<?php namespace Unit\Automotive;

class Car {
	/* ... */
}

function driveCar(Car $car) {
    /*
       ...
       $car->horn->honk();
       ...
    */
}

class AutotiveTest extends TestCase
{

	public function testCar() {

		// define mock objects
		$mockCar = Mockery::mock(Car::class)
			->shouldReceive('horn')
			->mock();

		$badMockCar = Mockery::mock(Car::class)
			->shouldReceive('horn->honk')
			->mock();

		// debug information
		printf("mockCar is car: %s, get_class()=%s\n",
			$mockCar instanceof Car ? 'true' : 'false',
			get_class($mockCar));

		printf("badMockCar is car: %s get_class()=%s\n",
			$badMockCar instanceof Car ? 'true' : 'false',
		    get_class($badMockCar));

		// this is ok, $mockCar is a Car
		driveCar($mockCar);

		// this throws an exception because $badMockCar is not a Car
		driveCar($badMockCar);

	}
}

This outputs:
mockCar is car: true, get_class()=Mockery_0_Unit_Automotive_Car
badMockCar is car: false get_class()=Mockery_1__demeter_horn

There was 1 error:

1) Unit\Automotive\AutotiveTest::testCar
ErrorException: Argument 1 passed to Unit\Automotive\driveCar() must be an instance of Unit\Automotive\Car, instance of Mockery_1__demeter_horn given, called in /var/www/*redacted*/tests/Unit/Automotive/AutomotiveTest.php on line 46 and defined

I believe when you do shouldRequire('horn->honk), it's almost like a macro for
Mockery::mock(Car::class)->shouldReceive('honk')->andReturn(Mockery::mock()->shouldReceive('honk')->getMock())

So your last call to mock is being called on the mock that is returned from the honk call and I think that is desired behaviour.
I would recommend splitting it in to two statements.
$mockCar = Mockery::mock(Car::class);
$mockCar->shouldReceive('horn->honk');

That makes sense.
Mockery::mock(Car::class) returns an object of type Car and
Mockery::mock(Car::class)->shouldReceive('horn->honk') returns an object of type horn.
Would it be possible to add a line to the documentation at https://github.com/padraic/mockery/blob/master/docs/reference/demeter_chains.rst to remind people not to chain both expressions together?


Partial support for Danby DPAC120068

(My first time ever contributing to open source!) I haven't filled in all of the codes, but most are there.

(I wasn't sure what code # to use either, I just made something up)


[Scarthgap] Torizon maintenance

Here’s a summary of the bumps performed in this maintenance:
fastfetch: 2.16.0 → 2.29.0 (release notes: https://github.com/fastfetch-cli/fastfetch/releases)
* note: this bump brings us the change from Torizon Core to Torizon OS when running on our OS
fluentbit: 3.0.7 → 3.1.9 (release notes:https://github.com/fluent/fluent-bit/releases)
* note: using meta-openembedded backported recipe, so in the future we can drop this recipe from our layer
greenboot: 0.15.4 → 0.15.7 (release notes: https://github.com/fedora-iot/greenboot/releases)
composefs: 1.0.4 → 1.0.5 (release notes: https://github.com/containers/composefs/releases)
* note: using meta-openembedded backported recipe, so in the future we can drop this recipe from our layer

On composefs there's no customization to be done, but I've added a .bbappend anyways, in order to remember that this is just a backported recipe that we should drop in the future, and any customization should be done on .bbappend.
But on fluentbit, there are some customizations done. Specially on EXTRA_OECMAKE. The PACKAGECONFIG on the upstream recipe is not complete, and seems to be disabling some default configs of the build. It wasn't straight forward to use only PACKAGECONFIG and we still would have to manually modify EXTRA_OECMAKE in order to both make it build and configure it to what we had. So in order to simplify things, we just set everything manually on the .bbappend.

Getting closer every day to finally dropping some of these recipes from our meta-layer.

Keep an eye out for stuff we can contribute upstream, guys!


Leaderboard Fails to Update Immediately After New Polls or Votes Are Submitted

Problem Summary
Users are experiencing issues where newly created polls or votes do not appear in the leaderboard statistics immediately after submission. The updates only become visible upon manually refreshing the application. This issue suggests a potential problem with state management or real-time data updating within the app.
Description
When a user creates a new poll or submits a vote, the expectation is that these actions will immediately be reflected in the leaderboard. However, the current behavior requires users to refresh the entire application to see their updates. This behavior can confuse users and detract from the real-time interactive experience expected from modern SPAs (Single-Page Applications).
Current Behavior

New polls or votes are submitted successfully.
The leaderboard does not update automatically with the new data.
A manual refresh of the application is required to see the changes.

Expected Behavior

Any new poll creation or vote should trigger an immediate update in the leaderboard.
Users should see their changes reflected in real time without needing to refresh the application manually.

Steps to Reproduce

Log into the application.
Create a new poll or participate in an existing poll by submitting a vote.
Navigate to the leaderboard page to view updates.
Observe that the new data is not reflected in the leaderboard.
Refresh the page manually.
Observe that the new data appears in the leaderboard after refreshing.

Possible Causes

State Management: After adding new data, the state might not be correctly updated across components or views.
Client-Server Synchronization: After data modifications, there might be a delay or lack of real-time synchronization between the client and server.
Caching Issues: If there's aggressive caching, either on the client or server side, it might prevent the new state from being fetched immediately.

There's a similar issue with the poll list on the home component. Newly created polls are not being displayed in the poll list immediately after their creation. This is similar to the issue with the leaderboard updates, indicating a broader state management or data synchronization problem within our application.
Additional Details:

When a user creates a new poll, although the backend confirms successful creation, the poll does not appear in the poll list visible on the home component.

Like the leaderboard, the new poll only becomes visible in the poll list after the user manually refreshes the entire application.

This issue disrupts the user experience and suggests that our frontend is not dynamically updating to reflect changes in the application's state or is not receiving real-time updates from the backend.

Potential Impact:

User Experience: Users may believe their actions (like creating a poll) have not been successful, leading to confusion or repeated attempts.

Data Integrity: There is a risk that the perceived lack of responsiveness might lead to data duplication as users attempt to create multiple polls due to a lack of immediate feedback.

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


WebGLTiles / GeoTIFF source pyramids

The current example for pyramid of WebGLTileLayers works well, unfortunately it does not scale when there are bigger pyramids and thus more layers are required. Depending on the browser, setting, machine, environment, etc it will happen quite soon that WebGL-contexts are lost (as seen in the console), which results in not-rendered tiles and in general a very bad performance (2-5 FPS instead of fluent 30ish).
I think this issue can be solved by providing a separate source, representing a pyramid of GeoTIFFs. This source will be very similar to the current one, but instead of a direct file reference it receives a template string and a tile grid object (very similar to the WMTS source, in fact).
Each requested tile may now be composed of all overlapping tiles of the GeoTIFF pyramid, thus being very similar to the current GeoTIFF source.
As there is now only a single canvas/WebGL context per layer/renderer the issue should be solved.
Please let me know whether this is feasible and easy to implement!

I think we'll want to address context sharing (or otherwise solve #12800) whether or not we add a new source or layer type to represent GeoTIFF (or other source) pyramids.
One issue with GeoTIFF pyramids is that there is no guarantee that the underlying tile grids will be uniform for a given resolution or zoom level.  The renderers currently assume that there is a single tile grid.  If you constructed a GeoTIFF pyramid where two GeoTIFFs at the same resolution had internal overviews or tile layouts that differed from one another, this would break the assumption by our renderers.  I think that currently a GeoTIFF (or other source) pyramid is best represented by a layer group in OpenLayers (as @ahocevar did in the COG pyramid example).
It feels to me like we should first address context sharing - making it possible to render many WebGL tile layers without exhausting the context limit.  Then I think we could add a new layer group type that makes it easy to work with GeoTIFF pyramids.  A layer group constructor for working with tiled STAC assets could make sense (and it would be nice to work on updating the STAC Tiled Asset Extension to reduce duplication and conflicts with the evolving OGC 2D TMS spec, or perhaps just use the OGC API - Tiles spec instead of needing another, but that is a different issue).

One issue with GeoTIFF pyramids is that there is no guarantee that the underlying tile grids will be uniform for a given resolution or zoom level. The renderers currently assume that there is a single tile grid. If you constructed a GeoTIFF pyramid where two GeoTIFFs at the same resolution had internal overviews or tile layouts that differed from one another, this would break the assumption by our renderers. I think that currently a GeoTIFF (or other source) pyramid is best represented by a layer group in OpenLayers (as @ahocevar did in the COG pyramid example).

That is true, but I'd compare this again with the WMTS use case, where the tile-grid defined in the capabilities is authoritative and the images in pyramid are expected to follow. So I guess in this case we should just assume the GeoTIFFs follow this external TileGrid. Maybe I should have made this more clear.
Regarding the context sharing: This definitely seems like a good idea and important to fix. I'm curious of how the API will look in the end. This solution definitely seems like the more general approach, and I hope it does not come with too many drawbacks.

A layer group constructor for working with tiled STAC assets could make sense

Yes, or at least with the information obtained by such a STAC Item.
Alright, shall I leave this issue open, or do we want to close it in favor of #12800 ?

@constantinius - I think it makes sense to have this open.
A pyramid of GeoTIFFs is a bit different than WMTS.  In the case of WMTS (or other well constrained tile specs), the tile grid (or tile matrix set) is defined in terms of tiles that are loaded by the client.  If I understand what you're interested in with a GeoTIFF pyramid, there are two levels of tile grid (or two levels of tile matrix sets).  The first tile grid determines which GeoTIFFs should be used for what resolution and coordinate range.  And then after reading the GeoTIFF metadata, there is a second tile grid (or tile matrix set) that defines the actual "tiles" that should be loaded.  Terminology is limiting me here, but I hope we're understanding this the same way.
My understanding is that your GeoTIFF pyramids are only defined by a tile grid that points to which GeoTIFF to load.  Then there are no guarantees at all about what the internal tiling scheme may be for any one of those individual GeoTIFFs.
I'm not saying that I don't see the value in an easy way to render a GeoTIFF (or other source type) pyramid.  Just saying that I think it might map better to a layer group rather than a single source given the current assumption made by our renderers.

@constantinius - I'd be curious to hear how things work with bigger pyramids now that #12965 is in.  You can try it out with the latest ol@dev release.  If things look ok performance-wise, the next step will be to add convenience around configuring the layer(s).

@tschaub Thanks for the update. I'll try it with our bigger pyramids!

@tschaub from our frontend guy I hear that the issue with the dropped context is now gone. Thanks a lot for the solution.
I will now close this issue, as an alternative is found.

Convenience added with #13312, by giving the WebGLTile layer a sources option. No need to create a layer group any more.


deps: update golang to 1.20.10

@katexochen I;m not expert on this, but I do see much files change in previous commit here https://github.com/confidential-containers/cloud-api-adaptor/commit/8d0c7a7608570fad0155bb8f0ccdd2d57a64870b

@huoqifeng we reduced the number of references we have of the version and read it from the versions.yaml file now, see https://github.com/confidential-containers/cloud-api-adaptor/pull/1423


in SD 1.5.1 bug(The size of tensor a (8) must match the size of tensor b (64) at non-singleton dimension 0)

Loading CLIP Interrogator 0.5.4...
load checkpoint from M:\SD\sdwebui\models\BLIP\model_base_caption_capfilt_large.pth
Loading CLIP model...
Loaded CLIP model and data in 8.05 seconds.
The size of tensor a (8) must match the size of tensor b (64) at non-singleton dimension 0

pip install clip-interrogator==0.6.0
pip install  transformers==4.26.1


Feature/mongodb

:x: Build TheIdServer 2.4.0-mongodb1-0041 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/8a673ad4a3 by @aguacongas)

:white_check_mark: Build TheIdServer 2.3.1-mongodb1-0044 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/8dadb59761 by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb1-0045 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/41d3a6cdaf by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb1-0046 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/f62c50d7a4 by @)

:x: Build TheIdServer 2.3.1-mongodb1-0047 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/fc78c3410a by @)

:x: Build TheIdServer 2.3.1-mongodb1-0048 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/8f82f4c2d3 by @)

:x: Build TheIdServer 2.4.0-mongodb1-0053 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/448c8d13bd by @aguacongas)

:x: Build TheIdServer 2.3.1-mongodb1-0056 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/e3c94dbef4 by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb.1+56.build.1246 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/e3c94dbef4 by @)

:x: Build TheIdServer 2.3.1-mongodb1-0059 failed (commit https://github.com/Aguafrommars/TheIdServer/commit/4545a50739 by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb1-0060 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/3afa5ffa71 by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb1-0061 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/6df73d9293 by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb1-0063 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/f3f705883f by @)

:white_check_mark: Build TheIdServer 2.3.1-mongodb.1+63.build.1253 completed (commit https://github.com/Aguafrommars/TheIdServer/commit/001ff9ced2 by @)


Figure out library packaging

At the moment the generated contracts assume that the predicates library can be imported as ./lib/predicates.ncl. That's... suboptimal. The problem is that we don't have an accepted general way of packaging Nickel libraries so that we could refer to them from the generated code. We should try to figure out a way of solving this packaging dilemma.
At the very least, we need to document that the generated contracts assume this filesystem layout.

For now, we decided on inlining the predicate library into the generated contracts. This is the most usable option currently available.


Support reload of max_control_line by updating connected clients

Make sure to update connected clients when max_control_line changes.
Signed-off-by: Derek Collison<EMAIL_ADDRESS>

Coverage increased (+0.03%) to 91.58% when pulling 007c98dc0378f8d1d8da9d5a78563b55dccfd2e7 on reload_mcl into 46a2661114e3158650f312cfeea8176420d43cfa on master.


eval: changes for ollama/local inference

Description
Changes for ollama/local inference.
Include additional in-scope models

/override "Red Hat Konflux / lightspeed-service-on-pull-request"
/lgtm
/approve

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.99%. Comparing base (110cb1a) to head (2cb31eb).
Report is 46 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1860      +/-   ##
==========================================
- Coverage   94.95%   93.99%   -0.96%
==========================================
  Files          61       62       +1
  Lines        2793     2830      +37
==========================================
+ Hits         2652     2660       +8
- Misses        141      170      +29

see 2 files with indirect coverage changes

/test e2e-ols-cluster-4-15

/test e2e-ols-cluster-4-15


Cache LoggerContext in log4j-slf4j-impl

When integrating Slf4J with Log4J, I make use of the log4j-slf4j-impl library.
Then, typically, when logging something this will be the classical approach used:
public class MyApp {
  private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(MyApp.class);
  public void doSomething() {
    log.info("Hello World!");
  }
}

Following the change of heart on slf4j#declared_static, I expected that the following is just as valid of a use case (which works, but does not perform well):
public class MyApp {
  public void doSomething(String ctx) {
    final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(ctx);
    log.info("Hello World!");
  }
}

Checking the integration code on Log4J side, it seems like there are appropriate caches on all expected places to deal with this, except in Log4jLoggerFactory.java#L53-L59 (invocation coming from AbstractLoggerAdapter.java#L46 ):
    @Override
    protected LoggerContext getContext() {
        final Class<?> anchor = LogManager.getFactory().isClassLoaderDependent()
                ? StackLocatorUtil.getCallerClass(Log4jLoggerFactory.class, CALLER_PREDICATE)
                : null;
        LOGGER.trace("Log4jLoggerFactory.getContext() found anchor {}", anchor);
        return anchor == null ? LogManager.getContext(false) : getContext(anchor);
    }

In particular, the StackLocatorUtil.getCallerClass call is what causes the performance degradation.
Would it be feasible to add a cache here as well, so the anchor is remembered between calls?

Is it alright if I create a suggested PR for this? I would really rather avoid the Apache "mailing list" stuff, though...
Worth noting that some of the other integrations on this project follow the same pattern, so would be nice to get a confirmation for this idea, or if Caching here is somehow against some other idea.

@blaghed, good news is, you don't need to deal with the mailing list stuff. We would be more than happy to assist you here.
Can you explain what kind of a cache you see others implement (references please) and log4j-slf4j-impl is missing? That is, to create a Logger, we need a LoggerContext. To locate that, we need to know the enclosing class of the getLogger() call, and this is where StackLocatorUtil.getCallerClass() comes in.

Following the change of heart on slf4j#declared_static...

IMHO, you're misinterpreting the docs. It says instance variables. Your example is not an instance variable, but a method variable. This is an instance variable:
public class MyApp {
    // Note the missing `static` modifier
    private final String foo = "bar";
}

Generally speaking, Loggers are not cheap constructs, they should ideally be reused and kept in a sufficiently long-living scope.

The idea behind instance loggers is a nice one: if an application server shares your library between applications, instance loggers should allow you to log messages to the correct application's log file.
Unfortunately many (most?) libraries don't use instance loggers and the list also includes libraries, which are meant to be shared between applications.
For example Hibernate's EntityManagerImpl and SessionFactoryImpl, which are objects specific to each application, use static loggers and send the logs of all applications to server's global logger context.
Since Hibernate is the JPA implementation in many application servers, system administrators are used to the fact that logs specific to a given application are scattered among multiple log files.
Therefore they have no reason to configure per-application logger contexts and might as well use a single logger context.
Note also that SLF4J's standard implementation (Logback) only supports a single logger context (see LoggerContext).
Remark: I chose Hibernate as an example. Pick any implementation of a Jakarta specification and you'll find similar problems.

Thanks for having a look.
After receiving your feedback and going again through the mentioned code, I can't really find a nice way to "cache" the LoggerContext in order to prevent the expensive StackWalker to always be called, at least not without some hacky approach.
Indeed, logback doesn't have this issue, so I should simply use that one instead.
Please feel free to close, and thank you for the explanation.

@blaghed,

After receiving your feedback and going again through the mentioned code, I can't really find a nice way to "cache" the LoggerContext in order to prevent the expensive StackWalker to always be called, at least not without some hacky approach. Indeed, logback doesn't have this issue, so I should simply use that one instead.

As @vy explained, the expensive StackWalker call is necessary to return a different Logger instance depending on the caller of LoggerFactory#getLogger(). If you eliminate the call (e.g. by switching to Logback) you lose all advantages that instance loggers have over static loggers.
The trick of using instance loggers is to manage the cost of Logger creation by assigning the logger to a field:
public class MyService {
  private final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(MyApp.class);
  public void doSomething() {
    log.info("Hello World!");
  }
}

This way if both application A and application B instantiate MyService, they could get different Logger instances, configured to log to different appenders.
The choice of using instance loggers implies however other limitations to your library. You can not use logging in classical "utility" classes:
public final class MyUtil {
    private static final Logger log = LoggerFactory.getLogger(MyUtil.class);

    public static String transform(String value) {
        log.debug("Transforming {}.", value);
    }

You need to either to pass Logger as parameter to the utility class:
public final class MyUtil {
    public static String transform(String value, Logger log) {
        log.debug("Transforming {}.", value);
    }

or replace static methods with instance methods:
public final class MyUtil {
    private final Logger log = LoggerFactory.getLogger(MyUtil.class);

    public String transform(String value) {
        log.debug("Transforming {}.", value);
    }

Remark: If you want to emulate Logback's behavior, you can also set the log4j2.contextSelector configuration property to org.apache.logging.log4j.core.selector.BasicContextSelector. There will be a single logger context for the entire application, so the caller lookup will not be necessary.


Clean up for building with JDK11

Hi folks, I tried to run mvn install with my JDK11 environment:
Maven home: /usr/local/Cellar/maven/3.5.2/libexec
Java version: 11.0.7, vendor: AdoptOpenJDK
Java home: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home
Default locale: en_CA, platform encoding: UTF-8
OS name: "mac os x", version: "10.13.6", arch: "x86_64", family: "mac"

and I got errors:
MavenReportException: Error while generating Javadoc:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/8/docs/api/ are in the unnamed module.
[ERROR] /Users/zhangmengxi/learning/saml-client/src/main/java/com/coveo/saml/SamlClient.java:699: warning: no @throws for com.coveo.saml.SamlException
[ERROR]   public void clearAdditionalSPKeys() throws SamlException {

and
MavenReportException: Error while generating Javadoc:
Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/8/docs/api/ are in the unnamed module.

Command line was: /Library/Java/JavaVirtualMachines/adoptopenjdk-11.jdk/Contents/Home/bin/javadoc @options @packages

My fix for them is on this PR~ Hope it helps~

Done in #131


Case-insensitive  input matching?

I can't seem to figure out how to do case-insensitive input matching. By this, I mean I would like a input of "michael" to show all possible inputs like "Michael". This doesn't have to be added now. I'd at least like to know where is best to make that change.

Just define your own type, conforming to FlowDataSource, and init RAMReel with instance of that type.

The new trie implementation (since 88a1da7b81edac564aafccf16ca3aaffca175fd4) example uses case-insensitive matching, but do be aware that this causes a visual clash between letter cases, since the typed text and suggestions are displayed on top of each other.

Hello, I'm wondering if there is a fix for the "visual clash"? Besides maybe hiding the collection view when the user enters a capital letter, has there been any development on the issue? Is there a way to adjust the datasource to match the case that the user-entered text is in?


Support Janome

Janome is a morphological analyzer purely written in Python.
We can analyze sentences after it runs pip install janome, which is very handy.

This is introduced in #57.


Task portus:assets:compile needs development gems

The task portus:assets:compile needs development gems.  This dependency make it hard to create a bundle for prod in a ci/cd system. because it needs to add all gems then portus:assets:compile and then remove dev and test gems again. In docker envs this is not possible in one step in two steps it doesn't make sense.
I don't know how to resolve it other then suggest adding annotate and other dependencies into production.

thanks for the update, I am not very happy with the current setup. Because as its the only way how ruby works, I can now workaround it.

See my comment.


TurtleBot3 Waffle Pi on ROS2 Foxy has a bound warning messages

ISSUE TEMPLATE ver. 0.4.0

Which TurtleBot3 platform do you use?

[ ] Waffle Pi

Which ROS is working with TurtleBot3?

[ ] ROS 2 Foxy Fitzroy

Which SBC(Single Board Computer) is working on TurtleBot3?

[ ] Raspberry Pi 4

Which OS you installed on SBC?

[ ] Ubuntu MATE 20.04

Which OS you installed on Remote PC?

[ ] Ubuntu 20.04 LTS (Focal Fossa)

Specify the software and firmware version(Can be found from Bringup messages)

Software version: [x.x.x]
Firmware version: V220624R1

Specify the commands or instructions to reproduce the issue.
$ ros2 launch turtlebot3_bringup robot.launch.py

Copy and Paste the error messages on terminal.

warning messages
$ ros2 launch turtlebot3_bringup robot.launch.py
[INFO] [launch]: All log files can be found below /home/ubuntu/.ros/log/2022-10-10-17-21-11-522006-TB3BG-R12V301-6757
[INFO] [launch]: Default logging verbosity is set to INFO
urdf_file_name : turtlebot3_waffle_pi.urdf
[INFO] [robot_state_publisher-1]: process started with pid [6777]
[INFO] [ld08_driver-2]: process started with pid [6779]
[INFO] [turtlebot3_ros-3]: process started with pid [6781]
[robot_state_publisher-1] Parsing robot urdf xml string.
[robot_state_publisher-1] Link base_link had 7 children
[robot_state_publisher-1] Link camera_link had 1 children
[robot_state_publisher-1] Link camera_rgb_frame had 1 children
[robot_state_publisher-1] Link camera_rgb_optical_frame had 0 children
[robot_state_publisher-1] Link caster_back_left_link had 0 children
[robot_state_publisher-1] Link caster_back_right_link had 0 children
[robot_state_publisher-1] Link imu_link had 0 children
[robot_state_publisher-1] Link base_scan had 0 children
[robot_state_publisher-1] Link wheel_left_link had 0 children
[robot_state_publisher-1] Link wheel_right_link had 0 children
[robot_state_publisher-1] [INFO] [1665393672.167454887] [robot_state_publisher]: got segment base_footprint
[turtlebot3_ros-3] [INFO] [1665393672.168661855] [turtlebot3_node]: Init TurtleBot3 Node Main
[turtlebot3_ros-3] [INFO] [1665393672.173350354] [turtlebot3_node]: Init DynamixelSDKWrapper
[robot_state_publisher-1] [INFO] [1665393672.172119821] [robot_state_publisher]: got segment base_link
[robot_state_publisher-1] [INFO] [1665393672.172255028] [robot_state_publisher]: got segment base_scan
[robot_state_publisher-1] [INFO] [1665393672.172298901] [robot_state_publisher]: got segment camera_link
[robot_state_publisher-1] [INFO] [1665393672.172332055] [robot_state_publisher]: got segment camera_rgb_frame
[robot_state_publisher-1] [INFO] [1665393672.172362765] [robot_state_publisher]: got segment camera_rgb_optical_frame
[robot_state_publisher-1] [INFO] [1665393672.172391310] [robot_state_publisher]: got segment caster_back_left_link
[robot_state_publisher-1] [INFO] [1665393672.172420207] [robot_state_publisher]: got segment caster_back_right_link
[robot_state_publisher-1] [INFO] [1665393672.172448214] [robot_state_publisher]: got segment imu_link
[robot_state_publisher-1] [INFO] [1665393672.172476130] [robot_state_publisher]: got segment wheel_left_link
[robot_state_publisher-1] [INFO] [1665393672.172503804] [robot_state_publisher]: got segment wheel_right_link
[turtlebot3_ros-3] [INFO] [1665393672.179742243] [DynamixelSDKWrapper]: Succeeded to open the port(/dev/ttyACM0)!
[turtlebot3_ros-3] [INFO] [1665393672.189502337] [DynamixelSDKWrapper]: Succeeded to change the baudrate!
[turtlebot3_ros-3] [INFO] [1665393672.227007385] [turtlebot3_node]: Start Calibration of Gyro
[ld08_driver-2] /dev/ttyUSB0    CP2102 USB to UART Bridge Controller
[ld08_driver-2] /dev/ttyACM0    OpenCR Virtual ComPort in FS Mode
[ld08_driver-2] FOUND LiDAR_
[ld08_driver-2] LiDAR_ started successfully
[turtlebot3_ros-3] [INFO] [1665393677.227312229] [turtlebot3_node]: Calibration End
[turtlebot3_ros-3] [INFO] [1665393677.227468786] [turtlebot3_node]: Add Motors
[turtlebot3_ros-3] [INFO] [1665393677.227821740] [turtlebot3_node]: Add Wheels
[turtlebot3_ros-3] [INFO] [1665393677.228095128] [turtlebot3_node]: Add Sensors
[turtlebot3_ros-3] [INFO] [1665393677.232691244] [turtlebot3_node]: Succeeded to create battery state publisher
[turtlebot3_ros-3] [INFO] [1665393677.241519674] [turtlebot3_node]: Succeeded to create imu publisher
[turtlebot3_ros-3] [INFO] [1665393677.246923828] [turtlebot3_node]: Succeeded to create sensor state publisher
[turtlebot3_ros-3] [INFO] [1665393677.253428737] [turtlebot3_node]: Succeeded to create joint state publisher
[turtlebot3_ros-3] [INFO] [1665393677.253560155] [turtlebot3_node]: Add Devices
[turtlebot3_ros-3] [INFO] [1665393677.253601585] [turtlebot3_node]: Succeeded to create motor power server
[turtlebot3_ros-3] [INFO] [1665393677.259988867] [turtlebot3_node]: Succeeded to create reset server
[turtlebot3_ros-3] [INFO] [1665393677.266893361] [turtlebot3_node]: Succeeded to create sound server
[turtlebot3_ros-3] [INFO] [1665393677.274864010] [turtlebot3_node]: Run!
[turtlebot3_ros-3] [INFO] [1665393677.679709379] [diff_drive_controller]: Init Odometry
[turtlebot3_ros-3] [INFO] [1665393677.753683101] [diff_drive_controller]: Run!
[turtlebot3_ros-3] [WARN] [1665393678.010527694] []: Messages of type 0 arrived closer (34000000) than the lower bound you provided (75000000) (will print only once)

firmware version
/update.sh $OPENCR_PORT $OPENCR_MODEL.opencr
aarch64
arm
OpenCR Update Start..
opencr_ld_shell ver 1.0.0
opencr_ld_main
[  ] file name   	: waffle.opencr
[  ] file size   	: 132 KB
[  ] fw_name     	: waffle
[  ] fw_ver      	: V220624R1
[OK] Open port   	: /dev/ttyACM0
[  ]
[  ] Board Name  	: OpenCR R1.0
[  ] Board Ver   	: 0x17020800
[  ] Board Rev   	: 0x00000000
[OK] flash_erase 	: 1.07s
[OK] flash_write 	: 1.31s
[OK] CRC Check   	: D28244 D28244 , 0.004000 sec
[OK] Download
[OK] jump_to_fw

Please describe the issue in detail.
I found the warning messages in the bringup part. When it bringup,sometimes the motor will turn uncontrollably. And this problem also occurs in the  teleop_keyboard.

@ROBOTIS-Will @robotpilot

@EndlessLoops Apologies for the delayed response. We have assembled a TF team to address TurtleBot3 issues and are actively working on resolutions. Please note that we do not support EOL (End-of-Life) ROS versions; our support currently extends to Noetic and Humble versions. We kindly ask that you try again with the latest version. If the same issue arises, please feel free to resubmit it, and we will address it promptly.

@EndlessLoops Apologies for the delayed response. We have assembled a TF team to address TurtleBot3 issues and are actively working on resolutions. Please note that we do not support EOL (End-of-Life) ROS versions; our support currently extends to Noetic and Humble versions. We kindly ask that you try again with the latest version. If the same issue arises, please feel free to resubmit it, and we will address it promptly.

How to download the latest version firmware? In here？

@sunghowoo


chrome apps or webpages shortcuts can be added in groups but cannot open them

chrome apps or webpages shortcuts can be added in groups but cannot open them

y e s

@justiceslava @monkeykingrana
Related to #80 and a bunch of other issues.
Please check out the build here which has implemented a bunch of these fixes.
https://github.com/PikeNote/taskbar-groups-pike-beta/releases


Should we consider using mypy for type checking?

http://blog.zulip.org/2016/10/13/static-types-in-python-oh-mypy/

This looks really interesting!


gpm: patch to fix w/musl, good for general use

Two of the patches fix same issues we fix for glibc,
one of which this replaces (the other touches same
code but on the not-glibc path).

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Fits CONTRIBUTING.md.

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: gpm
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on x86_64-linux (full log)
Attempted: gpm
Partial log (click to expand)
shrinking /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin/display-buttons
shrinking /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/lib/libgpm.so.2.1.0
shrinking /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/sbin/gpm
gzipping man pages under /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/share/man/
strip is /nix/store/90vmpr41dzsx350k5argycaf693hnl1l-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/lib  /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin  /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/sbin
patching script interpreter paths in /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7
checking for references to /build in /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7...
moving /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/sbin/* to /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin
/nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7

Success on aarch64-linux (full log)
Attempted: gpm
Partial log (click to expand)
shrinking /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin/hltest
shrinking /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin/mev
shrinking /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/lib/libgpm.so.2.1.0
gzipping man pages under /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/share/man/
strip is /nix/store/7iyn7gn33i7xxjgmwf25k20246y6nd9d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/lib  /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin  /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/sbin
patching script interpreter paths in /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7
checking for references to /build in /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7...
moving /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/sbin/* to /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin
/nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7

No attempt on x86_64-darwin (full log)
The following builds were skipped because they don't evaluate on x86_64-darwin: gpm
Partial log (click to expand)

a) For `nixos-rebuild` you can set
  { nixpkgs.config.allowUnsupportedSystem = true; }
in configuration.nix to override this.

b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
  { allowUnsupportedSystem = true; }
to ~/.config/nixpkgs/config.nix.

Success on aarch64-linux (full log)
Attempted: gpm
Partial log (click to expand)
shrinking /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin/hltest
shrinking /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin/mev
shrinking /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/lib/libgpm.so.2.1.0
gzipping man pages under /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/share/man/
strip is /nix/store/7iyn7gn33i7xxjgmwf25k20246y6nd9d-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/lib  /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin  /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/sbin
patching script interpreter paths in /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7
checking for references to /build in /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7...
moving /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/sbin/* to /nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7/bin
/nix/store/4n692c26rlz1yf6bplxq2n2qwr4yskjg-gpm-1.20.7

Success on x86_64-linux (full log)
Attempted: gpm
Partial log (click to expand)
shrinking /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin/get-versions
shrinking /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin/disable-paste
shrinking /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/sbin/gpm
gzipping man pages under /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/share/man/
strip is /nix/store/90vmpr41dzsx350k5argycaf693hnl1l-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/lib  /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin  /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/sbin
patching script interpreter paths in /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7
checking for references to /build in /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7...
moving /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/sbin/* to /nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7/bin
/nix/store/kvx6yia7i7jz8cf8v7ls5g2pcazqyiwr-gpm-1.20.7


IDs for automated E2E tests

Description
In order to simplify the E2E tests, we should have some useful IDs inside ionic-showcase. This PR: https://github.com/aerogear/test-suite/pull/17 is an example of how this IDs could help the QE team write E2E tests.

Checklist

[x] npm test passes
[x] npm run build works
[x] tests are included
[x] documentation is changed or added

👀


Research graphing library to use

The color correction UI includes a histogram of the RGB layer. Before we do the graph, we should do some brief research on a graphing library.

I did some browsing, reading and talked to @jisantuc , and here's what I've come up with:
Options
There are three options that seem solid:

nvd3: We've used this a few times before, it has a nice Angular wrapper and good documentation with examples. The main downside is that we lose some control, but it's easy to get to about 80% of what we need, and the remaining 20% may take some fiddling.
raw d3: We've also done this before and it's basically the inverse of nvd3; we have to write everything ourselves but we have total control.
chart.js: We haven't used this before but it seems to have an actively maintained Angular wrapper and is supposedly fast because it uses Canvas (but we might give up something in terms of styling).

Our current use-case is a histogram for color correction; neither nvd3 nor chart.js has demos for histograms, but it may be possible to adapt their bar charts or line charts to serve as a histogram.
Conclusion
For the moment, continuing to use nvd3 seems like the best option since we have experience with it and it should save us a lot of time. I'm going to start working on #625 , with a focus on implementing the histogram first to test out nvd3; if I run into major blockers then I'll evaluate chart.js more closely and potentially fall back to raw d3 if necessary.

This makes sense.
One thing to add -- we are not going to be computing the histogram on the front-end, it's just a line-graph. There will be an endpoint that returns the values to construct it.

Cool, that's what I assumed, computing histograms from images client-side sounded hard.

Follow-up to this: I used nvd3 and it is working fine so far.


Make disabled an AliasProperty

This allows rembembering the previous disabled state, which is useful
when using disabled at multiple levels.
Before that, disabling then un-disabling a widget, would un-disable all
the child widgets, which is a surprising and most of the time undesired
behavior.
Potential downsides are:

you can't change the disabled state of a children of a disabled
widget anymore, which may or may not be desired.
the property isn't identified as a boolean anymore, which makes the
inspector less useful.

I think it can be considered a bugfix, but it's arguably a slight api change, if so, the versionchanged tag should be updated accordingly.

Also, despite the force_dispatch option, it seems disabling an already disabled (through parent widget) widget doesn't work.
A test program can be found here.
https://gist.github.com/tshirtman/3db1281dc945f53a9ca9513c5252ad7f
from kivy.app import App
from kivy.lang import Builder

KV = '''
BoxLayout:
    BoxLayout:
        orientation: 'vertical'
        Button:
            text: 'toggle fl'
            on_press: fl.disabled = not fl.disabled
        Button:
            text: 'toggle bl'
            on_press: bl.disabled = not bl.disabled
        Button:
            text: 'toggle b1'
            on_press: b1.disabled = not b1.disabled
        Button:
            text: 'toggle b2'
            on_press: b2.disabled = not b2.disabled
    FloatLayout:
        id: fl
        BoxLayout:
            id: bl
            pos_hint: {'center': (.5, .5)}
            size_hint: .5, .5
            Button:
                id: b1
            Button:
                id: b2
'''

class Test(App):
    def build(self):
        return Builder.load_string(KV)

if __name__ == '__main__':
Test().run()

It seems logic to not be able to change the disable state of a children if a parent is disabled.
Second is not really an issue imo.
My only feedback: can't _disabled_count be a simple python attribute, not a kivy property? Every new property increase the time to create the widget so...

Otherwise, OK to merge after the change


When is onTokenRefresh triggered(javascript)

Hey,
I've read different info everywhere. Ranging from "it's not even working yet" through "it's under way" to "yeah, it's working".
My question would be, that if it's really working, when is it triggered? In a webapp I can't get it triggered, no matter how I try. I have to test it somehow.
Also, is there a way to get what the previous token was? I have to know what's the token that's getting replaced.
On other platforms they suggest an app reinstall. For me(as it's a webapp) it won't happen.
Thanks,
Richie

onTokenRefresh is triggered when there is the generation of a new token. This occurs if this is the first time the app is running or if an existing token has been invalidated by FCM likely due to some type of security risk. There is currently no way to trigger this unless you clear your application's data and run it again in which case you will get a brand new token.
There is no way to get the token previously assigned to your application, you will have to maintain that yourself.

Actually, @Richie81 is right about onTokenRefresh not working. It is not implemented yet. You can see it here.
If you look at the code, you can see that when you call onTokenRefresh, your callback function gets converted to an observer and gets assigned to tokenRefreshObserver, but that observer is never triggered (yet).


JS: cherry pick #946 to rc/1.20

#946 did not make it into 1.20 for some reason. This PR cherry-picks the commits, and adds the non-semantic fixup commits of #1019.

Shouldn't be needed if https://github.com/Semmle/ql/pull/1032 works out.

Should no longer be needed.


Added a bug for Password Encryption

I have reported a bug for password encryption

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 24
- Added 5

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 24
- Added 6

See the complete overview on Codacy

Please report it under issues section and not under PR

Please report it under issues section and not under PR


feat(@schematics/angular): update Angular and TS versions

The CLI legacy e2e tests where failing because Angular 7.0.0-rc.0 embed
https://github.com/angular/angular/pull/26151/, and TS version 3.0 wasn't
right for this. This commit fix this error as reported in #12423, but isn't enought
to support TS 3.1 (see #12416 for more commits on this).
Close #12413

Thanks for chipping in - as you saw we already started the update (we hoped to release on Friday along with the framework but ran out of time.)


Remove WeakMap/WeakSet#clear method

changes:
// lib.es6.d.ts and lib.core.es6.d.ts
// also WeakSet
 interface WeakMap<K, V> {
-    clear(): void;
     delete(key: K): boolean;
     get(key: K): V;
     has(key: K): boolean;
     set(key: K, value?: V): WeakMap<K, V>;
     [Symbol.toStringTag]: "WeakMap";
 }

https://tc39.github.io/ecma262/#sec-weakmap-constructor
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap
https://bugzilla.mozilla.org/show_bug.cgi?id=1101817

What runtime environments have this implemented?
I did a quick test against the latest Chrome, Node.js, and Edge and none of them had WeakSet.prototype.clear defined as far as I could tell.

@LPGhatguy it needs to be removed. it was part of the spec at an earlier draft but has since been removed.

Thanks @falsandtru!


fix: make framework work with newest Sveltekit Version

fixes #186
things to fix:

[x] templates
[ ] cypress tests

cypress tests

As discussed it is may be worth migrating it to Playwright. Do you think it's good to do it in this PR, or get this merged and do it in a follow-up?


Add ack 2.14 to garage

Duplicate of #495?

Not quite; this issue just requires that ack 2.14 be added to the garage, but the other requires a fix to the timings.pl tool.  I will post examples that demonstrate the problem in the other issue!

Done.


Update azureClientSample.c

When creating the MQTT client the third parameter of mosquitto_new() is later passed to all MQTT callback functions. In this case it should be a pointer to the azure client.
In this example the third parameter is wrong!
It should be
mqqtClient = mosquitto_new(azureClientId, true, azureClient);
instead of
mqqtClient = mosquitto_new(azureClientId, true, &azureClient);
Uwe

/azp run c - client - ci


Line don't appear

Hi,
I already read other issue but without succes
I use ReactJs, I make the npm install and here is my code
let chart = new Chart(myChartRef, {
                type: "line",
                data: {
                    labels: date,
                    datasets: [{ label: measure, data: quality, borderColor: "blue", showLine: true, pointRadius: 10, pointHoverRadius: 15 }]
                },
                options: {
                    events: ['click'],
                    responsive: true,
                    scales: {
                        xAxes: [{
                            type: 'time',
                            distribution: 'series'
                        }]
                    },
                    tooltips: {
                        mode: "index",
                        intersect: true
                    },
                    plugins: {
                        annotation: {
                            annotations: [{
                                type: 'line',
                                mode: 'horizontal',
                                scaleID: 'y-axis-0',
                                value: 62,
                                borderColor: 'rgb(255, 192, 192)',
                                borderWidth: 4,
                            }]
                        }
                    }
                }
            });

And it's in the console

Try to put your annotation settings right under options, Like this: https://codepen.io/jordanwillis/pen/qrXJLW
Somehow it doesn't work with options.plugins.annotation

I couldn't get any line to appear either, until I added the annotation element as a child of options.
options: {
annotation: {
annotations: [
{
type: 'line',
mode: 'vertical',
scaleID: 'x-axis-0',
value: payday.toString(),
borderColor: 'red',
borderWidth: 2,
}
]
}
}

Lines don't appear with scatter type of ChartJS. It works well with line type but when I'm doing the same for scatter type, it does not work. Any clues on that ?
Thank

Mee too having the same,
<Line
width={200}
height={300}
data = {{
labels: labels,
datasets: [{
label: 'Voltage Fluctuation',
data: data,
borderWidth: 1
}]
}}
options={{
maintainAspectRatio: false,
legend: { display: false },
scales: {
xAxes: [{
type: 'time',
time: {
unit: 'minute',
displayFormats: {
hour: 'HH:mm:ss'
}
}
}]
},
annotation: {
annotations: [{
type: 'line',
mode: 'horizontal',
scaleID: 'y-axis-0',
value: 233,
borderColor: 'rgb(75, 192, 192)',
borderWidth: 4,
label: {
enabled: false,
content: 'Test label'
}
}]
}
}}
/>