ENH: Added a couple of minimal test-cases to the Affine constructor

Codecov Report

Merging #33 into master will increase coverage by 0.94%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #33      +/-   ##
==========================================
+ Coverage   87.77%   88.71%   +0.94%
==========================================
  Files           8        8
  Lines         507      505       -2
  Branches       69       68       -1
==========================================
+ Hits          445      448       +3
+ Misses         42       38       -4
+ Partials       20       19       -1

Flag
Coverage Δ

#unittests
88.71% <ø> (+0.94%)
:arrow_up:

Impacted Files
Coverage Δ

nitransforms/linear.py
74.41% <ø> (+4.18%)
:arrow_up:

nitransforms/base.py
98.37% <0%> (-0.82%)
: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 f39e6fd...fb3d2f3. Read the comment docs.


Update README.md

Added a couple more dependencies to the list since running a build based on the current set of components returns errors e.g "Cannot find module 'react-aria' or its corresponding type declarations."
I would assume tree-shaking would not include them in a production build. So it may actually be simpler to include them all, regardless of whether using the components that make use of them.

@gregmsanderson thanks for the readme update


Outline entries parsed incorrectly when cell comments (#%%) in class definition

Env:
Python 2.7.11 64bits, Qt 5.4.1, PyQt5 5.4.1 on Darwin
Class methods are parsed incorrectly if there is a cell comment (#%%) preceding the method definition line.

However, it works fine for normal functions outside the class definition:

Tried with
class Test:
# %% Test 1
    def f1(self):
        pass

# %% Test 2
    def f2(self):
        pass

    def f3(self):
        pass

And I get

Which looks ok. Closing.


allow schema types to be pluggable

this refactoring allows developers to add support of new schema types

@chingor13 , done!


remove unused code

Hello @Qazalin,
could you tell me why you closed it? I would appreciate feedback :)
I am running static analysis of tinygrad code and i have found that this is not used anywhere nor tested, so I think its good to remove that to decrease number of lines


Send event to Snowplow if sinking batch to S3 fails

Migrated from: https://github.com/snowplow/snowplow/issues/1505


Add Mauve to Galaxy Tools

Forgot note that we are missing a .shed.yml file. Example can be found here

@RichardDavidsonTheGreat , @Takadonet have you looked at https://github.com/galaxyproject/tools-iuc/tree/master/tools/progressivemauve ? Is that useful already?

@RichardDavidsonTheGreat , @Takadonet have you looked at https://github.com/galaxyproject/tools-iuc/tree/master/tools/progressivemauve ? Is that useful already?

The tool in progressivemauve in tools-iuc does not use the 'hidden' command of 'contig ordering and orientation relative to reference' .  This feature is available as a dropbox option in the GUI but not available on the command line when using binary   progressivemauve . Only way to call from the command line is using the Mauve.jar and directly call the function which is ugly.
This tool hack was developed years ago and only now moving toward using bioconda.


Failing tests

What happened?
TASK [ansible-node-exporter : Create node_exporter config directory] ***********
    fatal: [centos8]: UNREACHABLE! => {"changed": false, "msg": "Failed to create temporary directory.In some cases, you may have been able to authenticate and did not have permissions on the target directory. Consider changing the remote tmp path in ansible.cfg to a path rooted in \"/tmp\", for more error information use -vvv. Failed command was: ( umask 77 && mkdir -p \"` echo OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused \"process_linux.go:90: adding pid 28027 to cgroups caused \\\"failed to write 28027 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/docker/6bffe942ab289f6018c910fcb7b67957333e050d435ffbe3bbfedb72effead8d/cgroup.procs: invalid argument\\\"\": unknown/.ansible/tmp `\"&& mkdir OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused \"process_linux.go:90: adding pid 28027 to cgroups caused \\\"failed to write 28027 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/docker/6bffe942ab289f6018c910fcb7b67957333e050d435ffbe3bbfedb72effead8d/cgroup.procs: invalid argument\\\"\": unknown/.ansible/tmp/ansible-tmp-1595086095.7307746-27669-8276321652003 && echo ansible-tmp-1595086095.7307746-27669-8276321652003=\"` echo OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused \"process_linux.go:90: adding pid 28027 to cgroups caused \\\"failed to write 28027 to cgroup.procs: write /sys/fs/cgroup/cpu,cpuacct/docker/6bffe942ab289f6018c910fcb7b67957333e050d435ffbe3bbfedb72effead8d/cgroup.procs: invalid argument\\\"\": unknown/.ansible/tmp/ansible-tmp-1595086095.7307746-27669-8276321652003 `\" ), exited with result 1", "unreachable": true}

Did you expect to see some different?
A working test.
Maybe fix?
I think I had similar issues with Github Actions. Could be multiple things:

I remember that essentially the Docker in Docker failed because of the filesystem. You can't have overlay on overlay. One of them has to be vfs for example.
Or it's buggy Docker?
Or it's Travis-CI.

Should we try to fix this?

What is the environment for test execution?

CentOS8

I remember that essentially the Docker in Docker failed because of the filesystem

Tests are not aimed to be run with DinD, that's one of the reasons behind using tox. How to run tests is described already in readme at https://github.com/cloudalchemy/ansible-node-exporter#local-testing

Or it's buggy Docker?

Maybe. However, if you start any container and you are able to write to /tmp in it, then it is fine.

Or it's Travis-CI.

Travis CI works. We schedule VM-per-ansible version, inside VM we launch molecule tests where each target is separate docker container.

Should we try to fix this?

If running tox inside a clean repository doesn't work, then yes. If it works, then I don't see any bug.

https://travis-ci.com/github/cloudalchemy/ansible-node-exporter/jobs/363897218

Not sure what happened there. Any idea how to fix?

This is some sort of flakiness in molecule itself. I have no solution apart from hitting "restart job"

Should be fixed by recent migration to molecule v3 and ditching tox. If this is still an issue please reopen.


Update isDateValid function to use locale, add unit tests of the buggy dates

Unfortunately the unit tests failed to run because of an error in the karma config file, so it will be appreciated if you test the change carefully before merging the pull request.
Sincerely.

I will be happy if I can help

send me an email<EMAIL_ADDRESS>please.


Starting auto-instrument again encounters crash

Describe the bug
First of all I would like to say that this is a great program!
While playing around with it I noticed that when keeping the application running and starting the go-instrument program again, the auto-instrument crashes with the error that the directory already exists.
{"level":"info","ts":1704449313.7016501,"logger":"Instrumentation.Manager","caller":"instrumentation/manager.go:107","msg":"no functions found for probe, removing","name":"google.golang.org/grpc/client"} {"level":"info","ts":1704449313.701675,"logger":"Instrumentation.Manager","caller":"instrumentation/manager.go:107","msg":"no functions found for probe, removing","name":"google.golang.org/grpc/server"} {"level":"info","ts":1704449313.7017107,"logger":"go.opentelemetry.io/auto","caller":"cli/main.go:107","msg":"starting instrumentation..."} {"level":"info","ts":1704449314.4905517,"logger":"Instrumentation.Manager","caller":"instrumentation/manager.go:177","msg":"Mounting bpffs","allocations_details":{"StartAddr":140642395824128,"EndAddr":140642396217344}} {"level":"error","ts":1704449315.5017455,"logger":"go.opentelemetry.io/auto","caller":"cli/main.go:109","msg":"instrumentation crashed","error":"mkdir /sys/fs/bpf/93325: file exists","stacktrace":"main.main\n\t/workspaces/opentelemetry-go-instrumentation/cli/main.go:109\nruntime.main\n\t/usr/local/go/src/runtime/proc.go:267"} Process 110286 has exited with status 0 Detaching
I think that when acting as a sidecar for an application, the life cycle of auto-instrument and the application should be the same. So theoretically, it seems this is not a problem in use. However, for development and debugging, it still doesn't feel very convenient. It seems better to deal with it, what do you think, will this have other side effects?
Environment

OS: [ubuntu]
Go Version: [1.21.5]
Version: [main branch]

To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.

When stopping the instrumentation process using SIGTERM or SIGINT a proper cleanup should happen, however using SIGKILL will not. see https://github.com/open-telemetry/opentelemetry-go-instrumentation/issues/408#issuecomment-1784177965


Serving port configuraion issue.

Thank you very much for providing such a powerful video server !  I just gave up using BBB as your product is far more lightweighted.
Just one quesion,  cloud it be possible to server from non-443 port？ This port is usually used by Ngnix.  Currently BBB doesn't provide non-443 port solution, so I want you know how your  team deal with it.
If it can be adjusted, how?  Thanks a lot !

Thank you. Yes, plugNmeet can be setup to work with any port but you'll require to make proper port forwarding. If you're using our installer then it will setup haproxy & proxy the connection to plugNmeet & livekit. If you want to setup haproxy in different port then will be the easiest way.
https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/haproxy_main.cfg#L61
During that time you'll require to change URL in different config files as well as. Like:
https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/livekit.yaml#L30
https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/config.yaml#L36
https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/config.yaml#L96

Thank you. Yes, plugNmeet can be setup to work with any port but you'll require to make proper port forwarding. If you're using our installer then it will setup haproxy & proxy the connection to plugNmeet & livekit. If you want to setup haproxy in different port then will be the easiest way.
https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/haproxy_main.cfg#L61
During that time you'll require to change URL in different config files as well as. Like: https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/livekit.yaml#L30 https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/config.yaml#L36 https://github.com/mynaparrot/plugNmeet-install/blob/1364f0ec594ad2f1db1a2ab015b37658b62023dc/install-files/config.yaml#L96

Thank you Jibon, but have you tried it? I've been tried several times but never succeeded.

but have you tried it?

If I wasn't tested then I shouldn't give you the solution. It's very easy to configure Haproxy but you should have knowledge on it. For my case I just change port & everything was smooth. That is why in the installation we mentioned about clean server without preinstalled apache or nginx.

Hii @jibon57 ,
Need to help for server configuration.


Add better user feedback when submitting forms

Make a better system for informing the user, that what they just did either failed or succeeded. This system needs to be placed both in frontend and backend.
Right now, no information is given to admin users editing forms.
Maybe the javascript "informationAlert" could be used, it is a custem information window developed by me, but it has it downsides.

Have added a better user feedback system, with the addition of more validation from #24 in fbfd30f

Updated in c4ebf1c


Fix bug adjusting inventory

Coverage remained the same at 27.556% when pulling 3d68bf0debb5e25ca430425af54041413837f155 on inventory into b6c8ebf8ae17b5a4caf73814ce49520541eae617 on master.


Critical issues before stabilization

I wanted to put together a more technical list of issues to be solved before we can stabilize (see rust-lang/rust#86656).
There are many more important issues like performance on some targets, or important missing functions, but IMO those don't prevent stabilization.  In this list I've trimmed down the issues to major API-related issues that can't be changed, or are difficult to change, after stabilization.
Issues to be solved

Restricting the number of lanes.  In my opinion, the LaneCount<N>: SupportedLaneCount bound makes the API exceptionally cumbersome.  I've also had some trouble writing generics around it, particularly when making functions that change the number of lanes (the trait solver sometimes simply fails).  Adding the bound often feels like boilerplate, and I found myself looking for ways to launder the bound, like adding unnecessary const parameters.  Making this a post-monomorphization error (I found rust-lang/lang-team#195 helpful) might be the way to go, or perhaps there's a way to make a const fn panic.  Cons: the trait bound is very explicit and hiding the error states could possibly do more harm than good when identifying the source of a build failure.
Mask element type.  I'm not confident that the mask type for Simd<f32, N> should be Simd<i32, N> (see rust-lang/portable-simd#322 for discussion).  I think it would be much more straightforward if the types simply matched. Cons: this would require an extra cast when using i32 masks for f32 vectors or similar, and makes implementing From<Mask> for Mask impossible (since pointer masks must be generic Mask<*const T, N>, maybe all pointers could use the same mask element?).
Swizzle functions.  They're difficult to use and not a very good API, but Rust doesn't currently allow for anything much better. We could hold off stabilizing arbitrary swizzles, but that's a big limitation.

Non-issues, but things that should be done

Are we happy with the traits the way they are? e.g. SimdPartialEq, SimdInt.
The API should be partitioned into multiple unstable features that can be stabilized independently.

Updates (after filing this issue)
Lane count

I tried condensing LaneCount an SimdElement into a single bound Simd<T, N>: Supported.  This doesn't work well for a variety of reasons.  One example: scatter/gather use Simd<T, N>, Simd<*const T, N>, and Simd<usize, N>.  Each of these would need their own bound, rather than using one LaneCount bound since they all share N.
I recommend either keeping the bounds as they are now (LaneCount and SimdElement) or turning LaneCount into a non-local error.

Swizzles
I tried the following swizzle code.  It requires the incomplete adt_const_params feature.  Even with this feature enabled, it's impossible to implement functions like reverse, because const generics can't access the generic const parameters.

    pub fn swizzle<const M: usize, const INDEX: &'static [usize]>(self) -> Simd<T, M>
    where
        LaneCount<M>: SupportedLaneCount,
    {
        // SAFETY: `self` is a vector and the swizzle index is a const array of u32
        unsafe {
            intrinsics::simd_shuffle(
                self,
                self,
                const {
                    assert!(M == INDEX.len(), "`M` must equal the length of `INDEX`");
                    let mut r = [0; M];
                    let mut i = 0;
                    while i < M {
                        assert!(
                            INDEX[i] < N,
                            "indices must be less than the input vector length"
                        );
                        r[i] = INDEX[i] as u32;
                        i += 1;
                    }
                    r
                },
            )
        }
    }

w00t! Very excited to see this. :D :D :D

Are we happy with the traits the way they are? e.g. SimdPartialEq, SimdInt.

Is there high level docs anywhere describing how the API is laid out? Like, a guided tour of everything? I realize that's a tall order to ask for before the API is set in stone because it takes work to stabilize. But I'm asking because as of right now, I find the API to be very overwhelming. There are a lot of traits and upon seeing them, I immediately wonder how they all fit together. And in particular, why they exist. That is, if the API were less trait heavy, what would we lose?
Looking at the names of the traits, I can make some guesses as to what some of them are for. And it looks plausible that they could all mostly be explained (at a high level) without too much exposition.
I have opinions on the names of the traits too, but I think that fun can be saved for later. :P
I find the number of concrete types to be large but not overwhelming. At a quick glance, I can immediately understand what they mean and what connects them. While I do have some light SIMD background, I'm confident that the large number of concrete types could be explained by a ~paragraph in the crate docs.

The API should be partitioned into multiple unstable features that can be stabilized independently.

Do you have a 50,000-foot view of what the partitioning might look like? I don't mean to put you on the spot and ask for a detailed proposal, but just a general feeling of what you think might make sense.

Swizzle functions. They're difficult to use and not a very good API, but Rust doesn't currently allow for anything much better. We could hold off stabilizing arbitrary swizzles, but that's a big limitation.

I agree that missing swizzles is a rather large limitation. For me personally, unless there is a language feature that you're pretty confident is right at the horizon, or if there's a small language feature that you can get the lang team on board with quickly, I would go to war with the army you have when everything else is ready to stabilize. But this is just a general sense of things personally, and I'm sure there is a deeper analysis that could be done here. e.g., "If Rust had language feature Foo, then the swizzle API could be written like this which would make things simpler and/or unlock new use cases."

e.g., "If Rust had language feature Foo, then the swizzle API could be written like this which would make things simpler and/or unlock new use cases."

that would be: if LLVM had dynamic swizzles (using the shuffle LLVM IR instruction), then we could just have the swizzle pattern be a function argument and rely on inlining and const-propagation, like we do with atomic orderings (technically we could do that to some extent in rustc, but it really should be in LLVM).

Is there high level docs anywhere describing how the API is laid out?

Nope, that's definitely something we should have.  Personally, I think we could use more submodules to make the division a little clearer.  Each of these could be documented independently, with a bit of guidance in the main std::simd module:

Simd, Mask, and the various aliases in std::simd
num containing SimdInt, SimdFloat, etc
ptr containing SimdConstPtr and SimdMutPtr
cmp containing SimdPartialEq etc
swizzle containing Swizzle, Which, etc

That is, if the API were less trait heavy, what would we lose?

The original implementation had no traits.  This results in two related issues.  To implement recip, you need impl Simd<f32, N> and impl Simd<f64, N> and end up with two identical (but separate in docs) recip functions.  For integers this is even more verbose and distracting.  The second issue is that you now have overlapping functions, e.g. recip (for floats), count_ones (for ints) and wrapping_add (for pointers) all implemented on the Simd type.  With traits, we were able to put generic vector functions on Simd and leave anything element-type-specific to a trait.

The API should be partitioned into multiple unstable features that can be stabilized independently.

Do you have a 50,000-foot view of what the partitioning might look like?

Offhand, I would say something like:

portable_simd_types: just Simd, Mask, and a handful of generic functions (these types implement Add, Sub, etc)
portable_simd_swizzle if we want to split off swizzling for later
portable_simd_scatter_gather: scatter/gather is another fairly complicated API we might want to hold back
portable_simd_traits: for all of the traits above, once we're comfortable with how they're divided up etc

I agree that missing swizzles is a rather large limitation. For me personally, unless there is a language feature that you're pretty confident is right at the horizon, or if there's a small language feature that you can get the lang team on board with quickly, I would go to war with the army you have when everything else is ready to stabilize.

One option might be to implement a slightly less powerful set of swizzle2<I0, I1>, swizzle4<I0, I1, I2, I3>, etc functions that are not quite as powerful as we'd like (impossible to make generic over N) and wait on stabilizing the completely generic interface for when we can do something like fn swizzle<const N: usize, const I: [usize; N]>() or perhaps something even better.

That is, if the API were less trait heavy, what would we lose?

Realistically we'd probably gain things. As it is, there are a number of APIs that have been hard to add due to the need to make them fit into the trait-heavy design.
That said, my stance here (that we should not have gone with the traits as it's lead to a cumbersome and inflexible design) is not a popular one, so YMMV.

As far as restricting the number of lanes goes, I tried combining the bound into something like:
pub struct Simd<T, const N: usize>(...) where Self: Supported;

In theory, this seemed like a good compromise between the current verbose bounds and using a non-local error.  In practice, it wasn't really possible to implement this.  It turns out we use the separation between the element bound (SimdElement) and the lane count bound (SupportedLaneCount) in a fair number of places.  For example, functions that use multiple vector types, such as scatter/gather, require the bound for each type, which actually ends up more verbose. (Currently, they all share a lane count bound).  Even worse, functions that only use another vector type internally (like Simd<usize, ...> in functions that take pointer vectors) need the extra bounds and leak implementation details.
After this experiment, I think the best option is to add two new compiler attributes like #[portable_simd_max_elements(N)] and #[portable_simd_require_power_of_2_elements], which error when unsupported lane counts are used.

could we just use:
impl<T: ..., const N: usize> Simd<T, N> {
    const VALID: () = {
        let valid = N > 0 && N < 64;
        if !cfg!(all_lane_counts_iirc) {
            valid &= N.is_power_of_two();
        }
        assert!(valid, "invalid lane count");
    };
    pub fn each_method(self, ...) -> ... {
        Self::VALID; // use so it triggers a post-mono error
        ...
    }
}

actually, no, we can't, since just copying a Simd type requires a supported lane count.

Also, it would be easy to accidentally forget

since just copying a Simd type requires a supported lane count.

Any chance we'd be willing to say that we're ok allowing the type to exist for non-PoT lane counts, but then just not offering anything other than Copy and the array conversions with them?  Then it's fine that we don't have a good way to do + or shuffle for Simd<f32, 21>, but we don't force it to be bound everywhere just to exist...
(But I guess that exposes layout questions that we don't want to decide just yet, even if we left them explicitly unspecified.)

it would be easy to accidentally forget

We could maybe have a -Z flag to ICE on non-power-of-two vectors in the codegen, or something, to help catch it.

since just copying a Simd type requires a supported lane count.

Any chance we'd be willing to say that we're ok allowing the type to exist for non-PoT lane counts, but then just not offering anything other than Copy and the array conversions with them?

we already have a feature flag to enable non-pot lane counts, the main issue imo is that someone could try to use Simd<T, 1234567> which should error for being too big. or Simd<T, 0> which is a pain therefore not allowed (though I'm ok with adding it for the consistency benefits).

Also, removing the bounds from Simd but not impl Simd doesn't help us much, I think.  In my experience, the bounds are no problem when writing code with "concrete" SIMD types, but painful when trying to do anything generic.  If functions still require them, those generics will still be difficult.

we already have a feature flag to enable non-pot lane counts, the main issue imo is that someone could try to use Simd<T, 1234567> which should error for being too big. or Simd<T, 0> which is a pain therefore not allowed (though I'm ok with adding it for the consistency benefits).

There is precedent with [T; HUGE] erroring, so I think we may be able to do the same if we can remove the non-PoT bound as well.

we already have a feature flag to enable non-pot lane counts, the main issue imo is that someone could try to use Simd<T, 1234567> which should error for being too big. or Simd<T, 0> which is a pain therefore not allowed (though I'm ok with adding it for the consistency benefits).

the other issue I forgot is that imo non-pot lane counts have the wrong layout and that should change: https://github.com/rust-lang/portable-simd/issues/319

the main issue imo is that someone could try to use Simd<T, 1234567> which should error for being too big

This one I feel strongly isn't a problem, since [T; isize::MAX as usize] has exactly the same issue, and I don't think that being a non-local error has really ever been a problem.  (I elaborate more on that train of thought in https://github.com/rust-lang/rust/pull/104087#issuecomment-1453028838 )
So long as using Simd like this gives the same kind of error as we get for arrays in https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=a8752e42c5601f574d948ff3677a7e0e, that seems entirely acceptable to me.  (Saying that with my lang hat on, but not speaking for the team, since I don't think we've discussed Simd in particular.)

or Simd<T, 0> which is a pain therefore not allowed

I would love to have even a hacky solution to this.  as_chunks is blocked on exactly the same thing (https://github.com/rust-lang/rust/issues/74985).
lcnr had some thoughts on doing something like this in https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/How.20essential.20is.20the.20compile-time.20check.20for.20empty.20arrays.3F/near/248387965.  Maybe someone could pick that up to deal with the zero problem for a while?  If it was easier, Simd<T, 0> feels like another of those places where we might do "the type is well-formed but hard to use".

but painful when trying to do anything generic

I suppose that's another possibility here -- explicitly decide to have v1 of stabilizing this not allow writing generic code over them, but still let people use specific versions when implementing stuff.
That seems like it'd still be pretty useful, since using f32x4 in the implementations of stuff is still much easier even if I can't be generic over stuff yet.

Also, removing the bounds from Simd but not impl Simd doesn't help us much, I think.

My proposal of using Simd::CHECK would only have type bounds, all lane count bounds would be post-mono errors only.

I love the current state of this project and am grateful for the hard work being done and the general friendliness/helpfulness of the team.
However, I will be a bit of a contrarian and say that swizzles are important to me, particularly dynamic ones. I've also used the APIs with the const swizzles at length, and it's workable: you can use const fn to generate special index patterns provided you are willing to write some boilerplate to make it ergonomic.
I'm not saying swizzles should stop stabilization per se, I'm a very happy nightly user.
I'll also be contrary and say that it's okay to abstract more functionality for very common use cases. I think some of this is already done, but I wouldn't be sad, for example, to see a function to map bytes using dynamic swizzles. The newbie user (like me) may not realize the hardware limitations (the usual size of look-up tables, for example) of certain operations and so creating a well-designed function for a common use case is a good thing to me.

I agree that a satisfying story for swizzles is important.
Regarding traits, I initially proposed it as a way to reduce the "multiplication of entities" problem so that it's easier to follow things. I have begun to think a different approach may be appropriate, but I believe we should probably fork further discussion about that into its own issues/threads.

My 2c is that if Rust's primitive types cannot currently be abstracted over with traits (other than Add etc), it's not necessary to be able to do it for SIMD types either at first. Indeed it would be strange if a workaround for the lack of numeric traits was to wrap your numbers in SIMD and use SIMD traits instead…

My 2c is that if Rust's primitive types cannot currently be abstracted over with traits (other than Add etc), it's not necessary to be able to do it for SIMD types either at first. Indeed it would be strange (and slightly amusing) if a workaround for the lack of numeric traits was to wrap your numbers in x1 SIMD and use SIMD traits instead…

Personally, I don't see a way around using traits. This was one of the first issues we hashed out, I'm sure there is more discussion available in zulip. SIMD types are not just numbers and not just arrays, they act like both simultaneously.  Like arrays, SIMD vectors have container-like operations that are only concerned with their memory layout and are indifferent to their element type.  This includes splatting, indexing, swizzles, scatter, gather, conversions to and from arrays and slices.
To undo this means that you will have 14 vector types that each implement these functions separately, and there will be no way in the future to ever treat a vector like an element-agnostic container.  A comparison would be like if [i32; 4] and [f64; 4] were totally independent types that couldn't both be used as [T; 4].
Using traits allowed us to treat vectors as containers (which they are) while also giving them element-specific behavior.  The element-specific functions can't be implemented directly Simd for each element type (they end up having name collisions and the docs are impossible to read), so any alternative to traits would need to account for this.

Can we add "documentation and review of the intrinsics' safety requirements" to the list? Currently every time I want to implement one of these in Miri I have to dig through PRs and then usually still go ask people. Intrinsics are language extensions so they should be reviewed by t-opsem. I also think the intrinsics' declarations should be moved into libcore so that they can be equipped with doc comments that live in the same repository as the codegen and Miri implementations that turn those doc comments into reality.

Yes, I intend on doing just that.

I opened #381 to track that

I strongly support checking lane count post-monomorphization. It's quite a hassle to carry around bounds proving that not only N but also N * 2, N / 4, etc are all valid lane counts (and I hit some ICEs along the way https://github.com/rust-lang/rust/issues/126443)

It's quite a hassle to carry around bounds proving that not only N but also N * 2, N / 4, etc are all valid lane counts

if you want to use a function fn f<const N: usize>(a: Simd<u8, N>) -> Simd<u8, { 2 * N }> you'll need some bounds regardless of if we handle element count limiting post-monomorphization or not, since those bounds are needed for any const-generic type, e.g. for arrays:
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=6320749ac371c3aef86ad1c1316d4cdd

related conversation about generic const exprs maybe gaining support for N.div_ceil(8) which would allow us to calculate bit vector sizes from lane counts: https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/Layout.20in.20const.20parameters/near/448743588

Why can't any number of lanes be supported, by using as many native SIMD vectors as needed, and masking for operations that need it?

The simple answer is that the size limitations are not related to native SIMD register sizes, but codegen backend encoding limitations.  We further restrict to even smaller sizes that we are confident operate correctly and optimize well. Our design allows for increasing the maximum in the future.

The codegen backend encoding limitations can be easily solved by having the std::simd implementation code-generate Simd<T, N> as an array of either T (with higher alignment) or a backend SIMD type and implement operations as loops that operate on parts of it with appropriate size for current SIMD ISA.
Given that this transformation is very simple and that not doing it is very burdensome for the API user, I don't see any reason to provide an API that doesn't perform it.
If the user uses a proper SIMD size, then the transformation will be a no-op and performance will be optimal; otherwise, the code will still work albeit less efficiently in some cases.

More precisely, doing something vaguely like this:
struct Simd<T, N>([<T as SimdArray<N>>::Type; N / <T as SimdArrayN>>::Length]);

default impl<T, N> SimdArray<N> for T {
  type Type = T;
  type Length = N;
}

// for AVX
impl<f32, N> SimdArray<N> for T
  where N <= 4 {
  type Type = __m128;
  type Length = N;
}

impl<f32, N> SimdArray<N> for T
  where N > 4 {
  type Type = __m256;
  type Length = (N + 7) / 8;
}

impl AddAssign<Simd<f32, N>> for Simd<f32, N>
where T: SimdArray<N, Type = __m128>
{
   fn add(&mut self, b: Self) -> Self {
     for i in 0..T::Length {
        self[i] = addps(self[i], b[i])
     }
   }
}

impl AddAssign<Simd<f32, N>> for Simd<f32, N>
where T: SimdArray<N, Type = __m256>
{
   fn add(&mut self, b: Self) -> Self {
     for i in 0..T::Length {
        self[i] = vaddps(self[i], b[i])
     }
   }
}

Or something like this:
#[align(simd)] // where the compiler chooses the alignment
struct Simd<T, N>([T; N]);

impl AddAssign<Simd<f32, N>> for Simd<f32, N>
where N <= 4
{
   fn add(&mut self, b: Self) -> Self {
        transmute::<_, &mut __m128>(&mut self)[0] = addps(transmute::<_, &mut __m128>(&self)[0], transmute::<_, &__m128>(&b)[0])
   }
}

impl AddAssign<Simd<f32, N>> for Simd<f32, N>
where N > 4
{
   fn add(&mut self, b: Self) -> Self {
     for i in 0..(N + 7)/8 {
        transmute::<_, &mut __m128>(&mut self)[i] = vaddps(transmute::<_, &mut __m128>(&self)[i], transmute::<_, &__m128>(&b)[i])
     }
   }
}

i.e. you could fix the codegen backend to support arbitrary sizes.

Simd is translated directly to LLVM IR vector types, theoretically LLVM supports arbitrary sizes, but really only expects you to use native vector sizes and generates terrible code for very large vector types (e.g. generating 10000 vector add instructions instead of a loop). LLVM also is quite a bit more likely to encounter bugs for weird vector sizes. the general idea is that people using Simd should use a smallish size and if they need to process more data, write an explicit loop into their algorithm.

The codegen limitations are something like 2^16 max elements, which is large enough that I doubt it's necessary to support anything larger. Something like this would make it possible to exceed that limit but I'm not sure it's worth the added complexity. We will likely be able to lift the current limit to something much larger if we can get reliable non-power-of-two-length codegen, but that's proving problematic for now.

generates terrible code for very large vector types (e.g. generating 10000 vector add instructions instead of a loop)

e.g. terrible code LLVM generates for a Simd<f32, 400> addition: https://llvm.godbolt.org/z/6r6EfjjfE

I guess the downside of this approach is that it allows the user to write "a + b + c" which will result in two loops, and unless the backend optimizer manages to fuse the loop, that code will be much worse than a single loop since it unnecessarily writes and reads the intermediate result to memory.
So maybe another option to solve the "LaneCount: SupportedLaneCount" issue is to leave the design as-is, but specify that users should generally never use Simd directly, and instead use an API providing a "SIMD array", "SIMD Vec" and "SIMD iterator" on top of it, which could either be the standard library or a 3rd party crate.
The iterator based design could still implement arithmetic on iterators, so you could write something like "collect_into(&mut result, a.iter() + b.iter() + c.iter())".

generates terrible code for very large vector types (e.g. generating 10000 vector add instructions instead of a loop)

e.g. terrible code LLVM generates for a Simd<f32, 400> addition: https://llvm.godbolt.org/z/6r6EfjjfE

As always, this depends on your choice of CPU. If Rust used target-cpu=native by default...
https://llvm.godbolt.org/z/xjsndxc1b
I agree that we are constantly fighting with dreadful LLVM codegen, regardless of the target.
My libm library was plagued by the need to generate vroundps which LLVM is incapable of.

As always, this depends on your choice of CPU. If Rust used target-cpu=native by default...

all that does is increase the upper limit for somewhat reasonable code, if using a 4000 element vector you go back to terrible code: https://llvm.godbolt.org/z/Wf9o5jT67

I'm using a personal arbitrary-length wrapper layer. A couple notes

making this API is strictly harder than making an api for fixed-length native arrays (without simd) which is already a massive pain. E.g. writing functions like these requires propagating N * 2, N / 4, etc. bounds through your entire codebase, and simd can only make it harder.

fn repeat_twice<const N: usize>(x: [u32;N]) -> [u32;N * 2]) { mem::transmute([x, x]) }
fn reinterpret_u16_as_u64<const N: usize>(x: [u16; N]) -> [u64; N / 4]) { mem::transmute(x) }

"bitmask" apis need overhaul because u64 is no longer guaranteed to fit all the bits - you want something like [u8; N / 8] which again requires carrying around the N / 8 bound

some instructions inherently cannot be scaled up to arbitrary lengths, e.g. _mm512_conflict_epi32 , which does a quadratic number of comparisons (roughly, every lane compared with every other lane). I guess such operations could have additional bounds on them without affecting the rest of the api?

if a vector is size 48, should it be processed as a chunk of size 32 and then a chunk of size 16, or three chunks of size 16? Should the user be able to control this choice? If the user can choose, than maybe the representation should instead be e.g. [[u32; CHUNK_SIZE]; N / CHUNK_SIZE] with user-controlled CHUNK_SIZE where LaneCount<CHUNK_SIZE>: SupportedLaneCount

They're difficult to use and not a very good API, but Rust doesn't currently allow for anything much better. We could hold off stabilizing arbitrary swizzles, but that's a big limitation.

Considering that shuffles/swizzles with compile-time-constant lane indices have worked in since at least 2015 without substantial change to the API shape, I think it's well past time to stabilize the API shape that exists.
So I think it makes sense to stabilize the simd_swizzle! macro and if an API that's perceived to be better becomes possible later, it's then possible to introduce another API alongside the simd_swizzle! macro later.

Portable SIMD has taken a substantially different approach to swizzles than e.g. the x86 shuffle intrinsics.  We really wanted to avoid a magic const argument that predates const generics and it's important to be able to generate the control mask with a const fn.  This has resulted in a rather clunky but functional Swizzle trait.
It should be safe to stabilize simd_swizzle! (at least once other things are stabilized), but my biggest concern is that we may need to then keep two swizzle implementations around, because the macro is fairly sensitive to the type deduction of its implementation.

Why is this even using a trait? If that's just to work around making the final argument const, then I think this can be expressed much better with a const { ... } block.
However, that would still expose the underlying simd_shuffle intrinsic fairly directly, so -- we'd have to be very careful here with stabilization.

We can't expose the intrinsic directly because we do some manipulation of the const indices before passing them into the intrinsic--passing it via an associated const allows it to be used in regular rust since it isn't bypassing the usual type system.

You should be able to do the same manipulation inside the const { ... } block.

I think I'm following... but do we want more const args? I think I even saw an issue somewhere encouraging const args to be removed in an edition change or something, I'm not sure where they stand right now.

Oh I see, the problem is that the macro shouldn't call simd_shuffle directly but wrap it in a function, and then the question is how does the function receive the index list as a constant. Ideally it would be a const generic but those are quite limited...

I think it's possible to write a macro something like the following (I have a prototype):
fn some_swizzle<T, const LEN: usize, const PARAM1: usize, const PARAM2: usize>(x: Simd<T, LEN>) -> Simd<T, LEN> {
    simd_swizzle!(x,
        const { /* some expression using LEN, PARAM1, PARAM2 */ },
        len = LEN,
        const_parameters = (PARAM1, PARAM2),
    )
}

But is something like this any better than implementing the Swizzle trait?  I'm having trouble imagining an idiomatic interface for this macro, but it takes away the need to understand some const generics type inference magic you need to understand to implement it.


Sharing Intent in Task Fragment does not work

There is a broken reference on line 185 under onOptionsItemSelected() method.
case R.id.menu_share:
                String email = PreferenceManager
                        .getDefaultSharedPreferences(getContext())
                        .getString("email_text", "");

"email_text" should match android:key="email_edit_text" found in pref_general.xml

Please note the above correction is needed in order for students to follow Chapter 8 exercise 20 (3 and 4) on page 189.
Thanks


Delete FeatureLayerDefinitionexpression directory

This sample was enhanced and renamed to FilterByDefinitionExpressionOrDisplayFilter. This instance is no longer valid and needs to be removed. All references to FeatureLayerDefinitionExpression were previously removed from the sample viewer.
issue: https://github.com/ArcGIS/afd-native-apis-doc/issues/2027

@JamesMBallard Good catch, just created a PR to remove this from v.next too


http client doesn't return none when the user is not found

instead the result gives an error and you need to drill down 3 layers to find the status code

this happens to all http calls where discord can return a 404, not just users


ps4 controller

hoe moet ik mijn dualshock 4 verbinden met mijn pc?

#620
you are probably trying to use the obsolete version if you are downloading from this Jays2Kings/DS4Windows site. Read the linked post and follow the link to up-to-date version of DS4Windows app.


fix code generation

Summary
Due to binary arrays in serialization, custom serde functions were created for marker and metadata modules. These have been required to be reapplied on any code generation run since they become overwritten.
Proposal
Update the code generation to apply these custom serde functions so that it does not manually need to be recreated on each proto version bump and generation

For Admin Use

[x] Not duplicate issue
[x] Appropriate labels applied
[x] Appropriate contributors tagged
[x] Contributor assigned/self-assigned

closed by #153


Adding initial draft of new module

what

First pass at new module to enable the automation of provisioning Terraform Cloud/Enterprise
Enables the user to specify workspace/environment configurations in YAML and have everything provisioned in TFE/TFC!

references

closes #1

/test all

/test all

/test all


Port to Python 3

Begin porting Python code from Python 2.7 to Python 3
Files to port:

run
tasks/bill_info.py
tasks/bills.py
tasks/govinfo.py
tasks/votes.py
tasks/utils.py

[ ] check list item


Fix bug. For example, we start the process for the first time. The pi…

…d is 12345. Due to the accident, the process is killed and the fe.pid exists. Then we start the process for the second time. The pid is 6789. The fe.pid shows 67895 , Because file.write only cover the first four digits. This case can happen easily when we use supervise. Then I add the file.setLength(0) and delete the old data.

PR is commited now

PR is commited now

Thanks for your contribution


"Wallet > Send :: Search" not working

Not seeing any network calls either

Probably a similar issue with missing resolves

Are there multiple issues re: missing resolves?
It looks like in December, useEffects that did resolving were taken out of claimPreview (for example, maybe others), and a withResolvedClaimRender HOC was made to sort of take its place at the page level.
I'm currently thinking of a useResolve effect somewhere.
Was there a strong opinion that a claim preview should definitely not be responsible for resolving its URI?
I could, for example, place this in effect in walletSend (after rewriting class component to functional).

Not sure why it was done this way, Rafael seemed to think it was the right way. Let's just add whatever way is easier and makes the most sense.


QGAN gives very bad results in Qiskit Aqua 0.8.1 and good results in Qiskit Aqua 0.7.3

Information

Qiskit Aqua version: 0.8.1 and 0.7.3
Python version: The one on the IBM Quantum Experience
Operating system: The one on the IBM Quantum Experience

What is the current behavior?
The same example of QGAN training works well with an old version of Qiskit Aqua (0.7.3) but gives very bad results with Qiskit Aqua 0.8.1
In fact, when run on Aqua 0.8.1, the code below achieves relative entropy equal to 0.1567 while the same code reaches relative entropy equal to 0.0034 with Aqua 0.7.3 (I tried this in two different computers with that olde version of Aqua)
This is the graph of the relative entropy with Aqua 0.8.1

This is the graph of the relative entropy with Aqua 0.7.3

Steps to reproduce the problem
Run this code:
%matplotlib inline
import numpy as np
import matplotlib.pyplot as plt
from qiskit import Aer
from qiskit.aqua import QuantumInstance
from qiskit.aqua.algorithms import QGAN
np.random.seed(2020)
N = 1000
real_data = np.random.binomial(3,0.5,N)
n = 2
num_qubits = [n]
num_epochs = 100
batch_size = 100
bounds = [0,3]
qgan = QGAN(data = real_data,
num_qubits = num_qubits,
batch_size = batch_size,
num_epochs = num_epochs,
bounds = bounds,
seed = 2000)
quantum_instance = QuantumInstance(backend=Aer.get_backend('statevector_simulator'))
result = qgan.run(quantum_instance)
print(result)
plt.title('Relative entropy evolution')
plt.plot(qgan.rel_entr)
plt.show()
What is the expected behavior?
The results should be similar (and with decreasing entropy, as in Aqua 0.7.3) in both versions of the library
Suggested solutions
Maybe there is some change in the default parameters from one version to another?

@Cryoris Can you check the uncertainty models?

@Cryoris were the uncertainty models investigated - I assume this issue is still present in the code?

@Cryoris were the uncertainty models investigated - I assume this issue is still present in the code?

That's actually a bug in TwoLocal where using circular entanglement on a 2 qubit circuit produces this
     ┌───┐┌──────────┐      ┌──────────┐
q_0: ┤ H ├┤ RY(θ[0]) ├─■──■─┤ RY(θ[2]) ├
     ├───┤├──────────┤ │  │ ├──────────┤
q_1: ┤ H ├┤ RY(θ[1]) ├─■──■─┤ RY(θ[3]) ├
     └───┘└──────────┘      └──────────┘

instead of
     ┌───┐┌──────────┐   ┌──────────┐
q_0: ┤ H ├┤ RY(θ[0]) ├─■─┤ RY(θ[2]) ├
     ├───┤├──────────┤ │ ├──────────┤
q_1: ┤ H ├┤ RY(θ[1]) ├─■─┤ RY(θ[3]) ├
     └───┘└──────────┘   └──────────┘

Since the QuantumGenerator uses TwoLocal(.., entanglement='circular') if no generator circuit is given this breaks the QGANs in the two qubit case. Explicitly using the second one with only one CZ produces the right convergence:

I'll open a PR in Terra to fix the TwoLocal there.

The reported problem has been corrected by the Nlocal fix in Terra, thanks @Cryoris, so I am closing this.


✨ Introducing StarkPass

add StarkPass

Hey @Giwook-Han thanks for your contribution, can you please fix the linter ? (npm run lint --fix or yarn lint --fix)

Thanks for the comment @0xlny! checked and fixed it

Sorry for the inconvenience. Can you check this again?/


lit skill component changes

see https://github.com/SkyCryptWebsite/SkyCrypt/pull/938#pullrequestreview-799561431 for more details

thanks! I didn't have time to look through this during the weekend and today but I will tomorrow 😄

Thanks!


Fix issue 794

This pull request fixes an issue https://github.com/pallets/jinja/issues/794, https://github.com/pallets/jinja/issues/244, https://github.com/pallets/jinja/issues/751 and issues related to revindex and length of iterable objects

Something got messed up here. You changed the base on GitHub, but you also need to rebase your commits onto that base too, then force push.

You're still pulling in all the commits from the master branch.

This PR can be closed, I just created new one with the correct base branch

Wrong base branch


Calibration of sensor

Is the Multichannel_Gas_sensor V2 factory calibrated and also if do we have to calibrate it again as given in the V1 of the sensor.

No, it's all calibrated out of the factory.


Update the game over message

Update the game over message so people know how to play again!

Because you created the pull request, you can't assign yourself as a reviewer, but feel free to assign a friend as a reviewer instead to see how it works 😄


Reset stdio in tests

At some point we had this functionality, but at some other point it broke with lots of refactoring around it. I couldn't pin point exacly where.
This PR adds that functionality to the Stdio mod and uses it in tests.

Need a rebase

this commit was merged as part of #250 .


Feedback for G2C Module 01

Module 01-Introduction
Spelling:

In the workshop scenario section:
04 Proof-Of-Concept (POC): After the optimal solution technologies and processes are selected, a POC is set up wiht a small representeative example of what a solution might look like, as much as possible. If available, a currently-running solution in a prallel example can be used
05 Implementation: Implementing a phased-in rollout of the completed solution basedd on findings from the previous phases
06 Handoff: A post-mortem on the project with a discussion of future enhancements
Throught

In the Workshop methodology section
Title of section "Workshop Methodolgy" spelling error
In first paragraph "use these modules indpendently in many cases"

Workshop scenario doesn't include Tailspin Toys gaming yet (I know you're working on this, let me know how I can help).

Checked all links and spelling

Lots of spelling errors in one list! What was I thinking. Anyway, fixed, and added Tailspin.


Fixes #209.

Here's the output of some more thorough testing of the backup process.
Preparation
Created a bare repository:
git init --bare myrepo

First backup on fresh branch
[master (root-commit) 2369e91] Backup
 6 files changed, 833 insertions(+)
 create mode 100644 .project
 create mode 100644 CommitHistory.activitymetadata
 create mode 100644 CommitHistory.json
 create mode 100644 Test.afm
 create mode 100644 Test.aird
 create mode 100644 Test.capella
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 8 threads
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 9.04 KiB | 9.04 MiB/s, done.
Total 8 (delta 1), reused 0 (delta 0), pack-reused 0
To /tmp/myrepo
 * [new branch]      HEAD -> my-branch
INFO:Importer:Backup of model finished

Second backup on existin gbranch
[my-branch 4d5ab1f] Backup
 2 files changed, 176 insertions(+), 176 deletions(-)
Enumerating objects: 7, done.
Counting objects: 100% (7/7), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 721 bytes | 721.00 KiB/s, done.
Total 4 (delta 3), reused 0 (delta 0), pack-reused 0
To /tmp/myrepo
   2369e91..4d5ab1f  HEAD -> my-branch
INFO:Importer:Backup of model finished

Check the repo
root@fedora:~# git clone --branch=my-branch /tmp/myrepo
Cloning into 'myrepo'...
done.
root@fedora:~# cd myrepo/
root@fedora:~/myrepo# ls
CommitHistory.activitymetadata  CommitHistory.json  Test.afm  Test.aird  Test.capella
root@fedora:~/myrepo# git log
commit 4d5ab1fb9bc865d957ef853bc68d2c2775d06ffd (HEAD -> my-branch, origin/my-branch)
Author: user<EMAIL_ADDRESS>Date:   Fri Oct 13 16:41:39 2023 +0000

    Backup

commit 2369e91ccfd5c388fa12c35c0d998c85ede0ea8f
Author: user<EMAIL_ADDRESS>Date:   Fri Oct 13 16:39:02 2023 +0000

    Backup

root@fedora:~/myrepo#


Python error on running vagrant up on custom site

Issue Type

Bug Report / Support Request

Your Environment

NOTE: Running from git bash
$ `vagrant nt --version && echo "VirtualBox `vboxmanage --version`" && ansible --version`
bash: command substitution: line 1: unexpected EOF while looking for matching `"'
bash: command substitution: line 2: syntax error: unexpected end of file
bash: command substitution: line 1: unexpected EOF while looking for matching `"'
bash: command substitution: line 2: syntax error: unexpected end of file
bash: vboxmanage: command not found

Your OS

Windows (version)

Full console output
https://gist.github.com/jmevalentin/2f6a4d0887ecfb6bece090adca71cbf4
Summary
When the vagrant up gets to the Ansible install I get an error that appears to be related to the python version, so I installed Python 3.9 and added it to the system path so that it would use it, and in git bash, running which python points to the correct python but this still happens.

I get the same on Windows10 Pro on an older version of drupalvm, just pulled and all seems OK now?


OCM-10439 | fix: Set component_routes to empty object will cause provider bug

What this PR does / why we need it:
Set component_routes to empty object will cause provider bug
Which issue(s) this PR fixes (optional, use fixes #<issue_number>(, fixes #<issue_number>, ...) format, where issue_number might be a GitHub issue, or a Jira story (OCM-xxxx):
Fixes #
OCM-10439
Change type

[ ] New feature
[x] Bug fix
[ ] Build
[x] CI
[ ] Documentation
[ ] Performance
[ ] Refactor
[ ] Style
[ ] Unit tests
[ ] Subsystem tests

Checklist

[ ] Subject and description added to both, commit and PR.
[ ] Relevant issues have been referenced.

/lgtm
/approve


Third party libraries

Hi Asadsahi,
can you please advice me how should i refer third party libraries like primeng in this project?
and also i would like to prevent it from compilation on each build...
I tried to add it in webpack.dev.js file - vendor array, but it does not work properly..  Nodeservices were throwing some exceptions whenever i add it.

@mageshbala90 try these steps:

npm i primeng --save
import primeng necessary module in AppModule or SharedModule (you need to export those modules from shared modules to be able to use it in another module)
e.g
import {AccordionModule} from 'primeng/components/accordion/accordion';

NB: I haven't installed primeng, hence getting red lines, but you get the idea.

Import primeng css files in vendor.css

You might not need bootstrap, if you have decided to use primeng themes etc. But check on primeng website if they have compatability with bootstrap 4.

Hi @asadsahi ,
Thank you for your advice.  I could integrate it by following above mentioned steps and it works.
But after adding Primeng modules, web pack is rebuilding infinitely even though i made no changes in the code.  Please be noted that there is no error in console.

An observation that may be of assistance.
I have not added any third party libraries.
However since the last update(s) my application randomly starts building infinitely.

Same problem i had,
and sawy that happening when some code in ts files has build error. I suggest to look output carefully and clear warning as much as possible.
I tryed with PrimeNg,Material2 and working well !

@m2017atTR @mageshbala90 I have just trid with two changes in home.component.ts and can't see it re-building more than once.

Can you notice anything specific on your environment?

I ment that there can be some changes in ts file changes in local copy
so when added third party HMR reflects repeatedly build.

I am using Kendo UI for Angular, but importing ButtonsModule and LayoutModule in shared.module.ts or app.module.ts is not working. I had to import to home.module.ts.
shared.module.ts:
//.........
// Services
import { ContentService } from './services/content.service';

import { ButtonsModule } from '@progress/kendo-angular-buttons';   //<-------------------
import { LayoutModule } from '@progress/kendo-angular-layout';       //<-------------------

@NgModule({
    imports: [
        CommonModule,
        FormsModule,
        ReactiveFormsModule,
        RouterModule,
        TranslateModule,
        NgbModule.forRoot(),
        // No need to export as these modules don't expose any components/directive etc'
        HttpModule,
        JsonpModule,
        ButtonsModule,                                  //<-------------------
        LayoutModule                                    //<-------------------
    ],
    declarations: [
        DynamicFormComponent,
        DynamicFormControlComponent,
        ErrorMessageComponent,
        ErrorSummaryComponent,
        FooterComponent,
        HeaderComponent,
        PageHeadingComponent,
        UppercasePipe
    ],
    exports: [
        // Modules
        CommonModule,
        FormsModule,
        ReactiveFormsModule,
        RouterModule,
        NgbModule,
        TranslateModule,
        // Providers, Components, directive, pipes
        DynamicFormComponent,
        DynamicFormControlComponent,
        ErrorSummaryComponent,
        ErrorMessageComponent,
        FooterComponent,
        HeaderComponent,
        PageHeadingComponent,
        UppercasePipe,
        ButtonsModule,                                  //<-------------------
        LayoutModule                                    //<-------------------
    ]

})
export class SharedModule
{
    public static forRoot(): ModuleWithProviders
    {
        return {
            ngModule: SharedModule,
            providers: [
                FormControlService,
                ContentService
            ]
        };
    }
}

home.component.html:
//......
<button kendoButton (click)="onButtonClick()" [primary]="true">My Kendo UI Button</button>

Error:

Can't bind to 'primary' since it isn't a known property of 'button'.

What am I doing wrong? (If I import in home.module.ts it works.)

@mageshbala90 you import/export in sharedmodule looks good. You need to import Shared module in each of consuming module e.g HomeModule in your case.

Hi @asadsahi ,
I have the same issue as @mageshbala90 and @m2017atTR  after installing primeng HMR is rebuilding infinitely, also checked the output and console and do not see any errors / exceptions

Hello friend,
I could add many other modules and working well...
Faced with same issues then

deleted dist folder completely then rebuild system...
also think about css or scss can couse this problem too... revert or completely remove from project for testing problem.

Update  about subject;
today I am working at home, same project at office HMR working perfect but at home
continuously building project as described. so problem result of some global npm or ... packages.
fyi

@m2017atTR if you have done a production build of this project this creates main.[hash].js file. and then if you run the project in dev mode, it may be reading the hashed version of main.js. Try deleting the wwwroot/dist folder and then run the project. That is the only reason I can think of right now for not running project under HMR.

I am still trying to find appropriate solutions of this problem, but for now try this workaround.

Hi,
I have a related problem.
I am trying to integrate a custom theme, but I am stuck.
I added to theme files in the wwwroot\assets directory.
I imported the css files from the theme using import('path to theme css')
When I run the application, I get an error that the font used in the theme can't be resolved. The font is also in the assets directory, but the theme can't resolve it as the css gets moved into the dist folder but not the font. Can anybody help? My guess is I need to add something in the webpack config but I just can't figure it out.

master is at .net core 2 now which does compilation a little cleanly. Give this a go, if you encounter any more issues, please let me know and I can look in more details.


Docker image 4.0.2-1 won't start - No implementation for java.util.Map<org.graylog2.plugin.Version, javax.inject.Provider<org.graylog.events.search.MoreSearchAdapter>> was bound

Just upgraded from 4.0.1-1 to 4.0.2-1 in my Kubernetes cluster, and the new Docker images seems won't start.
2021-01-28 18:17:40,213 ERROR   [CmdLineTool] - Guice error (more detail on log level debug): No implementation for java.util.Map<org.graylog2.plugin.Version, javax.inject.Provider<org.graylog.events.search.MoreSearchAdapter>> was bound.
  Did you mean?
    org.graylog2.plugin.Version annotated with @com.google.inject.name.Named(value=elasticsearch_version) bound  at com.github.joschi.jadconfig.guice.NamedConfigParametersModule.registerParameters(NamedConfigParametersModule.java:80)

    org.graylog.events.search.MoreSearchAdapter bound  at org.graylog2.storage.VersionAwareStorageModule.configure(VersionAwareStorageModule.java:54)

    org.graylog2.plugin.Version annotated with interface org.graylog2.storage.ElasticsearchVersion bound  at org.graylog2.bindings.ElasticsearchModule.configure(ElasticsearchModule.java:28)
 - {}

Reverting back to 4.0.1-1 fixes the issue.
Could this be related?
https://github.com/Graylog2/graylog2-server/issues/9521

Uh oh. It's probably my fault. Biggest change we made was https://github.com/Graylog2/graylog-docker/pull/148, so I'd guess it's related to that in some way. It starts up for me fine in docker-compose, though.
Are you settings GRAYLOG_PLUGIN_DIR to anything? What do your volume mounts look like? Are you adding any plugins, and what versions are they?

Uh oh. It's probably my fault. Biggest change we made was https://github.com/Graylog2/graylog-docker/pull/148, so I'd guess it's related to that in some way. It starts up for me fine in docker-compose, though.
Are you settings GRAYLOG_PLUGIN_DIR to anything? What do your volume mounts look like? Are you adding any plugins, and what versions are they?

I think the issue you mentioned probably is related, as it sounds like your instance isn't loading the plugins properly.
We wanted to give people the ability to mount the plugins dir as a volume without losing the bundled plugins. We created a couple new plugin directories

/usr/share/graylog/plugins - This is the old plugins dir. You should now be able to mount this as a volume and put whatever plugins you want there.
/usr/share/graylog/plugins-default - We moved the default plugins into this directory, so they don't disappear when the plugins dir is mounted as a volume.
/usr/share/graylog/plugins-merged - We set GRAYLOG_PLUGIN_DIR to this in docker-entrypoint.sh and copy plugins from both of the above dirs into this one.

Are you using a custom entrypoint or a different docker-entrypoint.sh? This line should set the correct plugins dir for you:
https://github.com/Graylog2/graylog-docker/blob/4.0.2-1/docker-entrypoint.sh#L75

I think the issue you mentioned probably is related, as it sounds like your instance isn't loading the plugins properly.
We wanted to give people the ability to mount the plugins dir as a volume without losing the bundled plugins. We created a couple new plugin directories

/usr/share/graylog/plugins - This is the old plugins dir. You should now be able to mount this as a volume and put whatever plugins you want there.
/usr/share/graylog/plugins-default - We moved the default plugins into this directory, so they don't disappear when the plugins dir is mounted as a volume.
/usr/share/graylog/plugins-merged - We set GRAYLOG_PLUGIN_DIR to this in docker-entrypoint.sh and copy plugins from both of the above dirs into this one.

Are you using a custom entrypoint or a different docker-entrypoint.sh? This line should set the correct plugins dir for you:
https://github.com/Graylog2/graylog-docker/blob/4.0.2-1/docker-entrypoint.sh#L75

Hi.
My setup follows the helm chart from kongz/graylog. So, it uses whatever voumes that chart is creating >> graylog-pod.yaml.zip
    volumeMounts:
    - mountPath: /usr/share/graylog/data/journal
      name: journal
    - mountPath: /usr/share/graylog/config
      name: config
    - mountPath: /entrypoint.sh
      name: entrypoint
      subPath: entrypoint.sh
    - mountPath: /k8s
      name: kubectl
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: graylog-deploy-token-dbsm7
      readOnly: true

Even without volumes mounted into /usr/share/graylog/plugins-default, there seems to be content in there from the image itself. We never installed any plugins manually.
graylog@graylog-deploy-1:~$ ls -l /usr/share/graylog/plugins-default
total 85772
-rw-r--r-- 1 graylog graylog 20239819 Jan 27 14:42 graylog-plugin-aws-4.0.2.jar
-rw-r--r-- 1 graylog graylog  6463542 Jan 27 14:41 graylog-plugin-collector-4.0.2.jar
-rw-r--r-- 1 graylog graylog  7997125 Jan 27 14:43 graylog-plugin-threatintel-4.0.2.jar
-rw-r--r-- 1 graylog graylog 23274748 Jan 27 14:39 graylog-storage-elasticsearch6-4.0.2.jar
-rw-r--r-- 1 graylog graylog 29839509 Jan 27 14:39 graylog-storage-elasticsearch7-4.0.2.jar

/usr/share/graylog/plugins-merged is empty.
/usr/share/graylog/plugins no longer exists.
GRAYLOG_PLUGIN_DIR is empty.
The chart does use a custom entrypoint, though. It comes from a configmap mounted into /entrypoint.sh inside the container.
https://github.com/KongZ/charts/blob/main/charts/graylog/templates/configmap.yaml
May that needs patching?

Hi.
My setup follows the helm chart from kongz/graylog. So, it uses whatever voumes that chart is creating >> graylog-pod.yaml.zip
    volumeMounts:
    - mountPath: /usr/share/graylog/data/journal
      name: journal
    - mountPath: /usr/share/graylog/config
      name: config
    - mountPath: /entrypoint.sh
      name: entrypoint
      subPath: entrypoint.sh
    - mountPath: /k8s
      name: kubectl
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: graylog-deploy-token-dbsm7
      readOnly: true

Even without volumes mounted into /usr/share/graylog/plugins-default, there seems to be content in there from the image itself. We never installed any plugins manually.
graylog@graylog-deploy-1:~$ ls -l /usr/share/graylog/plugins-default
total 85772
-rw-r--r-- 1 graylog graylog 20239819 Jan 27 14:42 graylog-plugin-aws-4.0.2.jar
-rw-r--r-- 1 graylog graylog  6463542 Jan 27 14:41 graylog-plugin-collector-4.0.2.jar
-rw-r--r-- 1 graylog graylog  7997125 Jan 27 14:43 graylog-plugin-threatintel-4.0.2.jar
-rw-r--r-- 1 graylog graylog 23274748 Jan 27 14:39 graylog-storage-elasticsearch6-4.0.2.jar
-rw-r--r-- 1 graylog graylog 29839509 Jan 27 14:39 graylog-storage-elasticsearch7-4.0.2.jar

/usr/share/graylog/plugins-merged is empty.
/usr/share/graylog/plugins no longer exists.
GRAYLOG_PLUGIN_DIR is empty.
The chart does use a custom entrypoint, though. It comes from a configmap mounted into /entrypoint.sh inside the container.
https://github.com/KongZ/charts/blob/main/charts/graylog/templates/configmap.yaml
May that needs patching?

Yeah, that's the problem. https://github.com/Graylog2/graylog-docker/pull/148 added this to docker-entrypoint.sh:
# Merge plugin dirs to allow mounting of /plugin as a volume
export GRAYLOG_PLUGIN_DIR=/usr/share/graylog/plugins-merged
rm -f /usr/share/graylog/plugins-merged/*
find /usr/share/graylog/plugins-default/ -type f -exec cp {} /usr/share/graylog/plugins-merged/ \;
find /usr/share/graylog/plugin/ -type f -exec cp {} /usr/share/graylog/plugins-merged/ \;

But since the helm chart uses a different entrypoint, it's missing that code. I think that configmap.yaml definitely needs updating.

Yeah, that's the problem. https://github.com/Graylog2/graylog-docker/pull/148 added this to docker-entrypoint.sh:
# Merge plugin dirs to allow mounting of /plugin as a volume
export GRAYLOG_PLUGIN_DIR=/usr/share/graylog/plugins-merged
rm -f /usr/share/graylog/plugins-merged/*
find /usr/share/graylog/plugins-default/ -type f -exec cp {} /usr/share/graylog/plugins-merged/ \;
find /usr/share/graylog/plugin/ -type f -exec cp {} /usr/share/graylog/plugins-merged/ \;

But since the helm chart uses a different entrypoint, it's missing that code. I think that configmap.yaml definitely needs updating.

I think we can close this and raise the issue on the chart maintenance. Thank you!

I think we can close this and raise the issue on the chart maintenance. Thank you!

is that issue also related to Linux OS?
I have updated Graylog from 3.3 to 4.0 and getting the same error?
graylog-server-4.2.6
mongodb-org-4.0.28
elasticsearch-6.8.13
ERROR:
Guice error (more detail on log level debug): No implementation for java.util.Map<org.graylog2.plugin.Version, javax.inject.Provider<org.graylog.events.search.MoreSearchAdapter>> was bound
Guice error (more detail on log level debug): No implementation for java.util.Map<org.graylog2.plugin.Version, javax.inject.Provider<org.graylog.plugins.views.search.engine.QueryBackend<? extends org.graylog.plugins.views.search.engine.GeneratedQueryContext>>> was bound


Need to somehow indicate what to reference by name or by value

Repro:
> var k = []
> k
[]
> generate(lave({x:1,y:k}))
'({\n    \'x\': 1,\n    \'y\': k\n});'

Expected Behavior: referencing K by value so I can actually deserialize this on other machine (kinda conflicts with #14 )
any suggestions? whitelist/blacklist variables from the scope?

going thru funny hoops
 (function(){var localA=k.a;delete k.a; return generate(lave(localA))})();

this seems to work))))

yeah, i think if you need a clean environment to prevent scope from being detected on initial run, you should provide a clean environment, such as by using the vm module.

care to add this to FAQ maybe?


Any way to support non named JSON Arrays ?

I know this may be far fetched, but I was wondering if there is any way Logan Square could support parsing JSON Arrays without a key.
Ex : Consider the JSON response from Dribbble below -
[
{
"id": 471756,
"title": "Sasquatch",
"description": "Quick, messy, five minute sketch of something that might become a fictional something.",
"width": 400,
"height": 300,
}
]
The response can be found documented here - http://developer.dribbble.com/v1/shots/#list-shots
So now, is there any way we could parse the outer array which doesn't have a key ?

This is already supported using LoganSquare.parseList(). Just pass that your InputStream or String and you'll get what you're looking for.


Docs: Fix Color Picker example usage #8444

Description
Fixes: #8444
How Has This Been Tested?
Via docs
Types of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

[x] The PR is submitted to the correct branch (dev).
[x] My code follows the code style of this project.
[ ] I've added relevant tests.

Hi.
Thanks for the PR.
Can you please post before and after change, so we wouldn't need to pull the changes and test it locally.

Hi. Thanks for the PR. Can you please post before and after the change, so we wouldn't need to pull the changes and test it locally.

Thank you for the advice and apologies for the inconvenience.

@ScarletKuro @henon
https://github.com/MudBlazor/MudBlazor/assets/7112040/c1641e91-4472-4c9a-af2b-28e7caaff0d7
https://github.com/MudBlazor/MudBlazor/assets/7112040/adf33908-423c-4ea8-881e-0409dafca2ae

Thanks!


Add a requirements.txt file for dependencies

We should add a requirements.txt file to have the dependencies installed in a single step. The ideal would be to have this as part of the library install process itself.
Ref: https://pip.pypa.io/en/latest/user_guide.html#requirements-files

Requirements files are more for pinning dependencies than listing them. You might compare it to a composer.lock file. An application depending on our tool has a requirements.txt, but a library should not.
The more correct route is to use the install_requires field of [setup.py][setup.py]: https://packaging.python.org/en/latest/distributing.html#install-requires
--
[setup.py]: https://github.com/Clarify/clarify_python/blob/69ac0648de43e531c49aadfa106bdd6e50a30c69/setup.py#L34

Ah thanks. Just found this which lays it out well:
https://packaging.python.org/en/latest/requirements.html

Yes, adding deps to the setup is on P's TODO list for this module.

Fixed. Will be checking in 1.1.1 soon. Then on to 2.0.


Missing support for subnet-id when creating a volume with netappfiles (reopening again)

az feedback auto-generates most of the information requested below, as of CLI version 2.0.72

Describe the bug
Previously a subnet id could be used when creating volumes when it was an extension.  Since being moved to the main cli this is not available.  The impact here is that I cannot create a volume in a separate resource group to where the vnet is located.
With the previous bug report it has been changed such that a subnet_id can be passed as the subnet parameter but the code only extracts the subnet name (and ignores the resource group).  This means it is not possible to use a vnet in a different resource group.
To Reproduce
az netappfiles volume create --resource-group  --vnet  --subnet  ...
This will fail unless the vnet is in the same resource group as the netappfiles.
Expected behavior
If a different resource group is specified in the subnet it should be used.
Environment summary
Linux latest azure-cli.
Additional context
It works in the portal.
This is where the subnet is now parsed but the resource group is ignored:
https://github.com/Azure/azure-cli/blob/20a25fff6775e5dbc8d7ecae1c037426a25a927a/src/azure-cli/azure/cli/command_modules/netappfiles/custom.py#L93

This issue is resolved


fix(rviz config): remove initial_pose_button_panel

Description
https://github.com/autowarefoundation/autoware.universe/issues/4848
rviz reports the following error:
[rviz2-74] [ERROR<PHONE_NUMBER>.618417957] [rviz2]: PluginlibFactory: The plugin for class 'tier4_localization_rviz_plugin/InitialPose

This plugin was removed https://github.com/autowarefoundation/autoware.universe/pull/4519.
So I will also remove tier4_localization_rviz_plugin/InitialPoseButtonPanel from the rviz cofings.
Tests performed
I have confirmed that no errors occur when launching RViz with each rviz config file.
like this.
ros2 run rviz2 rviz2 -d src/universe/autoware.universe/planning/obstacle_avoidance_planner/rviz/obstacle_avoidance_planner.rviz

Effects on system behavior

Not applicable.
Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.

[x] The PR follows the pull request guidelines.

Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

@yukke42  @knzo25  Please review this PR about lidar_centerpoint.
@tkimura4 @taikitanaka3 @1222-takeshi Please review this PR about accel_brake_map_calibrator


disable datastore hedging by default

I'm not sure how we haven't changed this default. It's literally been years we've recommended this be false for most folks.


[17.07] backport Make plugins dir private

backport:

moby/moby/pull/34374 Make plugins dir private.

with cherry pick moby/moby@0c2821d
$ git cherry-pick -s -x -Xsubtree=components/engine 0c2821d

Test failures are consistent to what we know has been failing:
FOR: https://jenkins.dockerproject.org/job/docker-ce-pr/96/consoleText
Passed (thought would fail):

Failed (should fail)
DockerSuite.TestRmiContainerImageNotFound
DockerSuite.TestRmiImageIDForceWithRunningContainersAndMultipleTags
DockerSuite.TestRunAttachDetachFromInvalidFlag
DockerSuite.TestRunWithNanoCPUs
DockerSuite.TestUpdateWithNanoCPUs
DockerSwarmSuite.TestServiceLogs
DockerSwarmSuite.TestSwarmNetworkPluginV2
DockerSwarmSuite.TestSwarmServicePsMultipleServiceIDs

Checked with: https://gist.github.com/seemethere/6128cb2391cd43b65b0ff4880af427e5

@rogaha @cpuguy83 @tiborvass

👍


Quickstart instructions for ASP.NET Core 2.x needs to reference "v2" templates

Issue / Steps to reproduce the problem
Attempting to follow the current quickstart documentation for ASP.NET Core 2 results in numerous problems due to the upgrade of IdentityServer to ASP.NET Core 3.0. The documentation should be updated to instruct the reader to install the current "v2" version of the IdentityServer templates (i.e. 2.6.1).
Relevant parts of the log file
N/A

merged.


[POC Mizar-Arktos Integration] Coredns, kube-dns are crashing and restarting in scale up and scale up env

What happened:
In Mizar-Arktos integrated local dev environment, kube-dns and coredns pod keeps crashing and get restarted.
In master, using default bridge network solution, kube-dns and coredns could not be started. (sandbox cannot be created. containerd reported ""No cni config template is specified, wait for other system components to drop the config.")
From kubelet log, it looks like kubelet is using pod ip managed by Mizar to do health and liveness check for kube-dns and coredns. Those ip addresses are not reachable from kubelet.
I0126 01:01:04.950570   24700 prober.go:121] Readiness probe for "coredns-default-ip-172-30-0-14-78dd67d496-f4mn6_kube-system_system(1f3795f9-84b7-42b0-a54d-8454b9b6c337):coredns" failed (failure): Get http://<IP_ADDRESS>:8181/ready: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I0126 01:01:15.294532   24700 prober.go:121] Liveness probe for "coredns-default-ip-172-30-0-14-78dd67d496-f4mn6_kube-system_system(1f3795f9-84b7-42b0-a54d-8454b9b6c337):coredns" failed (failure): Get http://<IP_ADDRESS>:8080/health: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I0126 01:02:24.704376   24700 prober.go:121] Readiness probe for "kube-dns-554c5866fc-vtr8t_kube-system_system(ca4d94d2-37a2-4c90-a38f-965668f25f99):kubedns" failed (failure): Get http://<IP_ADDRESS>:8081/readiness: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

I0126 01:02:09.721243   24700 prober.go:121] Liveness probe for "kube-dns-554c5866fc-vtr8t_kube-system_system(ca4d94d2-37a2-4c90-a38f-965668f25f99):kubedns" failed (failure): Get http://<IP_ADDRESS>:10054/healthcheck/kubedns: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

ubuntu@ip-172-30-0-14:~/go/src/k8s.io/arktos$ ./cluster/kubectl.sh get pods -AT -o wide
TENANT   NAMESPACE     NAME                                              HASHKEY               READY   STATUS    RESTARTS   AGE     IP            NODE             NOMINATED NODE   READINESS GATES
system   default       mizar-daemon-kdftq<PHONE_NUMBER>36715172    1/1     Running   0          7m21s   <IP_ADDRESS>   ip-172-30-0-41   <none>           <none>
system   default       mizar-operator-5c97f7478d-nrbl5<PHONE_NUMBER>540599971   1/1     Running   0          7m21s   <IP_ADDRESS>   ip-172-30-0-41   <none>           <none>
system   default       netpod1<PHONE_NUMBER>983888478   1/1     Running   0          2m16s   <IP_ADDRESS>    ip-172-30-0-41   <none>           <none>
system   default       netpod2<PHONE_NUMBER>141483683   1/1     Running   0          2m16s   <IP_ADDRESS>    ip-172-30-0-41   <none>           <none>
system   kube-system   coredns-default-ip-172-30-0-14-78dd67d496-f4mn6<PHONE_NUMBER>088497661   0/1     Running   3          7m21s   <IP_ADDRESS>     ip-172-30-0-41   <none>           <none>
system   kube-system   kube-dns-554c5866fc-vtr8t<PHONE_NUMBER>78937189    2/3     Running   8          7m21s   <IP_ADDRESS>     ip-172-30-0-41   <none>           <none>
system   kube-system   virtlet-nhqwd<PHONE_NUMBER>768950208   3/3     Running   0          7m12s   <IP_ADDRESS>   ip-172-30-0-41   <none>           <none>

What you expected to happen:
With Mizar as Arktos network plugin, kube-dns and coredns should be started successfully w/o crashing.

Starting K8s 1.18 in local cluster, only has kube-dns, no coredns. kube-dns pod is using local ip address.
ubuntu@ip-172-30-0-156:~/go/src/kubernetes$ ./cluster/kubectl.sh get pods -A -o wide
NAMESPACE     NAME                       READY   STATUS    RESTARTS   AGE     IP           NODE        NOMINATED NODE   READINESS GATES
kube-system   kube-dns-575cc5f5c-5mcbv   3/3     Running   0          3m32s   <IP_ADDRESS>   <IP_ADDRESS>   <none>           <none>

Starting preAlkaid in local cluster, only has kube-dns, no coredns.
ubuntu@ip-172-30-0-148:~/go/src/alkaid$ ./cluster/kubectl.sh get pods -A -o wide
NAMESPACE     NAME                        READY   STATUS    RESTARTS   AGE    IP           NODE        NOMINATED NODE   READINESS GATES
kube-system   kube-dns-5b6487d4cd-cdq8r   3/3     Running   0          115s   <IP_ADDRESS>   <IP_ADDRESS>   <none>           <none>

ubuntu@ip-172-30-0-148:~$ sudo iptables -t nat -S | grep <IP_ADDRESS>
-A KUBE-SEP-7PPXA5JT5ALVQPIV -s <IP_ADDRESS>/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-7PPXA5JT5ALVQPIV -p tcp -m tcp -j DNAT --to-destination <IP_ADDRESS>:53
-A KUBE-SEP-SNPTLXDNVSPZ5ND2 -s <IP_ADDRESS>/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-SNPTLXDNVSPZ5ND2 -p udp -m udp -j DNAT --to-destination <IP_ADDRESS>:53

Kube proxy log in arktos:
ubuntu@ip-172-30-0-14:~/go/src/k8s.io/arktos$ cat /tmp/kube-proxy.log | grep kube-dns
I0126 03:08:48.019124    5779 service.go:360] Adding new service port "system_0/kube-system/kube-dns:dns" at <IP_ADDRESS>:53/UDP
I0126 03:08:48.019143    5779 service.go:360] Adding new service port "system_0/kube-system/kube-dns:dns-tcp" at <IP_ADDRESS>:53/TCP
I0126 03:09:01.102105    5779 service.go:360] Adding new service port "system_0/kube-system/kube-dns-default:metrics" at <IP_ADDRESS>:9153/TCP
I0126 03:09:01.102122    5779 service.go:360] Adding new service port "system_0/kube-system/kube-dns-default:dns" at <IP_ADDRESS>:53/UDP
I0126 03:09:01.102134    5779 service.go:360] Adding new service port "system_0/kube-system/kube-dns-default:dns-tcp" at <IP_ADDRESS>:53/TCP
I0126 03:10:20.809149    5779 endpoints.go:281] Setting endpoints for "system_0/kube-system/kube-dns:dns" to []
I0126 03:10:20.809166    5779 endpoints.go:281] Setting endpoints for "system_0/kube-system/kube-dns:dns-tcp" to []
I0126 03:10:21.813249    5779 endpoints.go:281] Setting endpoints for "system_0/kube-system/kube-dns-default:dns" to []
I0126 03:10:21.813271    5779 endpoints.go:281] Setting endpoints for "system_0/kube-system/kube-dns-default:dns-tcp" to []
I0126 03:10:21.813280    5779 endpoints.go:281] Setting endpoints for "system_0/kube-system/kube-dns-default:metrics" to []

in K8s 1.18:
ubuntu@ip-172-30-0-156:~/go/src/kubernetes$ cat /tmp/kube-proxy.log | grep kube-dns
I0126 02:57:04.562445    6812 service.go:379] Adding new service port "kube-system/kube-dns:dns" at <IP_ADDRESS>:53/UDP
I0126 02:57:04.562456    6812 service.go:379] Adding new service port "kube-system/kube-dns:dns-tcp" at <IP_ADDRESS>:53/TCP
I0126 02:57:27.099960    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns-tcp" to []
I0126 02:57:27.100043    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns" to []
I0126 02:57:27.744946    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns-tcp" to []
I0126 02:57:27.744987    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns" to []
I0126 02:57:27.745016    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [<IP_ADDRESS>:53]
I0126 02:57:27.745031    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns" to [<IP_ADDRESS>:53]
I0126 02:57:27.745350    6812 proxier.go:812] Stale udp service kube-system/kube-dns:dns -> <IP_ADDRESS>
I0126 02:57:31.114722    6812 service_health.go:183] Not saving endpoints for unknown healthcheck "kube-system/kube-dns"
I0126 03:12:04.464281    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [<IP_ADDRESS>:53]
I0126 03:12:04.464294    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns" to [<IP_ADDRESS>:53]
I0126 03:12:04.464318    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns-tcp" to [<IP_ADDRESS>:53]
I0126 03:12:04.464344    6812 endpoints.go:376] Setting endpoints for "kube-system/kube-dns:dns" to [<IP_ADDRESS>:53]

Arktos:
ubuntu@ip-172-30-0-14:~/go/src/k8s.io/arktos$ ./cluster/kubectl.sh get ep -A
NAMESPACE     NAME               ENDPOINTS          AGE   SERVICEGROUPID
default       kubernetes         <IP_ADDRESS>:6443   18m   1
kube-system   kube-dns                              18m
kube-system   kube-dns-default                      18m

K8s 1.18:
ubuntu@ip-172-30-0-156:~/go/src/kubernetes$ ./cluster/kubectl.sh get ep -A
NAMESPACE     NAME         ENDPOINTS                     AGE
default       kubernetes   <IP_ADDRESS>:6443             30m
kube-system   kube-dns     <IP_ADDRESS>:53,<IP_ADDRESS>:53   29m

Service endpoint was not set correctly in Arktos. Might be a mizar service controller issue.

still fails randomly. mostly works.

Carl to verify and close


Integration with React Native?

Hello, would I be able to integrate this library with React Native using Expo TypeScript?

@justadudewhohacks how can you help in this case? I'm very interested in this integration and working on it.


xlsx-ugnis incorrect data check error while installing on Mac

Error below while installing react-spreadsheet-import package using yarn on Mac.
yarn add react-spreadsheet-import
yarn add v1.22.19
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error An unexpected error occurred: "https://registry.yarnpkg.com/xlsx-ugnis/-/xlsx-ugnis-0.20.3.tgz: incorrect data check".
info If you think this is a bug, please open a bug report with the information provided in "/Users/priya/ui/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

Hey @priyadhanz, we don't use yarn ourselves, so can't really help you out with this problem. If you figure out what could be changed in https://github.com/UgnisSoftware/xlsx-ugnis - feel free to create a PR.


UNABLE TO SET THE STAT:PROD :  "SET NODE_ENV=PRODUCTION" IT'S NOT WORKING INTERNALLY.

As I mentation when I set the "start:prod": " set NODE_ENV=production && nodemon server.js", the server starts as production but internally I guess it's not setting NODE_DEV as production, when I send the request in postman as production loading times go to infinite and failed, but when I set NODE_DEV = production manually in .env file it works, I don't what's happing but I try to figure it out from my side if you have any knowledge let me know.
I have the screenshot if you want to check out.

If using a .env file works, I don't see how the issue is caused by express. Additionally, I don't think express has a way to manage different environments directly.
I believe the problem is with the npm command itself because the set and nodemon commands are executed in different shells. Therefore, the NODE_ENV is only set for the duration of the first command. When nodemon runs, the value NODE_ENV is lost.
I highly suggest you use a config file like .env. It's easy, persistent, and removes the issue of cross-platform compatibility (make sure to add it to the .gitignore!!!).
If you really don't want to use a persistent config file, either use a package like cross-env (cross-env NODE_ENV=production nodemon server.js) or remove the whitespace before the && (set NODE_ENV=production&& nodemon server.js). Removing the whitespace executes both commands in the same shell instance, if I am not mistaken.
Hope it helps!


Panic when downloading

Describe the bug
When downloading via phoenix, we get 502 in CERN's setup. See cern golive card
(skipping the usual bug template as it needs input from CERN)

@ishank011 could you provide a bit more input? 👯 I suspect that accounts middleware is acting funny. It would be helpful if you could post the phoenix request since such middleware can be bypassed, and I would like to see what the implications are.

@ishank011 could you provide a bit more input? 👯 I suspect that accounts middleware is acting funny. It would be helpful if you could post the phoenix request since such middleware can be bypassed, and I would like to see what the implications are.

I tried killing the usual suspect, the ocis store, but I'm not reproducing the issue that way. I think the smoking gun is the accounts middleware, as your logs show

I tried killing the usual suspect, the ocis store, but I'm not reproducing the issue that way. I think the smoking gun is the accounts middleware, as your logs show

@refs Clicking on a file first sends a HEAD request which returns successfully
Request URL: https://cbox-spare-02.cern.ch:9200/remote.php/webdav/hello.txt
Request Method: HEAD
Status Code: 200 OK
Remote Address: <IP_ADDRESS>:12345
Referrer Policy: strict-origin-when-cross-origin

followed by one to the endpoint, which returns a 502
Request URL: https://cbox-spare-02.cern.ch:9200/ocs/v1.php/cloud/user/signing-key
Request Method: GET
Status Code: 502 Bad Gateway
Remote Address: <IP_ADDRESS>:12345
Referrer Policy: strict-origin-when-cross-origin

The complete logs are here https://gist.github.com/ishank011/2ec204692a6cc1092db68b743857fdf6
I don't see any others.
Also, all these background requests remote.php/dav/files/iarora/abc.txt?a=1&c=424293cbda57c4ed5931b8a011f7ea59&preview=1&scalingup=0 return a 500, and I see that these return a 404 at https://ocis.owncloud.works/.
One more thing. How do we disable tus from phoenix?

@refs Clicking on a file first sends a HEAD request which returns successfully
Request URL: https://cbox-spare-02.cern.ch:9200/remote.php/webdav/hello.txt
Request Method: HEAD
Status Code: 200 OK
Remote Address: <IP_ADDRESS>:12345
Referrer Policy: strict-origin-when-cross-origin

followed by one to the endpoint, which returns a 502
Request URL: https://cbox-spare-02.cern.ch:9200/ocs/v1.php/cloud/user/signing-key
Request Method: GET
Status Code: 502 Bad Gateway
Remote Address: <IP_ADDRESS>:12345
Referrer Policy: strict-origin-when-cross-origin

The complete logs are here https://gist.github.com/ishank011/2ec204692a6cc1092db68b743857fdf6
I don't see any others.
Also, all these background requests remote.php/dav/files/iarora/abc.txt?a=1&c=424293cbda57c4ed5931b8a011f7ea59&preview=1&scalingup=0 return a 500, and I see that these return a 404 at https://ocis.owncloud.works/.
One more thing. How do we disable tus from phoenix?

As @butonic mentioned, this should be handled by reva but apparently, it is somehow being redirected to ocis.

As @butonic mentioned, this should be handled by reva but apparently, it is somehow being redirected to ocis.

But looking at https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocs/handlers/cloud/user/user.go, this won't be the issue, as it should always return 200

But looking at https://github.com/cs3org/reva/blob/master/internal/http/services/owncloud/ocs/handlers/cloud/user/user.go, this won't be the issue, as it should always return 200

u.Opaque is probably nil here https://github.com/owncloud/ocis/blob/master/ocis-pkg/middleware/account.go#L70

u.Opaque is probably nil here https://github.com/owncloud/ocis/blob/master/ocis-pkg/middleware/account.go#L70

Yep. opaque:<map:<key:\"gid\" value:<decoder:\"plain\" value:\"2763\" > > map:<key:\"uid\" value:<decoder:\"plain\" value:\"125677\" > > >

Yep. opaque:<map:<key:\"gid\" value:<decoder:\"plain\" value:\"2763\" > > map:<key:\"uid\" value:<decoder:\"plain\" value:\"125677\" > > >

@ishank011 regarding TUS: as long as TUS headers are present ocis web will use them. https://github.com/owncloud/owncloud-sdk/pull/461
Which means that on EOS which does not support TUS the ocdav handler should not announce them in PROPFIND headers. which is currently hardcodet to true: https://github.com/cs3org/reva/blob/a7bf52ba4cf145baeb4b72d5dca485c731d5c1a7/internal/http/services/owncloud/ocdav/propfind.go#L192-L197
We could return capabilities like this in aResourceInfo Opaque propery ... because it might change from file to file ...

@ishank011 regarding TUS: as long as TUS headers are present ocis web will use them. https://github.com/owncloud/owncloud-sdk/pull/461
Which means that on EOS which does not support TUS the ocdav handler should not announce them in PROPFIND headers. which is currently hardcodet to true: https://github.com/cs3org/reva/blob/a7bf52ba4cf145baeb4b72d5dca485c731d5c1a7/internal/http/services/owncloud/ocdav/propfind.go#L192-L197
We could return capabilities like this in aResourceInfo Opaque propery ... because it might change from file to file ...

@butonic oh okay. I added a change which fixes the capabilities response in ocs https://github.com/cs3org/reva/pull/1331. Can we somehow propagate that to ocdav? Otherwise, I'll add the opaque property to EOS resources

@butonic oh okay. I added a change which fixes the capabilities response in ocs https://github.com/cs3org/reva/pull/1331. Can we somehow propagate that to ocdav? Otherwise, I'll add the opaque property to EOS resources

forget the capabilities endpoint. it has to die for anything related to files. having a single endpoint does not make sense because the capabilities might change with every tree, maybe even for every folder and file.
TUS ist a good example. It really is specific to the folder and we should announce it in the PROPFIND / HEAD requests using the proper headers. So I strongly vote for opaque properties.

forget the capabilities endpoint. it has to die for anything related to files. having a single endpoint does not make sense because the capabilities might change with every tree, maybe even for every folder and file.
TUS ist a good example. It really is specific to the folder and we should announce it in the PROPFIND / HEAD requests using the proper headers. So I strongly vote for opaque properties.

Cool, I'll make the change. Thanks for looking into this!

Cool, I'll make the change. Thanks for looking into this!

@ishank011 we could add tus support to https://cs3org.github.io/cs3apis/#cs3.storage.registry.v1beta1.ProviderInfo.Features

@ishank011 we could add tus support to https://cs3org.github.io/cs3apis/#cs3.storage.registry.v1beta1.ProviderInfo.Features


Enhanced store updating

Hoist P/R Checklist
Review and check off the below. Items that do not apply should be checked to indicate they have been considered. If unclear if a step is relevant, please leave unchecked and note in comments.

[x] Up to date with develop branch as of last change.
[x] Ready for review (or add wip label).
[x] Added CHANGELOG entry (or N/A)
[x] Checked for breaking changes (add breaking-change label + CHANGELOG if so, or N/A)
[x] Updated doc comments / prop-types (or N/A)
[x] Reviewed and tested on Mobile (or N/A)
[x] Created Toolbox branch / PR (link provided here, or N/A)

Pull request reviewers: when merging this P/R, please consider using a squash commit to collapse multiple intermediate commits into a single commit representing the overall feature change. This helps keep the commit log clean and easy to scan across releases.

Closing this in favor of new PR that also includes support for transaction based updates and other enhancements to the grid reaction


Add  in gamelist.xml to keep track of playing time

Added a new <gametime> XML attribute in gamelist.xml that keeps track of how long you've played a game. It displays the total number of seconds the game has been launched from ES. This new attribute needs to be displayed by the themes (I'd recommend to add it to Batocera default theme).

To avoid false positives, it's logged only if the calculated game time for a session is >5 seconds.
Structure of the new attribute in gamelist.xml:
<gameList>
        <game>
             ....
             <gametime>1245</gametime>
</game>
</gameList>

@fabricecaruso i let you merge. it is ok for me.

After discussion with @fabricecaruso we decided to revert back to unformatted seconds for <gametime>. Let theme creators do their jobs ;)

i don't really understand ? We can't change a date format when create a theme, only show or not an information ?

Yes, you can format it. The same way you format <lastplayed>20190703T195750</lastplayed> or
<rating>0.7</rating>. That's the information I got from Fabrice, I never wrote any theme.

Yes, you can format it. The same way you format <lastplayed>20190703T195750</lastplayed> or
<rating>0.7</rating>. That's the information I got from Fabrice, I never wrote any theme.

We can't format them ;)

Last played is formatted by ES, and the LANG selected, maybe it's what he want to say. Different in FR or US.
Rating is formatted with icons like stars ...  it's really specific for it ;)

@fabricecaruso is the boss for ES, i'm sure it will be perfect ;)

DONTMERGE yet, pending review from @fabricecaruso

Closing for a cleaner PR on https://github.com/batocera-linux/batocera-emulationstation/pull/316