Grid sort not working on GridColumn that is not mapped to any variable in the backing object

Issue Details
Type of Issue  (check one with "X")
[ ] Bug Report => Please search GitHub for a similar issue or PR before submitting
[ ] Feature Request => Please ensure feature is not already in progress
[ ] Support Request => Please do not submit support requests here, instead see: https://discourse.oss.antheminc.com/

Current Behavior
Server Side Pagination is On and Sortable is enabled, When we try to sort the GridColumn that is unmapped it throws a ClassCastException
Expected Behavior
Should be able to sort the values without error
How to Reproduce the Issue
Steps to Reproduce
On-grid enable Server Side Pagination, declare a GridColumn without mapping it to any variable in the backing object and enable sortable, Click Sort on the Grid, Now It throws ClassCastException and Sorting doesn't happen
Code Snippet
@GridColumn(sortable = true,sortAs=SortAs.NUMBER)
private Double penaltyDouble;
Environment Details

Nimbus Version:

Browser:

After discussing this with the team, we have asked that either an aggregate query or mongo view be created to support this scenario. Serverside pagination relies on sorting to be done in the database layer, which is why this is not supported.  If we have to support this by adding collection sorting support on the server, we'll revisit it in a new feature.


Rework network-tools to

have a single entry point
print help and usage examples for every function
be available both locally and via must-gather
add local-scripts folder for scripts that should be available
locally, but not vis must-gather
move a set of tools for networking testing to test-networking
folder
create scripts folder for all the other scripts
only included tested scripts to be available via network-tools
command, other scripts like sriov_network_info and ovn_cleanConntrack
still can be called manually via their path. That is done to make sure
support/customers don't run some dangerous scripts by accident.
They can become a part of network-tools command when we clarify usage
scenarios.

Add script template to make sure new scripts match general requirements.
Add docs-generating script that updates the second part of user.md
based on scripts help output.
Signed-off-by: Nadia Pinaeva<EMAIL_ADDRESS>

/assign @bpickard22

This PR mostly needs reviewing updated docs and testing commands as explained in the docs

/assign martinkennelly

Awesome work! This should open the floodgates hopefully ;)
With OVN-K as the network plugin:
all good
ovn-nic-firmware:
works good
ovn-pod-to-pod:
works good
ovn-pod-to-svc:
works good

@martinkennelly thank a lot for reviewing this!
node info really wasn't collected, should be fixed now (I also added error log to network-tools instead of just exit 1 to make such errors more visible)

/lgtm


NoneType object has no attribute 'text'

Traceback (most recent call last):
File "scrape.py", line 155, in
obj.save_specification_to_file()
File "scrape.py", line 131, in save_specification_to_file
datum = self.crawl_phones_models_specification(value, brand[0])
File "scrape.py", line 77, in crawl_phones_models_specification
model_name = soup.find(class_='specs-phone-name-title').text
AttributeError: 'NoneType' object has no attribute 'text'

I am getting the same error

found any solution.?


Remove class parameters use

Also removed MailChimp support since the mailer doesn't exist anymore.

Thank you!


Make children accessor readonly

The tree doesn't mutate the children in the data, so the accessor can return a readonly array.

I'm not accustomed to adding the readonly flag. Is there any reason for this other than correctness and safety. Is the absence of this causing errors/annoyances in your code?

Yes, it does cause an error... our Folder type has an entries: readonly (File | Folder)[] property that we return using the childrenAccessor function (in which we do a type check in order to return null for a File), so we have to use an (unsafe) type cast to make it work without this patch.
The modifier is already present on the data property, for example, so adding it here as well keeps things consistent.


HttpTrigger Model Binding gives null v1.17.2

Description
I am getting a null when binding using [HttpTrigger(...)] MyModel model
However, if I use [HttpTrigger(...)] HttpRequest request  I can deserialize the body in to my model
Using a custom type from Docs
Steps to reproduce

Create a Functions Worke App with a HttpTrigger Function using 1.17.2 SDK
Create a model and use as an argument type with the trigger attribute
Call the function over http
Breakpoint shows that the model is null

public sealed record MyModel(int Id);

[Function(nameof(IncomingAsync))]
public static async Task<IActionResult> IncomingAsync(
    [HttpTrigger(
        AuthorizationLevel.Anonymous,
        WebRequestMethods.Http.Post,
        Route = ROUTES.INCOMING)] MyModel model)
{
...
}

Hi @MrAntix, does the following work?
public sealed record MyModel(int Id);

[Function(nameof(IncomingAsync))]
public static async Task<IActionResult> IncomingAsync(
    [HttpTrigger(
        AuthorizationLevel.Anonymous,
        WebRequestMethods.Http.Post,
        Route = ROUTES.INCOMING)] HttpRequest req, [FromBody] MyModel model)
{
...
}

Note the use of the [FromBody] attribute - there are additional requirements outlined here for using this attribute.

Hi @satvu
No that's null too.
See here https://github.com/MrAntix/sandbox-http-trigger-custom-type

Closing as answered.

Hi @satvu
I didn't ask a question about how I could do this another way, I raised a bug.
Closing this won't get it fixed.
The docs say
"The trigger input type is declared as one of the following types:"
"A custom type | When the body of the request is JSON, the runtime will try to parse it to set the object properties."

Please review


Add missing execution resources to fetched traces

closes https://github.com/NethermindEth/juno/issues/2218

LGTM, I'll approve when the tests are fixed


Add sonarqube plugin

Change description
Extract sonarqube addition from #56 PR
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

yep. lesser evil here. few lines of code. functional coming next with an actual cherry-pick from top of commits


Enhance test for database upgrade process

As proposed in https://github.com/k9mail/k-9/pull/2158#issuecomment-277963119, I've extended the test for the database upgrade process, which was introduced in #2158. There, the test was restricted on the existence of tables, indexes and triggers. Now, the test also checks the structure of these entities using the sql column in sqlite_master.
Fortunately, I've only found one issue with this new test, and that is minor. It concerns the column notify_class of table folders. Using the upgrade process, this column is created with default 'INHERITED'. However, when the database is created from scratch, the default is missing.
Therefore, I've added the default value to dbCreateDatabaseFromScratch to fix the test.
However, this approach show also the lack of current tests: They test only if upgrading from a virtual v29 database comes to the same result like creating a new one from scratch (see #2158). But, additionally, a respective test would be nice for every release (not only v29)! Because you have to note, that my solution for the notify_class column only applies to future new installations. People with a former new installation of a release with database v50 and above will still not have the correct default value. Nevertheless, I've chosen that approach, because the default should not be that important and we would have to re-create the whole table in order to change it. But the message is, that there may be much more problems of this type. They can only be detected with a test of the upgrade-paths of every release! However, that's not that easy, but I have some ideas how to realize this. I will write them down in a new issue in the next days. But for now, this pull request is good enhancement :smile:

I don't think we even did upgrades before v29 - we may have simply required re-creation - I would not in general spend too long worrying about them.
What I think we should do first is stop destroying databases when the upgrade fails and instead persuade users to raise bugs with the error. Then we can fix them and they can upgrade, saving their data.

Sorry, I was not talking about versions before v29. I was talking about the releases between v29 and now!
However, the other part sounds good, but I'm too new to assess this ;-)

I've just had a look at the code and we don't need to worry about the change in default for notify_class. We always provide one when creating a folder anyway.

Thanks!


Hand joint positions do not regain tracking after temporary loss of hand tracking.

Describe the bug
Occasionally when hand tracking is lost, the joint positions for that hand are not discarded nor subsequently updated when hand tracking is regained.
When tracking of the hand is regained, an additional persistent hand mesh that does not disappear when tracking is lost is rendered on top of the hand in question's last known pose. In the video attached under Screenshots, you can see there are a total of three hand meshes being rendered after the bug occurs. All hand meshes track their hands correctly before and after the bug occurs, but the joint positions are not updated correctly after the bug occurs.
I am not able to find a more reliable method of repoducing this bug other than repeatedly moving hands out of the headset's FOV, but it occurs regularly while testing my apps. The tracking does not resume normal function until the app is restarted.
To reproduce
Steps to reproduce the behavior:
Project Setup:

Create new Unity project and import MRTK.
Set MixedRealityToolkit profile to DefaultXRSDKConfigurationProfile.
Edit: Enable XR Plug-in mangament in project settings
Add gameobject with mesh and Orbital solver.

In app reproduction of bug:

Move hand out of tracking view of the headset, then back in.

Expected behavior
No duplicate hand meshes are displayed, and joint tracking resumes on physical hand instead of the old hand joint data
Screenshots
Shows expected behaviour the first time hand lost and regained, Followed by faulty behaviour the second time.
https://youtu.be/-8yrjCxPk3k
Your setup

Unity 2019.4.17f1
MRTK v2.5.3
Also observed using MRTK v2.4.0 and Unity 2019.4.4f1

Target platform

HoloLens 2

Hey @elbuhofantasma, can you repro and see if this happens in legacy vs just XR SDK?

Hey @elbuhofantasma, can you repro and see if this happens in legacy vs just XR SDK?

I seem to have the same problem. While using my HoloLens2 app, more hands get stuck and freeze in the scene.

I'm using Unity 2020.1.10f1 (but same happens in Unity 2020.2.2f1) and using MRTK 2.5.3,
Any ideas how to fix this?

Same problem here, but it came up only in the last few weeks. I think the chance for "ghost hands" increased with cpu load, but I can't pin any special cause.

This sounds related to https://github.com/microsoft/MixedRealityToolkit-Unity/issues/9165

The stuck hand tracking should be fixed via #9890 in the upcoming 2.7.0 release. Please re-open if you're still able to repro on 2.7.0.


PubChemPy stopped working today

Hi there,
I have been using PubChemPy for a while and it's been working great until today when commands that used to work don't anymore. For example, the simple command compounds = pcp.get_compounds('methane', 'name', record_type='3d') gives the error URLError:

<urlopen error [Errno 8] nodename nor servname provided, or not known>

I suspect there's been some changes to PubChem itself?

Things look OK for me. The error message suggests network connectivity issues - it could have been a temporary problem with the PubChem servers or it may be a problem with your local network.
Are you able to open this link:
https://pubchem.ncbi.nlm.nih.gov/rest/pug/compound/name/methane/JSON?record_type=3d

Thanks for replying quickly! So I just tried and I cannot. Do you know how I can fix this?

I think you will need to contact the pubchem support team: https://pubchemdocs.ncbi.nlm.nih.gov/contact


Fallback to Layout-Type-Alias when unknown LayoutRenderer

Instead of having to do this:
<target name="hello">
    <layout type="mylayout" />
</target>

Then it could be nice one could also do this:
<target name="hello" layout="${mylayout}" />

Right now one can do this:
<variable name="mylayout2">
      <layout type="mylayout" />
</variable>
<target name="hello" layout="${mylayout2}" />

Maybe skip support for option-handling when doing the short-hand type-alias-syntax.

I think this is available on NLog. I am already using it and its working fine.
<target xsi:type="File" name="file" fileName="${basedir}\logs\${shortdate}.log"
			layout="${loggerLayout}" />

My packages:
NLog: 5.0.1
NLog.Web.AspNetCore: 5.1.0

Yes I know the work-around (using config-variable) is working. My goal is to do it without the work-around:
<target xsi:type="File" name="file" fileName="${basedir}\logs\${shortdate}.log" layout="${jsonlayout:includeeventproperties=true}" />


Runtime merge proposal

Problem Statement
The Kata Containers project is a merge of 2 hardware virtualization based runtimes: Intel’s Clear Containers and Hyper’s runV. As of Feb 13th, 2018, the two runtimes live alongside under the Kata Containers runtime github repository. Having two codebases is confusing the community and impeding potential contributors to really commit to the project.
Although each runtime has its strengths and gaps, the next step for the Kata Containers project should be about combining the two runtimes into a single code base, and merging each runtime feature set into a larger one.
To reach that goal, these two approaches are proposed:

Have the community pick one runtime and then work on filling the feature gaps.
Find a technical way to pick the best components from each runtime and merge them into a single code base.

During the Feb 5th, 2018 Kata Containers Architecture meeting, the community decided to initially go with the first solution, i.e. picking one runtime over the other.
We believe this solution is a little too aggressive and may underestimate the engineering costs of filling the technical gaps of either runtime.
Goals
The goal of this proposal is to show that the second approach is viable and can be implemented. We think by mixing the best of the two runtime components we can accelerate the runtime merging process and reach the Kata Containers 1.0 release sooner.
This proposal aims at:

Building a flexible and extensible runtime based on a clean core framework
Providing a smooth upgrade path for both runV and Clear Containers users, by keeping all features from both runtimes early in the merge process
Accelerating the runtime merge process
Providing a base for efficient CRI implementations, for both OCI based CRI shims and native ones

High Level Architecture
By picking the virtcontainers framework that Clear Containers already leverages, the runV hypervisor drivers and the runV runtime API, we believe that the merged runtime will fulfill the [Kata Containers runtime requirements] (https://github.com/kata-containers/runtime/issues/31).
The Kata Containers runtime would then be based on the following components:

The virtcontainers library would be the core Kata Containers runtime framework.
In order to have a real multi-hypervisor architecture, the runV hypervisor drivers for Xen, libvirt and kvm-tool would be added to the virtcontainers library.
The virtcontainers API would be improved and extended in order to support the current runV and Frakti specific requirements.
runV's virtual machine factory.

cc @sboeuf @jodh-intel @egernst @gnawux @laijs @bergwolf @jessfraz @WeiZhang555 @tallclair

Thank you for submitting the proposal  @sameo :)

Add some basic goal of the merging proposal:

A well organized and extensible architecture;
A high efficient workflow, especially for OCI and CRI;
Smooth upgrade for existing customers of both runV and clear-containers;
Keeps the features from both runV and clear-containers;
Accelerate the runtime merging process.

@gnawux Done, please let me know if that looks fine to you.

Thanks @sameo!
lgtm

cc @jon

This seems sane to me!

and the runV runtime API
I didn't see that listed below, or is that the same thing as runV's virtual machine factory.?

virtcontainers API would be improved and extended
Would it be possible to list the specific places it falls short here? Or would that require a more involved analysis?

By picking the virtcontainers framework
I'd be interested in seeing a bit more justification for this, even if it's just one sentence. What's the alternative, and why is this preferred?

virtcontainers API would be improved and extended

Would it be possible to list the specific places it falls short here? Or would that require a more involved analysis?

It needs some further analysis. We need to compare the current virtcontainers API with PR #32 to fully where the gaps are, if any.

Thanks for clarifying. LGTM.

What about multi-architecture support? The above summary seems to only mention multi-hypervisor support. The runV hypervisor driver is both hypervisor-agonistic and architecture-agonistic. It has support for ARM64, AMD64, PPC64 and s390x. Are we going to only keep the hypervisor-agonistic part of it?

and the runV runtime API
I didn't see that listed below, or is that the same thing as runV's virtual machine factory.?
@tallclair Not just the VM factory. The entire set of API is being discussed here https://github.com/kata-containers/runtime/pull/32

and the runV runtime API
I didn't see that listed below, or is that the same thing as runV's virtual machine factory.?

@tallclair Not just the VM factory. The entire set of API is being discussed here https://github.com/kata-containers/runtime/pull/32

This LGTM, I like this idea.
One thing, currently virtcontainers resides under https://github.com/containers organization, is it possible to move it back under https://github.com/kata-containers ? Or we can't manage codes and it also tear kata-containers down to too many pieces. @sameo

@sameo one nit about the architecture graph -- the agent/shim/proxy are outside of virtcontainers and shim/proxy are not used by frakti.

@bergwolf

Are we going to only keep the hypervisor-agonistic part of it?

Certainly not. It has to be architecture agnostic as well, and as an example we recently merged ARM support for QEMU into the virtcontainers. I'll add a mention to it to the proposal, thanks.

@WeiZhang555

One thing, currently virtcontainers resides under https://github.com/containers organization, is it possible to move it back under https://github.com/kata-containers ? Or we can't manage codes and it also tear kata-containers down to too many pieces.

We initially put virtcontainers under the github.com/containers organization to make it very clear that it's neither vendor nor Clear Container specific. If we decide to go and base the Kata Containers runtime off virtcontainers, it would make perfect sense to move it under github.com/kata-containers/runtime/ as a runtime package. Or maybe as a separate repo, but that would be more complex.
I will send a PR for that purpose tomorrow or early next week, I first need to know what was the output of yesterday's discussion on this proposal.
I'd like to move virtcontainers

@bergwolf

the agent/shim/proxy are outside of virtcontainers and shim/proxy are not used by frakti.

Right, what I meant with this diagram is to show that virtcontainers provide support for managing different kind of proxies, shims and agents. Not that the proxies and shims implementations are done inside virtcontainers. Not sure how to make that clearer with such high level diagram though...

@sameo

Not sure how to make that clearer with such high level diagram though...

How about renaming virtcontainers to kata-runtime, and kata-runtime in the graph to kata-cli? Then we can link shim/proxy under kata-cli and agent under kata-runtime. Current separation of kata-runtime and virtcontainers makes it unclear because virtcontainers essentially is part of kata-runtime.

@sameo I've drawn a sample architecture graph based on the above suggestion. Please feel free to modify or use it directly. The components in orange are kata components.

@sameo @bergwolf can we add a bit more detail on the features provided in the VM templating (VM Factory) component. The rest of the items in the architecture are mostly self explanatory.

Since we have the initial requirements pr merged and virtcontainers is now merged, can this issue be closed?
I'll open a new issue to detail vm templating.


[Snyk] Upgrade com.fasterxml.jackson.core:jackson-annotations from 2.15.2 to 2.16.1

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade com.fasterxml.jackson.core:jackson-annotations from 2.15.2 to 2.16.1.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 5 versions ahead of your current version.
The recommended version was released 3 months ago, on 2023-12-24.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Updated to 2.17.1


State bug for example galaxy angular size measurement

In Stage 3, at marker ang_siz3, the user needs to measure the angular size of the galaxy to advance, which it does correctly. If you move backwards to the ang_siz3 guideline, the state doesn't register that the angular size has already been measured, and it is not possible to go forwards.

I think I've diagnosed the problem here - the state.ruler_clicked_total member value referenced in this guideline doesn't actually exist anywhere. The marker is explicitly advanced to ang_siz4 here.
Now that I've found the cause, this should be easy to fix.


FPGA: Migrate to ClearLinux, use native go and kernel APIs

Build all the tools from the source in ClearLinux environment

Codecov Report

Merging #199 into master will decrease coverage by 0.59%.
The diff coverage is 50%.

@@            Coverage Diff            @@
##           master     #199     +/-   ##
=========================================
- Coverage   79.17%   78.58%   -0.6%
=========================================
  Files          11       11
  Lines        1508     1508
=========================================
- Hits         1194     1185      -9
- Misses        281      289      +8
- Partials       33       34      +1

Impacted Files
Coverage Δ

cmd/fpga_crihook/main.go
78.33% <50%> (-3.75%)
:arrow_down:

Continue to review full report at Codecov.

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

looks good to me except of reduced test coverage.


change base to nvidia-cuda

@AlmightyYakob @mattdawkins Is this something that needs to be merged?

I still need to test this, apologies.

Oh, this is the thing you need to test.  I can help with that, LMK.

So it looks like this is mostly good, but I had to add some changes. I can make a new branch on this repo with this new stuff, so that we can change/update it without issue.

Closing in favor of #70


Fix return type

Coverage remained the same at 88.218% when pulling e488fb8a3f246126fbf0668e302c10b6e3659aa2 on zhanhb:patch-1 into 48c94fce52a7a71840d533e4cff0c4e5efe6e6f1 on ultraq:master.


Build error for ecmwf-atlas when using recent Intel compilers and a gcc@12 backend

Describe the bug
When compiling with Intel, we need to use C++-17 capable gcc compiler as backend in spack. This is done through the compiler config, for example for Discover:
- compiler:
    spec<EMAIL_ADDRESS>    paths:
      cc: /usr/local/intel/oneapi/2021/compiler/2023.2.1/linux/bin/intel64/icc
      cxx: /usr/local/intel/oneapi/2021/compiler/2023.2.1/linux/bin/intel64/icpc
      f77: /usr/local/intel/oneapi/2021/compiler/2023.2.1/linux/bin/intel64/ifort
      fc: /usr/local/intel/oneapi/2021/compiler/2023.2.1/linux/bin/intel64/ifort
    flags:
      cflags: -diag-disable=10441
      cxxflags: -diag-disable=10441
      fflags: -diag-disable=10448
    operating_system: sles15
    target: x86_64
    modules:
    - comp/intel/2023.2.1
    environment:
      prepend_path:
        PATH: '/usr/local/other/gcc/11.4.0/bin'
        CPATH: '/usr/local/other/gcc/11.4.0/include'
        LD_LIBRARY_PATH: '/usr/local/intel/oneapi/2021/compiler/2023.2.1/linux/compiler/lib/intel64_lin:/usr/local/other/gcc/11.4.0/lib64'
      #set:
      #  I_MPI_ROOT: '/usr/local/intel/oneapi/2021/mpi/2021.5.0'
    extra_rpaths: []

With gcc@9:11, this works. With gcc@12,this fails for ecmwf-atlas:
[  3%] Linking CXX executable ../../../bin/atlas-io-list
cd /discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/cache/build_stage/spack-stage-ecmwf-atlas-0.36.0-ygvahpmfl4h44pyocjubiteaz4uaavwm/spack-src/build/atlas_io/src/tools && /gpfsm/dulocal15/sles15/other/cmake/3.28.2/bin/cmake -E remove /discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/cache/build_stage/spack-stage-ecmwf-atlas-0.36.0-ygvahpmfl4h44pyocjubiteaz4uaavwm/spack-src/build/bin/atlas-io-list
cd /discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/cache/build_stage/spack-stage-ecmwf-atlas-0.36.0-ygvahpmfl4h44pyocjubiteaz4uaavwm/spack-src/build/atlas_io/src/tools && /gpfsm/dulocal15/sles15/other/cmake/3.28.2/bin/cmake -E cmake_link_script CMakeFiles/atlas-io-list.dir/link.txt --verbose=1
/discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/spack/lib/spack/env/intel/icpc -O2 -g -DNDEBUG -Wl,--disable-new-dtags "CMakeFiles/atlas-io-list.dir/atlas-io-list.cc.o" -o ../../../bin/atlas-io-list -Wl,-rpath,"/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/ecmwf-atlas-0.36.0-ygvahpm/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/inl/2021.10.0/ecmwf-atlas-0.36.0-ygvahpm/lib64:/gpfsm/dnb55/projects/p01/s2127 \/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/bzip2-1.0.8-secsaw2/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/lz4-1.9.4-wk7dz7k/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/ncurses-6.4-h57iiko/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/openblas-0.3.24-3k3ad6m/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/fftw-3.3.10-jwoymye/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/python-3.10.13-xusbxob/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/expat-2.5.0-iemkw7p/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/libbsd-0.11.7-pwug2g3/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/libmd-1.0.4-57q2udg/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/gdbm-1.23-fqmqprp/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/readline-8.2-ca6xvfd/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/libffi-3.4.4-eirpkvv/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/libxcrypt-4.4.35-cazjnai/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/sqlite-3.43.2-44pzvun/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/zlib-1.2.13-dyrl52j/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/util-linux-uuid-2.38.1-2te4m7v/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/xz-5.4.1-r65qkio/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/qhull-2020.2-ouqsjqu/lib:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/eckit-1.24.5-ciukrk2/lib64:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/ectrans-1.2.0-r3j4al7/lib64:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/fiat-1.2.0-pyeukly/lib64:/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/fckit-0.11.0-bjqhnu4/lib64:\$ORIGIN/../lib64:/discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/eckit-1.24.5-ciukrk2/lib64" ../../../lib/libatlas_io.so \
/discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/eckit-1.24.5-ciukrk2/lib64/libeckit_option.so /discover/nobackup/projects/jcsda/s2127/dheinzel/spstmil/envs/unified-env-intel-2021.10.0/install/intel/2021.10.0/eckit-1.24.5-ciukrk2/lib64/libeckit.so -lm /usr/lib64/librt.so -lpthread -ldl

ld: ../../../lib/libatlas_io.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_use_local_data()' make[2]: *** [atlas_io/src/tools/CMakeFiles/atlas-io-list.dir/build.make:106: bin/atlas-io-list] Error 1 make[2]: Leaving directory '/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/cache/build_stage/spack-stage-ecmwf-atlas-0.36.0-ygvahpmfl4h44pyocjubiteaz4uaavwm/spack-src/build' make[1]: *** [CMakeFiles/Makefile2:1858: atlas_io/src/tools/CMakeFiles/atlas-io-list.dir/all] Error 2 make[1]: Leaving directory '/gpfsm/dnb55/projects/p01/s2127/dheinzel/spstmil/cache/build_stage/spack-stage-ecmwf-atlas-0.36.0-ygvahpmfl4h44pyocjubiteaz4uaavwm/spack-src/build' make: *** [Makefile:169: all] Error 2

I tried different versions of ecmwf-atlas (0.35.1 and 0.36.0), as well as different versions of the Intel compiler (2021.5.0 and 2021.10.0).
Other packages that require C++-17 standard build fine regardless of the gcc backend (e.g. eckit, fckit).
My first guess is that there is another dependency in ecmwf-atlas that isn't compiled with C++-17 standard, i.e. that uses C++-11 and that gets pulled in here. But maybe that assumption is incorrect/
To Reproduce
See above
Expected behavior
It builds with gcc@12 as backend
System:
Any system with Intel compilers supported in spack-stack
Additional context
n/a

We are moving to 0.38.1 and this may not be an issue any more. I'm closing this for now, but we can re-open if anyone experiences the same issue.

This is still going to be an issue, but fortunately we've identified a workaround for it. It requires updating the spack-stack site configs, thus until that gets done this issue should remain open.


Autocomplete feature for CLI options

Having an autocomplete feature for CLI options would definitely improve the user experience.
A quick search suggests that clap is able to support autocomplete, although I haven't tried this yet myself. I'm also not sure if this will work since we use proxy binaries, but it's worth looking into.
If we can make it work somehow, I suspect there will be options that are easier to complete (e.g., --output-format which has a pre-fixed set of options) than others. For example, for --harness one would need to first run kani-driver in order to find the proofs. This may not be desired, so we should carefully evaluate the process for each option.

Yes, that would be awesome! I think at least enabling the auto complete for the flags would be amazing. For values that are not enums, I think it will be more complicated.

I just bumped into this enum to help with custom values: https://docs.rs/clap/4.2.7/clap/enum.ValueHint.html


Applying HoloToolkit scene and project settings should show proper status in menu items

[Migrated from internal feedback 10971165]
"When we use the HoloToolkit menu to setup camera, field of view, etc., please look at what is already set. If it is set, check it in the little menu you show, that way we don't have to remember or wonder if something has been set previously."

Closing issues older than 180 days. If this is still an issue, please reactivate with recent information.


[Bug] f5 cause crash rendering armor

3rd person view crashing with armor on.

have not tested vanilla armor,
crash with aether armor (tested with only aether mod)
also tested with another mods armor

Sorry for not adding the "bug" tag, I couldn't figure out how

Fixed by PR #66


[IMPORTANT] Do not use v8.1.0, it's broken!

I already addressed the issue in #280
In the latest release there is a typo we didn't spot before.
Fixed and tested.

Fix should be released in a moment

As long as v8.1.0 is the latest version available I'd leave this open.

At the time Ive closed this issue the release was already happening, so i’ve just assumed that it would go smoothly

Ah, it failed on linting - sorry. It was already past midnight when I was handling this and had to go to sleep.


Supporting other date formats

Right now dates are parsed based on delimiter ("/" for American and "-" for European) which has month/day swapped around.
There have been needs for at least the "ISO" format of YYYY-MM-DD HH:MM:SS http://getgrav.org/forum#!/theme-development:international-yaml-date-fie
Some ability to make a site-wide (with document level override?) config for what the expected input date is would be handy.
I think the php library already supports some of this, reading here:
http://php.net/manual/en/datetime.formats.date.php

Playing some more, I'm not sure this is needed... I find that it parses correctly if the date field is enclosed by double-quotes (") - I had some entries with and some without, which was throwing me.

good to know. closing this then.

Hi! Good morning! I'm still studying Grav and when I read about the date, I thought that I should warn you.
I'm sorry for bring more issues here, but I think this can cause issues. Here, in Brazil, the used date format is dd/mm/yyyy!
I think it's better/safer to use ISO 8601 by default.
Thanks.

@robsonsobral when adding dates manually (not using the Admin plugin) the format described here http://learn.getgrav.org/content/headers#date allows Grav to understand how it should interpret the date.
Displaying the date on the site is another topic, and it's set in the System configuration.
If you believe there is a problem I don't see, please open a new issue.


Missing letter T in README.md

//produces the following output
{
salu T ation: 'Mr.',
firstName: 'William',
suffix: 'III',
lastName: 'Hearst',
middleName: 'R.',
fullName: 'Mr. William R. Hearst, III'
}

please submit a PR

Ok, don't know why i need to PR if you can edit it on github.

fixed.


Single Ignition/Retraction Issue

Lightsaber only powers on / powers off once. After that, the saber becomes unresponsive - buttons do nothing, no sound is played, and LEDs remain off. While the saber is on, however, it functions as expected - swings detected, blaster mode can be entered/exited, and lockup activated. Upon powering off lightsaber, "L" LED aboard nano remains lit for 1s and extinguishes (otherwise, it is solid).
Config menu works as expected only from boot. Can be entered/exited multiple times without issue, but cannot be accessed after power on/power off when the saber becomes unresponsive.
Problem persists on two different Nano clone boards (these) with CH340G USB serial chips (not FTDI). Issue was not encountered the first few times code was compiled/uploaded to Nano. Tried resetting the board with blank sketch and reuploading LSOS - no success.
Commented LS_INFO and uncommented LS_DEBUG, LS_BUTTON_DEBUG, LS_RELAUNCH_DEBUG, and LS_DEBUG_SLEEP in Config. Serial monitor returns "Main button click" upon power on and "Main button longPress start" and "Main button longPress..." during power off. Doesn't seem to iterate "Main button longPress..." like it does for entering config menu. Also does not seem to detect the button being released.

Updated with more info.

Problem source found and corrected in v1.0.1 :
Nano clones seems to have a problem with the corde of the first retractation effect : I replace the counter type to uint8_t to int8_t and it now works OK.
 Thank you! Who would've thought that uint8_t would've been so pesky.


Potential solution for ignoring unknown flags

A potential solution for ignoring unknown flags. This is something we've run into a need for with automated deployments of updates.
The basics are that if the parser runs into an unknown TokenShort or TokenLong and the option to ignore unknown is set, it advances the context - potentially past a trailing argument to the flag.
This doesn't break any tests (but doesn't add any yet).
I know the idea was closed in #237 but I figured I'd have a go at it and submit a PR for discussion. Thanks!

So, --foo bar is handled properly, because after recognizing an unknown TokenShort or TokenLong the parser advances past everything until it finds the next TokenShort, TokenLong, or TokenEOL. There may be cases I haven't thought through, however.
I just added a clearer loop to get to the next usable token (short, long, EOL).
This is just for flags, not sub-commands, although it does work properly for flags on those sub-commands.

How does that account for positional arguments? ie. How does  it differentiate between a positional argument and an unknown flag value?

What's the use case for this exactly?

Good question - in the past, we've taken out flag-set params in our code, or added future flags to service definitions, and had to do a delicate dance to not have auto-updates to services fail because of unrecognized flags.
It's a problem that we face that may not be wide-spread, but I know from this and other repos it's not an entirely unique problem. I did recognize that it may not be a need for a majority of users, and so made use of this feature strictly opt-in. (Also opt-in so merging this code doesn't break expected behavior.)

How does that account for positional arguments? ie. How does it differentiate between a positional argument and an unknown flag value?

Let me investigate that... I think it handles it properly because positional args aren't TokenShort or TokenLong tokens, but maybe I'm wrong.

One case I ran into the following case. Consider having a sendmail binary for example, and you wanna replace it with a custom one that can handle some of the flags ignoring others.


DYI instead of DIY

Hi Peli,
I created some cardboard circuits and I'm doing a blog about it on the SparkFun site. I'm listing the github link below and noticed a possible typo in the heading.
https://microsoft.github.io/cardboard-circuits/

Thanks! Fixed it!


Bootstrap Runtime

@matbuechner, I'm doing some work with @AllenHu95 using the IPCA code here and had a couple of questions I was hoping you could help with, as I'm fiddling around with the backend.  In particular, we're doing some work with the bootstrap testing procedure and are hoping to improve the runtime somewhat.

Do you have a good sense of whether 10e-6 is the "right" threshold for convergence?  Since we have to refit IPCA for each bootstrap sample, I'm considering using a less conservative threshold but wanted to check whether you foresee any issues there.

Would you be open to a PR that allows users to modify the fit params at run-time (as opposed to using IPCA class values)?  What I'm imagining here is adding some additional key-words to _fit_ipca for iter_tol and max_iter (which could be passed through the bootstrap tests).  In cases where these key-words weren't provided we'd default to the class values.
My use-case here would be a more conservative threshold for the main IPCA run, and then a lighter one for the bootstrap sample runs.  Obviously, there are work-arounds (could set the class value after fitting the main run), which might be preferable, so I wanted to get your input.

It looks like most of the work is done in the alternating-least squares component.  Off-hand, do you think there are any opportunities for performance improvement there?
I'll note that when we run each bootstrap iteration sequentially the run-time per iteration is better (about 5 minutes), vs. in parallel (< 1.2 hours).    Let me know if you see an obviously solution based on this result.

Thanks, and let me know if there are any other details I can provide.
-Leland

Thanks, @lbybee.

Regarding the threshold, I have no strong prior for 10e-6. I agree that it might be conservative in some cases. My suggestion would be to plot the convergence rate to determine at what point it levels off and to adjust iter_tol accordingly. One caveat, this would require us to be sure that the convergence is "smooth", i.e. there should be no weird jumps in the measure that is used to determine convergence.
I am certainly open to this if there is demand. The only argument against it would be proliferation of PRs in the _fit_ipca. Would you rather want to see this as part of _fit_ipca or are you fine adjusting the PRs on the class?
Thanks for pointing this out. Does this occur both with the 'multiprocessing' and the 'loky' backend of joblib?

In terms of general performance improvement in the alternating least squares function, it might be worthwhile to think about using the sparse matrix routines of numpy / scipy, but I haven't given this deep thought yet. Your input is definitely welcome.
-Matthias

I think ita worth look at the model  before doing all the bootstrapping. that's only sth we want to do if we think we will use it.
On Thu, May 23, 2019, 1:31 PM Leland Bybee <notifications<EMAIL_ADDRESS>wrote:
@matbuechnerhttps://github.com/matbuechner, I'm doing some work with @AllenHu95https://github.com/AllenHu95 using the IPCA code here and had a couple of questions I was hoping you could help with, as I'm fiddling around with the backend. In particular, we're doing some work with the bootstrap testing procedure and are hoping to improve the runtime somewhat.

Do you have a good sense of whether 10e-6 is the "right" threshold for convergence? Since we have to refit IPCA for each bootstrap sample, I'm considering using a less conservative threshold but wanted to check whether you foresee any issues there.

Would you be open to a PR that allows users to modify the fit params at run-time (as opposed to using IPCA class values)? What I'm imagining here is adding some additional key-words to _fit_ipca for iter_tol and max_iter (which could be passed through the bootstrap tests). In cases where these key-words weren't provided we'd default to the class values.

My use-case here would be a more conservative threshold for the main IPCA run, and then a lighter one for the bootstrap sample runs. Obviously, there are work-arounds (could set the class value after fitting the main run), which might be preferable, so I wanted to get your input.

It looks like most of the work is done in the alternating-least squares component. Off-hand, do you think there are any opportunities for performance improvement there?

I'll note that when we run each bootstrap iteration sequentially the run-time per iteration is better (about 5 minutes), vs. in parallel (< 1.2 hours).  Let me know if you see an obviously solution based on this result.
Thanks, and let me know if there are any other details I can provide.
-Leland
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/bkelly-lab/ipca/issues/1?email_source=notifications&email_token=ACICUE2ORISSOAESRKJKUDDPW3IGXA5CNFSM4HPIXUH2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GVQV6OA, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACICUE7OHOXOPMKZP737EPTPW3IGXANCNFSM4HPIXUHQ.

@kellybry I can provide the estimates (without p values) for all Γ later. Will run the code without bootstrap.

Thanks all of you for working together on this btw.
On Thu, May 23, 2019 at 6:05 PM AllenHu95 <notifications<EMAIL_ADDRESS>wrote:
@kellybryhttps://github.com/kellybry I can provide the estimates (without p values) for all Γ later. Will run the code without bootstrap.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/bkelly-lab/ipca/issues/1?email_source=notifications&email_token=ACICUE465VW5C4POLLKA3JLPW4IKVA5CNFSM4HPIXUH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWDTYOI#issuecomment-495402041, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ACICUEYNL5V4HF2JGSH3T53PW4IKVANCNFSM4HPIXUHQ.
--
Bryan T. Kelly
Professor of Finance
Yale School of Management
https://www.bryankellyacademic.org/http://faculty.chicagobooth.edu/bryan.kelly


Model loading in 4bit cannot be trained in multiple GPUs?

Hi all,
Appreciate for this awesome work.
I was trying to feed the model into 2 3090ti (24G VRAM each). Loading in 4bit, however I got the error message "ValueError: You can't train a model that has been loaded in 8-bit precision on multiple devices.".
It seems that Accelerate does not allow 4/8-bit model to be trained on multiple devices.
Or it could be "device_map="auto"" does not work for 4bit?

Hi all,
Appreciate for this awesome work.
I was trying to feed the model into 2 3090ti (24G VRAM each). Loading in 4bit, however I got the error message "ValueError: You can't train a model that has been loaded in 8-bit precision on multiple devices.".
It seems that Accelerate does not allow 4/8-bit model to be trained on multiple devices.
Or it could be "device_map="auto"" does not work for 4bit?

how to solve?

Hi all,
Appreciate for this awesome work.
I was trying to feed the model into 2 3090ti (24G VRAM each). Loading in 4bit, however I got the error message "ValueError: You can't train a model that has been loaded in 8-bit precision on multiple devices.".
It seems that Accelerate does not allow 4/8-bit model to be trained on multiple devices.
Or it could be "device_map="auto"" does not work for 4bit?

how to solve?

pip uninstall accelerate -y
pip install git+https://github.com/huggingface/accelerate.git
when run this, my code can work.

@diaojunxian When version of accelerate are you using when it worked?
Did it work with device_map="auto"?


Support for multiple weighted clusters in routing

[apologies for the delayed turn around for this feature].
This PR provides an intuitive way of specifying cluster weights, when a particular route is backed by two or more clusters. Instead of using the existing Runtime style probability specification, users can group related clusters under a single weighted_clusters block with % weights assigned to each cluster.
Please refer to #247 for more details.
The current PR is missing documentation. Will add that in a day or so. TLDR:
In the routing config, you can have either the cluster key or the weighted_clusters key.
The weighted_clusters is of the following format:
"weighted_clusters" : {
"runtime_key_prefix" : "foo",
"clusters" : [{ "name" : "cluster-name", "weight" : N },
...
]}

where N is an integer from 0 to 100. It determines the proportion of request traffic to be sent to the target cluster. The sum of all weights in the weighted cluster should be equal to 100.
On runtime support for weighted clusters: If we wish to validate the weights provided by the user (as we do it currently), it is not exactly clear how the weights would be validated (i.e. sum of weights == 100) if runtime support were to be enabled for a weighted cluster. My current inclination is to skip runtime support altogether for weighted_clusters. With the addition of RDS, a user can combine weighted cluster and RDS to dynamically change weights. It may not occur instantaneously (as it depends on the RDS poll interval).
Fixes #247
@mattklein123 @ccaraman
p.s.: For reviewing this PR, please do not look at the individual commits. Instead, I suggest looking at config_impl.h|cc as one change set and then config_impl_test.cc as another change set.

added runtime support as well.

@rshriram: @ccaraman will review first. I will take final pass once she is done.

addressed all except the traffic shifting/splitting issue. Waiting on feedback from @junr03 .

@rshriram after reading your doc it is obvious to me how you could do traffic shifting with the same mechanism, so I agree that having both docs is somewhat duplication. However, I think that it is better to have a traffic shifting example to make the use case explicit for users. I think it would be best to merge the two docs; eliminating duplicate info from the traffic shifting doc as needed.

@junr03 I will send a separate PR to merge the two docs.

great!

@rshriram @junr03 sorry I thought this was done. A follow up docs PR sounds good.


Custom frames for windows not applied correctly

Describe the bug
Since version 0.25 there is a visual bug when we set a custom window frame. In 0.24 the code below was making the window all green (as expected) with little margin.
let frame = egui::containers::Frame::none()
    .fill(egui::Color32::from_rgb(180, 220, 160))
    .inner_margin(egui::Margin::symmetric(20.0, 20.0));

In 0.25 and 0.26 the same code makes it only partially green with title bar area still with its original color, which is also not properly adjusted to the title.

To Reproduce
Steps to reproduce the behavior:

Go to egui_demo_lib -> window_options.rs
Find creation of "demo_window_options" window
Make it as below:

use super::View as _;
let frame = egui::containers::Frame::none() // <-- new
	.fill(egui::Color32::from_rgb(180, 220, 160)) // <-- new
	.inner_margin(egui::Margin::symmetric(20.0, 20.0)); // <-- new
let mut window = egui::Window::new(title)
	.id(egui::Id::new("demo_window_options"))
	.frame(frame) // <-- new
	.resizable(resizable)
	.constrain(constrain)
	.collapsible(collapsible)
	.title_bar(title_bar)
	.scroll2(scroll2)
	.enabled(enabled);

Expected behavior
Just as in 0.24 and earlier, the whole window area should be colored green with no exception for title bar.

Was this solved by https://github.com/emilk/egui/pull/3995 ?

Sadly no, I was testing it on the most recent master which already includes fix from #3995.

@Tearth
Is it similar to #3806 ?

@Tearth Is the color-related thing similar to #3806 ?

Seems like yes, and turns out adding context.style_mut(|p| p.visuals.window_highlight_topmost = false); similarly as you did in your issue fixed the thing - the window is now displayed as I was used to before 0.25. Thanks for the link!


Bug: Internal error "The context currently only supports a single SQL statement"

Describe the bug

Running the following tpcds queries in postgres accelerator gives error 14 23 24 39

Using TPCDS connector as a data source, with DuckDB in-memory or file-mode acceleration:

Status { code: Internal, message: "This feature is not implemented: The context currently only supports a single SQL statement", metadata: MetadataMap { headers: {"content-type": "application/grpc", "date": "Wed, 11 Sep 2024 06:32:27 GMT", "content-length": "0"} }, source: None }

This error is observed on the following TPCDS queries:

Q14
Q23
Q24
Q39

TPCDS queries stored as seen in datafusion-benchmarks
To Reproduce
Steps to reproduce the behavior:

Configure a connector with a TPCDS data source using DuckDB in-memory or file-mode acceleration
Run one of the specified TPCDS queries
Observe error

Expected behavior
The TPCDS queries should run successfully.
Testing Validation
In-memory DuckDB:

[ ] Q14
[ ] Q23
[ ] Q24
[ ] Q39

File mode DuckDB:

[ ] Q14
[ ] Q23
[ ] Q24
[ ] Q39

Spicepod
version: v1beta1
kind: Spicepod
name: tpcds1.duckdb
datasets:
  - from: duckdb:call_center
    name: call_center
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:catalog_page
    name: catalog_page
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:catalog_returns
    name: catalog_returns
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:catalog_sales
    name: catalog_sales
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:customer
    name: customer
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:customer_address
    name: customer_address
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:customer_demographics
    name: customer_demographics
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:date_dim
    name: date_dim
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:household_demographics
    name: household_demographics
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:income_band
    name: income_band
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:inventory
    name: inventory
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:item
    name: item
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:promotion
    name: promotion
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:reason
    name: reason
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:ship_mode
    name: ship_mode
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:store
    name: store
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:store_returns
    name: store_returns
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:store_sales
    name: store_sales
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:time_dim
    name: time_dim
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:warehouse
    name: warehouse
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:web_page
    name: web_page
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:web_returns
    name: web_returns
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:web_sales
    name: web_sales
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory
  - from: duckdb:web_site
    name: web_site
    params:
      duckdb_open: tpcds1.duckdb
    acceleration:
      enabled: true
      engine: duckdb
      mode: memory

spicepod.yaml
version: v1beta1
kind: Spicepod
name: tpcds-sf0.1.db
datasets:
  - from: duckdb:call_center
    name: call_center
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:catalog_page
    name: catalog_page
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:catalog_returns
    name: catalog_returns
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:catalog_sales
    name: catalog_sales
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:customer
    name: customer
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:customer_address
    name: customer_address
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:customer_demographics
    name: customer_demographics
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:date_dim
    name: date_dim
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:household_demographics
    name: household_demographics
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:income_band
    name: income_band
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:inventory
    name: inventory
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:item
    name: item
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:promotion
    name: promotion
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:reason
    name: reason
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:ship_mode
    name: ship_mode
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:store
    name: store
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:store_returns
    name: store_returns
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:store_sales
    name: store_sales
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:time_dim
    name: time_dim
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:warehouse
    name: warehouse
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:web_page
    name: web_page
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:web_returns
    name: web_returns
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:web_sales
    name: web_sales
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds
  - from: duckdb:web_site
    name: web_site
    params:
      duckdb_open: tpcds-sf0.1.db
    acceleration:
      enabled: true
      engine: postgres
      params:
        pg_host: localhost
        pg_port: 5432
        pg_user: postgres
        pg_pass: postgres
        pg_sslmode: disable
        pg_db: tpcds

Closed by: https://github.com/spiceai/spiceai/pull/2970


Avoid using {} for objects with unknown properties

In which branch or foundry version should this feature be added?
Any
Is your feature request related to a problem? Please describe.
The use of {} is not particularly helpful for objects with unknown properties, and it is reported as an error with typescript-eslint or tslint.

Avoid the Object and {} types, as they mean "any non-nullish value".
This is a point of confusion for many developers, who think it means "any object type".
https://github.com/typescript-eslint/typescript-eslint/blob/v4.4.1/packages/eslint-plugin/docs/rules/ban-types.md#default-options

It also disallows access of the object properties game.modules.get("foo").data.title without adding ts-ignore or recasting the object like (game.modules.get("foo").data as Record<string, unknown>).title.

Property 'title' does not exist on type '{}'

Describe the solution you'd like
Instead of using {}, use Record<string, unknown>, as the user will be able to access contents of the objects without adding ts-ignore, and stop typescript-eslint from freaking out.
Alternatively, use the unknown type, as it will force the user to recast the object anyway.

Could you please provide specific occurrences where you would like to see this adjusted? We typically already use Record<string, unknown> or similar types in these kinds of situations but obviously there may be mistakes.

Ah, I must have been mistaken, I thought I saw it more, but I guess it was just Game.Module.data game.d.ts:764 then.
The types work really well so far. Thanks to all of you for this massive undertaking, and good job!


Odd usability when navigating away from unsaved form

If you change a record (contact) then open another contact w/o saving, the changes are not saved, but not cancelled either – if you navigate back to the changed record, it still has the changes you made visible in the form. This leads to a somewhat confusing UX.
Video: https://d.pr/v/y1NXyo
Ideally it would require explicit action (save/cancel): disallow navigating away if the form has been modified, and make buttons indicate whether or not there are changes to save/cancel.

fixed


Add COPR build for master

I remember that you were interested in the COPR builds for new commits to master branch.
This will build in your COPR project (psss/tmt). (Packit should ask you for builder permission.)
If you don't set the owner+project, we will create packit/psss-tmt-master for you.

Nice, thanks for the improvement! For now the packit/psss-tmt-master repo would be ideal. So I can keep the config as it is now?

You are welcome. We have that for some time already but we probably need to share this more..;)

For now the packit/psss-tmt-master repo would be ideal.

I see you fixed that by yourself, thanks:
https://github.com/psss/tmt/commit/4338162343e9d47d69c8490316967ca922d96812

@lachmanfrantisek, just noticed after switch to the main copr repo: Packit needs the "admin" permission to the repo?

@lachmanfrantisek, just noticed after switch to the main copr repo: Packit needs the "admin" permission to the repo?

Only when we need to change settings -- e.g. chroots.
For PRs, you should get a comment with the required changes and you can choose if you do the change manually or give us the admin permissions. For branch builds, we have only commit status for now.

I see, thanks for clarification.


python310Packages.aiosomecomfort: 0.0.7 -> 0.0.8

Diff: https://github.com/mkmer/AIOSomecomfort/compare/refs/tags/0.0.7...0.0.8
Changelog: https://github.com/mkmer/AIOSomecomfort/releases/tag/0.0.8
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
23.05 Release Notes (or backporting 22.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 216553 run on x86_64-linux 1

3 packages built:

home-assistant-component-tests.honeywell
python310Packages.aiosomecomfort
python311Packages.aiosomecomfort


Uncaught SecurityError when used with flow-router

I initially reported this issue within flow-router here https://github.com/meteorhacks/flow-router/issues/118#issuecomment-104694222. I get an error in the browser console when using velocity meteor-mocha-web with flow-outer. It appears to be an issue with page.js which is used within flow-router, and I suppose page.js just doesn't work within the context where meteor-mocha-web is running tests. I get an error that looks like this:
Uncaught SecurityError: Failed to execute 'replaceState' on 'History': A history state object with URL 'http:/?mocha=true&lastModified=1432567736395' cannot be created in a document with origin 'http://localhost:58823'.

Interestingly, the tests still seem to run without a problem. I don't know much about the inner workings of meteor-mocha-web, but it seems bizarre there would be an attempt to create a history event with the URL http:/?mocha=true&lastModified=1432567736395.
This error can be reproduced with the following steps:
$ meteor create flow-test
$ cd flow-test
$ meteor add meteorhacks:flow-router
$ meteor add mike:mocha
$ meteor

Has anyone else run into this? Can I just ignore that error since it doesn't appear to affect the application or the tests?

I am experiencing the same issue. As you said, the test runs fine in spite of this. But it'd be good to have a fix for this pesky error message.

I can confirm I'm seeing this error too.

I am encountering the same issue.  Since the Mocha iframe doesn't load because of the invalid origin exception being thrown, my tests actually don't run unless I manually go to the URL that the Mocha iframe is trying to load.
While the exception is happening in flow-router code, the error is caused by an invalid URL being loaded by mike:mocha.
The iframe src is actually combining mirror.rootUrl + mirror.rootUrlPath (as seen at this line of code) in the mochaWebIFrameURL helper.  Since mirror.rootUrl has a trailing slash and mirror.rootUrlPath has a leading slash, this is causing the iframe URL to be http://localhost:56135//?mocha=true&lastModified=1440508192343 (note the double-slash after the port).
Eliminating the double slash in the URL fixes this problem.
I guess this can be fixed one of a few ways:
First option is changing the mochaWebIFrameURL helper to parse the trailing slash from rootUrl:
return mirror.rootUrl.replace(/\/$/, "") + mirror.rootUrlPath + "&lastModified=" + mirror.lastModified;
Second option, almost the same, is to use url-join to combine the two instead of just lobbing it off the end of the host.  This is safer, but possibly completely unnecessary because it seems the only time that rootUrlPath is set is in the server init... which brings me to the third option...
Third, and likely best solution, is just remove the leading slash from the rootUrlPath in the server initialization code.  This option does require you to restart your server, as a regular hot-reload won't reinit the velocity database which stores this rootUrlPath value.
I can make a pull-request but would want @rralian to comment on if it matters changing rootUrlPath first, or if there is another recommended fix.

@abernix First, thanks for diving into this... you went deeper than I did. I don't think you need to wait for me... I'm just the guy who submitted the original issue. But your suggested fix (i.e., "best option") sounds reasonable to me. I can't think of a reason we would need the leading slash. So I'd say submit the PR.

Haha, well, your opinion definitely does matter, of course @rralian, but I guess I totally mis-tagged you and meant to ask the package maintainer, @mad-eye, if he thought changing the rootUrlPath would matter. :grin:

That's what I figured. :smile:

@mad-eye could you please provide a fix as suggested (removing the / from rootUrlPath), as this makes mocha mike unusable with an app with flow-router, or page.js

Yes, please fix this.

Pull-request #192 submitted which fixes this problem.

:+1:


Getting Denom must be between 3 and 128 characters Error

While using GasPrice.fromString function I am getting the  Denom must be between 3 and 128 characters Error
But for chain fxcore the Fee denom is 'FX'
fee_tokens: [
{
denom: 'FX',
fixed_min_gas_price:<PHONE_NUMBER>000,
low_gas_price:<PHONE_NUMBER>000,
average_gas_price:<PHONE_NUMBER>000,
high_gas_price:<PHONE_NUMBER>000
}
]

Hello @shukr-acharya
have you resolve this issue?

No

Hello @shukr-acharya have you resolve this issue?

No

As a workaround you can use the GasPrice constructor directly. Something like this should work:
const price = new GasPrice(Decimal.fromUserInput("0.123", 18), "FX");

As a workaround you can use the GasPrice constructor directly. Something like this should work:
const price = new GasPrice(Decimal.fromUserInput("0.123", 18), "FX");

Thanks @webmaster128, it works

How do you implement this on chain? The pattern in Cosmos SDK requires denoms to be at least 3 characters:
https://github.com/cosmos/cosmos-sdk/blob/v0.50.2/types/coin.go#L831-L833. So I am wondering if GasPrice.fromString should support this case.


Add a dependency from ASP.NET Core to .NET Core targeting pack installers

Targeting pack installers should mirror the runtime installer dependency graph.

cc @anurse


[web]: Firebase Firestore web plugin

I'd like to use Firebase Firestore in my Flutter web app. What's the process?
Possible solutions:

Communicate with the Firebase javascript library via platform channels. If so I'm looking for examples of how to communicate with js libraries.
Use the Rest API and build a pure dart package

Try this https://pub.dev/packages/firebase
But we are having issues – see https://github.com/flutter/flutter/issues/32524

@passy I've been able to make firebase package work in flutter_web after correcting pubspec.yaml as follows:
dependencies:
  flutter_web: any
  flutter_web_ui: any
  firebase: any

dev_dependencies:
  build_runner: any
  build_web_compilers: '>=1.0.0 <2.0.0'
  pedantic: ^1.0.0

The key here is the version of build_web_compilers.

The important note here is that we are using firestore (instead of cloud_filestore) which is bridging to firebase.js embedded into web page.
I had to follow web configuration to make it work with the above config, but finally succeed:): https://firebase.google.com/docs/web/setup

Is the current solution not really cumbersome as there needs to be two seperate code bases for mobile and web backend code? One uses the FlutterFire plugins and one uses the firebase web plugin..

We know it's CRAZY difficult with the current setup. This is a technical preview. We are very focused on getting merged into the core Flutter SDK to resolve this.

Is there any chance of a time frame estimation? That would really help a huge amount with planning!

@kevmoo any estimates for the merge?

@aryzhov thanks for that! Made Firebase work on my project... the only issue with < 2.0.0 is that I can't use libraries such as Moor/Hive for persistent database using Flutter Web. Hopefully gets resolved soon.

@mkiisoft you don't need to use build_web_compilers: '>=1.0.0 <2.0.0' anymore.
You might also take a look at the crossfire package which provides a common API for the FlutterFire plugins and the JS Api Wrapper of the firebase package.

I get a blank screen and 'FirebaseJsNotLoadedException: firebase.js must be loaded' with
build_web_compilers: '>=1.0.0 <2.0.0'
and with build_web_compilers: ^2.0.0
when I try to call fb.InitializeApp

@mkiisoft

I can't use libraries such as Moor/Hive for persistent database using Flutter Web.

You can actually. Here is a sample which uses Hive for flutter web. Source code

does any have flutter web firebase sample code.

Everyone who are still confused, have a look at this solution: https://link.medium.com/kDgKPDM081

You can check out the steps in this articles:  Flutter Web: Firestore Crud.

@happyharis Nice idea to write the article. It looks like Firestore Flutter web support is immanent: https://github.com/FirebaseExtended/flutterfire/pull/1670


Mvi farm

Pull Request Template
Type of Change
Select a category that relates to the content of your pull request (choose all that apply).

[ ] Bug Fix
[x] Content
[ ] New Feature
[ ] Documentation
[ ] Code Refactoring

Summary of Changes
Updated MVI LM rewards date. No change in INDEX daily rewards (still 110 INDEX)

Fixes: Issue # #334

Test Data or Screenshots

Include proof that your changes function properly and resolve the linked issue.

Submission Reminders
By submitting this pull request, you are confirming the following to be true:

I have reviewed the Contribution Guidelines.
I have performed a self-review of my own code.
I have updated my repository to match the master at SetProtocol/index-ui.
I have included test data or screenshots that prove my fix is effective or that my feature works.

Thanks for the PR! However, MVI liquidity mining hasn't been extended yet. That will be done sometime in the coming week.

Matthew requested to change the DPI to 0
https://discord.com/channels/762061559744299010/762062707548487691/876749983074881576
added another commit for DPI

MVI hasn't gone live yet, so the above dates will not be accurate. Ack on the DPI change, will be adding that in a following PR


revert: "chore(deps): update engines to 4.8.0-11.e88b5dd70fddc391f9344ee8056dfd92f0f6fdef"

Reverts prisma/prisma#16647

Merging to unblock engines and I'll redo the original PR


Unable to fetch most recent media URL on GoPro Fusion

OS: macOS 11.1 (Big Sur)
GoPro: Fusion

I get an almost empty file path when using the getMedia() and getMediaFusion() functions.
To Reproduce
Steps to reproduce the behavior:
>>> from goprocam import GoProCamera, constants
>>> GoProCamera.GoPro().getMediaFusion()

Expected behavior
It should return the URL for both front and back images of last picture taken.
['http://<IP_ADDRESS>/videos/DCIM/100GBACK/GPBK0151.JPG', 'http://<IP_ADDRESS>/videos2/DCIM/100GFRNT/GPFR0151.JPG']
Screenshots
Instead, it returns:
['http://<IP_ADDRESS>/videos/DCIM//', 'http://<IP_ADDRESS>/videos2/DCIM//']

Additional context
The SD cards are not empty.
I am able to view images by manually typing in the correct URL on the browser.
goprocam/GoProCamera.py lines 649-677? Are "GBACK", "GFRNT" supposed to be prefixed with "100" to be "100GBACK", "100GFRNT"?

Hi, can you rollback to this version? https://github.com/KonradIT/gopro-py-api/releases/tag/3.0.1 and try again

Thank you for your response, Konrad. It seems I have the same issue with v3.0.1 as well.


Temporary error upon loading the card

Checklist:

[X] I updated to the latest version available
[X] I cleared the cache of my browser

Release with the issue:
5.3.0
Last working release (if known):
Browser and Operating System:
Version 119.0.6045.160 (Official Build) (64-bit)
Windows 11
Description of problem:
Initial loading of the page shows an error, that disappears in <1 sec, still is quite disturbing.

This comes upw even with the simplest layout of the card.
Javascript errors shown in the web inspector (if applicable):
none
Additional information:
example config tested:
type: custom:hourly-weather
entity: weather.home

Interesting, I wonder if this is a result of the recent change to use a web service call to get forecasts from HA. Perhaps we can hold off on showing errors if the web service call hasn't completed yet. If someone has time to look at this I can look at a PR. Otherwise, I'll get to this when I can.

I also got the same error come up on my little wall panel

So in the past days I was able to debug the problem, and get the root cause.

(I have a quite big dashboard with multiple different cards, using Meteorologisk institutt (Met.no))
initially we start the subscription with subscribeToForecastEvents
upon loading card starts rendering renderCore
this calls const forecast = this.getForecast();
as there is no answer yet from the subscription ( this.forecastEvent?.forecast is equals null in private getForecast() that returns the default daily granularity from the this.hass?.states[this.config.entity]?.attributes.forecast (6 items with daily granularity))
yields to error (this._showError(this.localize('errors.too_many_segments_requested')))
shortly HA kicks in for the subscription and subscribeMessage callback returns with the hourly distribution (24 entries in the array)
card re-renders with correct content.

I have an initial suggestion, please feel to review the PR and comment/modify.


podman1.6.4: unable to pass multiple --security-opt parameters

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
/kind bug
Description
In podman 1.6.4 at least (used in RHEL-8.1 for OSP project), we're apparently unable to pass multiple --security-op parameters to podman run, for instance:
podman run --net host --name selinux-test --rm -ti --security-opt=label=level:s0 --security-opt=label=type:svirt_t --privileged centos:8 sh

Although the container is started, we don't see both options - only the latest is applied, at least according to podman inspect:
[...]
            "Annotations": {
                "io.container.manager": "libpod",
                "io.kubernetes.cri-o.ContainerType": "sandbox",
                "io.kubernetes.cri-o.Created": "2020-06-11T08:30:18.590733514Z",
                "io.kubernetes.cri-o.TTY": "true",
                "io.podman.annotations.autoremove": "TRUE",
                "io.podman.annotations.init": "FALSE",
                "io.podman.annotations.label": "type:svirt_t",
                "io.podman.annotations.privileged": "TRUE",
                "io.podman.annotations.publish-all": "FALSE",
                "org.opencontainers.image.stopSignal": "15"
            },
[...]
            "SecurityOpt": [
                "label=type:svirt_t"
            ],
[...]

Steps to reproduce the issue:

Run a container with multiple --security-opt as parameter

Inspect the container

Describe the results you received:
Apparently only the last param value is applied, all previous ones are just discarded
Describe the results you expected:
We should see all the passed options in the SecurityOpt list
Additional information you deem important (e.g. issue happens only occasionally):
Apparently this isn't an issue anymore in podman-1.9.3 - maybe it's "just" a missing backport?
Output of podman version:
podman version 1.6.4

Output of podman info --debug:
debug:
  compiler: gc
  git commit: ""
  go version: go1.12.12
  podman version: 1.6.4
host:
  BuildahVersion: 1.12.0-dev
  CgroupVersion: v1
  Conmon:
    package: conmon-2.0.6-1.module+el8.1.1+5259+bcdd613a.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.6, commit: 6ffbb2ec70dbe5ba56e4bfde946fb04f19dd8bbf'
  Distribution:
    distribution: '"rhel"'
    version: "8.1"
  MemFree:<PHONE_NUMBER>8
  MemTotal:<PHONE_NUMBER>6
  OCIRuntime:
    name: runc
    package: runc-1.0.0-64.rc9.module+el8.1.1+5259+bcdd613a.x86_64
    path: /usr/bin/runc
    version: 'runc version spec: 1.0.1-dev'
  SwapFree:<PHONE_NUMBER>
  SwapTotal:<PHONE_NUMBER>
  arch: amd64
  cpus: 12
  eventlogger: journald
  hostname: overcloud-0-novacompute-0
  kernel: 4.18.0-147.8.1.el8_1.x86_64
  os: linux
  rootless: false
  uptime: 2h 6m 18.21s (Approximately 0.08 days)
registries:
  blocked: null
  insecure:
  - undercloud.ctlplane:8787
  search:
  - registry.access.redhat.com
  - registry.fedoraproject.org
  - registry.centos.org
  - docker.io
store:
  ConfigFile: /etc/containers/storage.conf
  ContainerStore:
    number: 15
  GraphDriverName: overlay
  GraphOptions: {}
  GraphRoot: /var/lib/containers/storage
  GraphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 8
  RunRoot: /var/run/containers/storage
  VolumePath: /var/lib/containers/storage/volumes

Package info (e.g. output of rpm -q podman or apt list podman):
podman-1.6.4-4.module+el8.1.1+5885+44006e55.x86_64

This seems to be fixed in 2.0, so I'm going to close here.
If you're looking for a backport/patch for 1.6.4, please open a BZ.


Pass state/props to onRight or onLeft (navbar)

Version

react-native-router-flux v3.30
react-native v0.28

Is it possible? how to do that?
for instance if I want to save a form using the navbar right button...

I think this can be done, but not sure how. Right now I see that the Connect function is passed in...

Any ideas on this?

I think this is a great reason to use flux. React shouldn't be trying to share state or props when you can have a higher level store keep this information for multiple components to connect to and use.

Exactly. I am using redux but i find no way to access or pass the store
there :(
On Thu, 30 Jun 2016 at 20:00, Chris Ridenour<EMAIL_ADDRESS>wrote:

I think this is a great reason to use flux. React shouldn't be trying to
share state or props when you can have a higher level store keep this
information for multiple components to connect to and use.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aksonov/react-native-router-flux/issues/864#issuecomment-229739332,
or mute the thread
https://github.com/notifications/unsubscribe/AAMWSN0Xa8Cc8BGpLTdkA5jQ0OajSK45ks5qRAQsgaJpZM4I-s0w
.

Is there a way to access the store from within onRight / onLeft? We are looking into performing a logout and would need access to dispatch.
Another use case we've encountered is uploading a collection of files onRight. Since we don't have access to the props or the store though, we can't even check if we should already display the button or not. At the moment we simply added this functionality at the entry point of the next scene and redirect back if there are no files.

Try this trick:
Scene:
<Scene key="members" component={Members} title="Members" onRight={(props) => props.onAdd && props.onAdd()} rightTitle="Add" />
component:
class Members extends React.Component {
componentDidMount() {
Actions.refresh({ onAdd: this.addMember.bind(this) });
}
addMember() {
const { project_id } = this.props.params;
Actions.memberadd( {params: {project_id: project_id}} );
}
render() {
const { project_id } = this.props.params;

return (
  <MembersList params={{project_id: project_id}} />
);

}
}
export default Members;

try this trick:
## Scene:
<Scene key="members" component={Members} title="Members" onRight={(props) => props.onAdd && props.onAdd()} rightTitle="Add" />

## Component:
class Members extends React.Component {
    componentDidMount() {
        Actions.refresh({ onAdd: this.addMember.bind(this) });
    }

  addMember() {
    const { project_id } = this.props.params;
    Actions.memberadd( {params: {project_id: project_id}} );
  }

  render() {
    const { project_id } = this.props.params;
     return (
      <MembersList params={{project_id: project_id}} />
    );
  }
}

export default Members;

I don't see why you can't access the store via onRight or onLeft. Since it's just a JavaScript function, everything available should be there - maybe there's a scoping problem in your case. If you post code we can try and help.


ratelimit option have not been parsed in FileDownloader

[x] I've verified and I assure that I'm running youtube-dl 2017.08.09
[x] At least skimmed through the README, most notably the FAQ and BUGS sections
[x] Searched the bugtracker for similar issues including closed ones

What is the purpose of your issue?

[x] Bug report (encountered problems with youtube-dl)

In https://github.com/rg3/youtube-dl/blob/master/youtube_dl/downloader/common.py#L176, rate_limit is still str and need to be parsed first.

https://github.com/rg3/youtube-dl/blob/master/youtube_dl/downloader/common.py#L34


Add check for nested liquid loops

There are instances where there are multiple liquid loops nested inside each other. These can clog the TTR.
Here is a bad example...
  {% for product in collection.products %}
    {% for tag in product.tags %}
      {% for variant in product.variants %}
        {% for collection in product.collections %}

        {% endfor %}
      {% endfor %}
    {% endfor %}
  {% endfor %}

Semi-related to the nested snippets logic.

closing as wont do


Verify or calculate offset from FileLength

Currently the code reads a "FileLength" attribute from the header, but this is currently unused.
https://github.com/janelia-cosem/fibsem-tools/blob/f4bedbfc4ff81ec1b83282908ba6702baf98c734/src/fibsem_tools/io/fibsem.py#L587
One use of this would be to verify or calculate the OFFSET location rather than assuming that it is at 1024. That is OFFSET == FileLength - np.prod(shape)*np.dtype(dtype).itemsize

As long as the offset is in fact a constant, I think we should continue to treat it that way in the .dat reader. As for doing a validation, unfortunately it's possible for data to be incomplete (due to some problem during acquisition), and then the file length couldn't be used to infer the offset. Rather, in this situation the offset is needed for validating the file length.

Perhaps we should actually record the offset somewhere then. It may be needed in case the metadata needs to expand.

Is the FileLength verified anywhere in this repository?


fix: update viewBox to 0 0 64 64

[FX-NNNN]
Description
exported svgs from figma has some inconsistent viewBox. I double checked with figma and it seems that there was issues in exporting by all svgs by plugin to include name-variant
How to test

CI is green
check storybook

Screenshots
n/a
Development checks

[x] Add changeset according to guidelines (if needed)
Read CONTRIBUTING.md and Component API principles
[x] Make sure that additions and changes on design follow Toptal's BASE design, and it's been already discussed with designers at #-base-core
Annotate all props in component with documentation
Create examples for component
Ensure that deployed demo has expected results and good examples
Ensure the changed/created components have not caused accessibility issues. How to use accessibility plugin in storybook.
[x] Self reviewed
Covered with tests

Breaking change

codemod is created and showcased in the changeset
test alpha package of Picasso in StaffPortal

All development checks should be done and set checked to pass the
GitHub Bot: TODOLess action

PR commands

List of available commands:

@toptal-bot run package:alpha-release - Release alpha version
@toptal-anvil ping reviewers - Ping FX team for review

PR Review Guidelines

When to approve? ✅
You are OK with merging this PR and

You have no extra requests.
You have optional requests.

Add nit: to your comment. (ex. nit: I'd rename this variable from makeCircle to getCircle)

When to request changes? ❌
You are not OK with merging this PR because

Something is broken after the changes.
Acceptance criteria is not reached.
Code is dirty.

When to comment (neither ✅ nor ❌)
You want your comments to be addressed before merging this PR in cases like:

There are leftovers like unnecessary logs, comments, etc.
You have an opinionated comment regarding the code that requires a discussion.
You have questions.

How to handle the comments?

An owner of a comment is the only one who can resolve it.
An owner of a comment must resolve it when it's addressed.
A PR owner must reply with ✅ when a comment is addressed.

@toptal-anvil ping reviewers


ImagesAPIViewSet query params for rendition?

Is your proposal related to a problem?

The problem is: it's not easy to seamlessly get renditions from the API without extra code within the Pages or Blocks.
Describe the solution you'd like
I'd like to just do something like this:
"get" /api/v2/images/1/?renditions=max-1200x1200,height-200
and the result would be something like this:
{
    "id": 1,
    "meta": {
        "type": "wagtailimages.Image",
        "detail_url": "http://localhost:9000/api/v2/images/1/",
        "tags": [],
        "download_url": "/media/original_images/processed-b7d09dd7-449a-4b96-9e1a-b3c471e4abad_m2p0kWLk_pcPaWKf.jpeg"
    },
    "renditions": {
        "max-1200x1200": "/media/....",
        "height-200": "/media/..."
    },
    "title": "processed-b7d09dd7-449a-4b96-9e1a-b3c471e4abad_m2p0kWLk",
    "width": 2522,
    "height": 3362
}

Additional context
I would create a PR for this if there's interest :slightly_smiling_face:  :+1:

It sounds like what you're describing is essentially the same thing as the image serve view: https://docs.wagtail.org/en/stable/advanced_topics/images/image_serve_view.html

I had a feeling you were gonna answer within 5 minutes :D
And I also figured something like this existed already. However it's not exactly what I'm looking for since either the user has to interact or I have to write extra code.
When I create a StructBlock that has an ImageChooserBlock, I eventually get the ID of that image back via the API.
Now in my frontend, it would be nice to then just query for the rendition, which can be different depending on my frontend context. I.e. on PageA.svelte I want fetch('/api/v2/images/1/?renditions=max-1200x1200'), on PageB.svelte I want fetch(/api/v2/images/1/?renditions=height-400).
Obviously if I only need a few different renditions I can just do that in my Block's get_api_representation, and the overhead is negligable.
I agree that my proposal has the flaw of any attacker being able to just flood the harddrive of any Wagtail-instance out there with renditions, however as an alternative proposal maybe we could just add a settings-variable that allows me to specify the renditions I might need?
But yeah: It's not a high-priority problem. Just an idea.

Thanks for the suggestion @andreasnuesslein
The problem with implementing something like this in the Wagtail API is it would make it easy for someone to overload a site by sending it lots of requests for images at random sizes.
I think we would need to either limit the options for what rendition sizes can be requested on the server side, or require signed URLs on the client side.
Wagtail already has both options built in, but this could be documented better and there currently isn't a code snippet or library that you could use to generate the signed URLs for the image serve view.

I think we would need to either limit the options for what rendition sizes can be requested on the server side, or require signed URLs on the client side.

Yeah. If I understand correctly, signing would imply the client to have a SECRET, which is tricky to keep secret in case of a pure frontend package. So I was also thinking maybe just a settings-variable that could apply system-wide to any instance of Images .
This way you'd just say "While building your frontend, you may specify a WAGTAIL_RENDITION_OPTIONS in settings so that any of these renditions might be requested at any time". In this case I'd even not do the whole GET-parameter stuff anymore but just deliver the rendition (options) within the response JSON directly

{
    "id": 1,
    "meta": {
        "type": "wagtailimages.Image",
        "detail_url": "http://localhost:9000/api/v2/images/1/",
        "tags": [],
        "download_url": "/media/original_images/processed-b7d09dd7-449a-4b96-9e1a-b3c471e4abad_m2p0kWLk_pcPaWKf.jpeg"
    },
    "renditions": {
        "max-1200x1200": "/media/....",
        "height-200": "/media/..."
    },
    "title": "processed-b7d09dd7-449a-4b96-9e1a-b3c471e4abad_m2p0kWLk",
    "width": 2522,
    "height": 3362
}

And as an semi off-topic follow-up: For consistency reasons it would be helpful to have a simple Serializer/Endpoint that always delivers the same format for Images. Does something like that exist already and I haven't found it?
What I mean is: Right now I have a CustomImage(AbstractImage) which brings this method:
    def get_api_representation(self, renditions=None):
        retval = {
            "id": self.id,
            "meta": {
                # "type": settings.WAGTAILIMAGES_IMAGE_MODEL,
                # "detail_url": ....
                "tags": self.tags.all(),
                "download_url": self.file.url,
            },
            "title": self.title,
            "width": self.width,
            "height": self.height,
            "caption": self.caption,
            "copyright": self.copyright,
        }
        if renditions:
            retval["renditions"] = {r: self.get_rendition(r).url for r in renditions}
        return retval

In my StructBlocks I then do
return { "picture": value.get("picture").get_api_representation(),...
  # or: .get_api_representation(["height-340"])

And for the Pages where I use my CustomImage, I have a custom serializer
class CustomImageSerializer(fields.Field):
    def to_internal_value(self, data):
        pass

    def to_representation(self, image):
        try:
            return image.get_api_representation()
        except SourceImageIOError:
            return {"error": "SourceImageIOError"}

Am I missing something that will simplify this? It feels quite boilerplate-y. I think that also inspired this ticket here.


Uninstalled ember-cli-template-lint and ember-cli-eslint packages.

Description( Issue No - #198 ):
In package.json, in scripts object, "lint" variable in scripts object
"lint": "npm-run-all --aggregate-output --continue-on-error --parallel lint:*"
npm run lint:hbs  & npm run lint:js all test are passed without any errors.
npm run lint all test are passed without any errors
Installed packages(as dev dependencies):
1. ember-template-lint
2. npm-run-all
3. eslint packages
Uninstalled packages:
1. ember-cli-template-lint
2. ember-cli-eslint

Your pull request description is a great start, I thought. I appreciated that you documented what you did (e.g. ran npm run lint:hbs) and what you saw (no errors).

@ijlee2 Required changes are made. Please review again.