pkg/list: Sort is too slow

Originally opened by @vikstrous2 in https://github.com/cuelang/cue/issues/745
What version of CUE are you using (cue version)?

$ cue version v0.3.0-beta.4 linux/amd64

Does this issue reproduce with the latest release?
yes
What did you do?
Baseline:
root.cue
package kube

import "list"

_a: [{name: 1}, {name: 3}, {name: 4}, {name: 5}, {name: 6}, {name: 7}, {name: 8}, {name: 9}, {name: 0}]
_b: [_a, _a, _a, _a, _a, _a, _a, _a, _a, _a]
_c: [_b, _b, _b, _b, _b, _b, _b, _b, _b, _b]
_d: [_c, _c, _c, _c, _c, _c, _c, _c, _c, _c]

out: list.FlattenN(_d, 4)

Run:
$ time cue eval root.cue | wc -l
0.34user 0.01system 0:00.20elapsed 172%!C(MISSING)PU (0avgtext+0avgdata 68940maxresident)k
0inputs+0outputs (0major+1293minor)pagefaults 0swaps
18001

Replace the last line with this list.Sort command to see the performance impact of using list.Sort in this config:
out: list.Sort(list.FlattenN(_d, 4), {x: {}, y: {}, less: x.name< y.name})

Run:
$ time cue eval root.cue | wc -l
6.03user 0.07system 0:02.87elapsed 212%!C(MISSING)PU (0avgtext+0avgdata 72392maxresident)k
0inputs+0outputs (0major+2495minor)pagefaults 0swaps
18001

What did you expect to see?
negligible performance difference
What did you see instead?
10x slow down

Update: We've been running the above yq command on the output of CUE for a while now, but there are ~500 files to sort and now it takes longer to run yq so many times than it takes to generate the output in the first place. If we had associative lists and those were output in a sorted order, that would solve this issue. I tried to make my own associative lists with a for comprehension. I see that maps are output in a sorted order, but for comprehensions (li: [for x in obj {x}]) are not, so I'm still running into the issue with sorting being slow because I still need to sort the output of the for comprehension.
To be fair, I haven't tried applying the associative list + sort pattern everywhere because I'm worried that I'll run into the same performance issue after refactoring my config.

@vikstrous2 do you have an example where the output is not stable? (https://github.com/cue-lang/cue/wiki/Creating-test-or-performance-reproducers)
CUE uses a topological sort due to conjunctions and such. In my experience it is stable with both JSON and Yaml output of kubernetes manifests, though not lexicographically sorted.
You might also try v0.4.0 but this has been the behavior in the 0.3 series as well (iirc)

Sorry for the confusion. The issue is not that the output is not stable between runs with the same config. The issue is that refactors cause fields to be reordered even though it's rendering equivalent configs. I realized now that actually maps are output in the same order the are defined.
The following two configs should produce the same output because the are equivalent:
b: "b"
a: "a"

a: "a"
b: "b"

The fact that they produce different output makes it infeasible to review the diff in the generated output when refactoring. (when working with large configs where there might be 1000 changes that are just noise)

@vikstrous2 thanks for the additional detail.
As noted in #474 we are looking to tighten up this behaviour in the spec, so that should help.

I realized now that actually maps are output in the same order the are defined.

Indeed, that should be the case above, despite the fact this is not guaranteed in the spec. So given this is the case, are you running into a case where this is not happening? i.e. why are you finding that sort is required? Without a sort the output might well differ from the sorted result, but if you accept that diff then from that point on the diff should be "true", no?
Note that I'm not pushing back on the fact that we should fix the speed of sort; that we should fix it is a given (and thank you for the reproducer above). Rather, I'm trying to see if there is a practical workaround for now.
It sounds like you have CUE as the source of truth - do you even need to review the diff of the yaml output? I ask that question, again not to undermine the need for a semantic diff package, but to understand more about your use case.

 Thanks for asking them.

So given this is the case, are you running into a case where this is not happening?

No, I'm not running into cases where the output order is unexpected. The order just changes between refactors because fields are often moved around. Sometimes there's no way to do a refactor without moving fields around and it's hard / tedious to split it up into two refactors where one of them keeps the order.

Without a sort the output might well differ from the sorted result, but if you accept that diff then from that point on the diff should be "true", no?

Yes, we can accept the diff, of course. But we'd have to do it blindly unless we go through it and manually compare every changed line to make sure nothing unexpected sneaks through the review. This is hard if the diff is 1000 lines, but only 1 meaningful change is expected.

Note that I'm not pushing back on the fact that we should fix the speed of sort

I actually think that if the output of maps was sorted and that also led to for comprehensions being sorted, that might be a better solution than having to manually sort the output. I don't know if this is feasible or if it's a complete solution (there might be a lot of for comprehensions that interact with each other and might break sorting anyway).

do you even need to review the diff of the yaml output?

Definitely. It acts as a test that can be verified easily. A lot of engineers are not proficient at writing CUE and it's easy to accidentally make mistakes that can be caught when reviewing the generated output. We don't render every possible config (we generate different things for different environments), but we render one example config and check that in so it's part of the PR review.
I commented on the semantic diff issue, but I'm thinking that it doesn't provide significantly more value than diffing well sorted and normalized yaml files.

I actually think that if the output of maps was sorted and that also led to for comprehensions being sorted, that might be a better solution than having to manually sort the output.

This is definitely an option, but I don't think it's necessarily the right default.

A lot of engineers are not proficient at writing CUE and it's easy to accidentally make mistakes that can be caught when reviewing the generated output.

A very good point.

I commented on the semantic diff issue, but I'm thinking that it doesn't provide significantly more value than diffing well sorted and normalized yaml files.

Generally speaking I think diff will be more useful, because it is a semantic diff across different encodings. But I can see how in your case a more specific diff would be more useful.
Thanks very much for the additional colour.

list.Sort should now be significantly faster. There are still significant possible optimizations if the values for T (or x and y) are idempotent. But I hope for now this will be of help.

Dropping the now-defunct v0.4.x milestone from this issue, but leaving the zGarden label such that we come round to considering what milestone this should sit in.

Here is a tweaked testscript which avoids using time:
env CUE_EXPERIMENT=evalv3=0

# root1 with the old evaluator
exec cue vet -c root1.cue
# root2 with the old evaluator
exec cue vet -c root2.cue

env CUE_EXPERIMENT=evalv3=1

# root1 with the new evaluator
exec cue vet -c root1.cue
# root2 with the new evaluator
exec cue vet -c root2.cue

-- root1.cue --
package kube

import "list"

_a: [{name: 1}, {name: 3}, {name: 4}, {name: 5}, {name: 6}, {name: 7}, {name: 8}, {name: 9}, {name: 0}]
_b: [_a, _a, _a, _a, _a, _a, _a, _a, _a, _a]
_c: [_b, _b, _b, _b, _b, _b, _b, _b, _b, _b]
_d: [_c, _c, _c, _c, _c, _c, _c, _c, _c, _c]

out: list.FlattenN(_d, 4)

-- root2.cue --
package kube

import "list"

_a: [{name: 1}, {name: 3}, {name: 4}, {name: 5}, {name: 6}, {name: 7}, {name: 8}, {name: 9}, {name: 0}]
_b: [_a, _a, _a, _a, _a, _a, _a, _a, _a, _a]
_c: [_b, _b, _b, _b, _b, _b, _b, _b, _b, _b]
_d: [_c, _c, _c, _c, _c, _c, _c, _c, _c, _c]

out: list.Sort(list.FlattenN(_d, 4), {x: {}, y: {}, less: x.name < y.name})

> env CUE_EXPERIMENT=evalv3=0
# root1 with the old evaluator (0.143s)
> exec cue vet -c root1.cue
# root2 with the old evaluator (0.691s)
> exec cue vet -c root2.cue
> env CUE_EXPERIMENT=evalv3=1
# root1 with the new evaluator (0.335s)
> exec cue vet -c root1.cue
# root2 with the new evaluator (1.362s)
> exec cue vet -c root2.cue

So evalv3 is about twice as slow as evalv2. And both evaluators are about three times as slow when adding the sorting. Both of these should be resolved, even though the slow-downs aren't incredibly worrying at this point.


Form Request Validation array attributes problem

Hi Team,
I am stuck with an issue described as follows:
Step 1: Create a form request like following with attributes defines as array:

namespace App\Http\Requests\Auth;

use App\Http\Requests\Request;

class LoginRequest extends Request {

        public function __construct(){

            parent::__construct();

        }

        public function authorize(){

            return $this->isGuest === TRUE;

        }

	/**
	 * Get the validation rules that apply to the request.
	 *
	 * @return array
	 */
	public function rules()
	{
            return [
                'user[email]' => 'required',
                'user[password]' => 'required',
            ];
	}

}

Step 2: a simple login form

form method="post" action="{{ url('/user/login') }}">
  {!! csrf_field() !!}
  input type="email" class="form-control uname" name="user[email]" value="{{ old('user[email]') }}"
  input type="password" class="form-control pword" name="user[password]"
  input type="hidden" class="form-control pword" name="type" value="admin"
  button type="submit" class="btn btn-success btn-block">Subimit
Step3: Now try to submit this form and it will never get validated inspite of filling the values in the form.
The form requests never validate this.
It never reaches to the controller action.

Please ask on the forums.

Now we need to discuss issues on forums. great


Changed activation method for MenuToggle

:+1:
No reason to have an extra event when it initially gets activated

So maybe we should put this->Changed(this, System::EventArgs::Empty); in ChangeSelection method? And remove it from Activate and Change methods?

Done


Websocket component does not work when run on a server or in a docker

I tried the Real-time data streaming example from the documentation.
It works as advertised when run locally, but I need to deploy my intended app on a server.
When I run this in a server, adding the host='<IP_ADDRESS>' argument to the dash app, the websocket extension no longer works.
I have made a repo with a dockerized version of this demo app, as well as a version with added diagnostics.
The diagnostics show:
WebSocket connection state: {'readyState': 3, 'isTrusted': True, 'timeStamp': 727.5, 'code': 1006, 'reason': '', 'wasClean': False}

which apparently means that the client socket closed unexpectedly/abnormally. The same behaviour occurs whether I run the docker locally, or run the app on a server.
If I use wscat to connect directly to the server websocket it successfully connects and outputs the sequences of 10 random numbers, even though the Websocket dash component cannot connect to the same url.

If the example works locally but nor within docker, it hints towards a bug in the containerization process. I'll try to find time to take a look one of the following days (:

Thanks.
Also note that the example does not work when run on a server, with the connecting web browser run locally, even when not dockerized.

I had a look at the repo. It seems that there are multiple issues with the dockerization setup, and in addition the example in the docker container is different from the one running outside. I have reverted the example to the original one for clarity, and fixed the most pressing issues in this PR,
https://github.com/quantitative-technologies/dash-websockets/pull/1
The example is now running in my laptop. Hence, it is my impression that there isn't any issues with the Websocket  component in regard to dockerization.

When you just run the files using Python, you're using a development server, which is not suited for production. This is explicitly printed to the console as a warning. For production use there are multiple hosting options, with uvicorn (for FastAPI) and gunicorn (for Flask, and thus Dash) being comon options. Hence, I am not sure if that information should go in the documentation here - it's more of a general topic. But it's great to hear that it now working - and I can add that your resulting setup is much better suited for production use now :)

My bad, somehow I missed the warning :(


incubator jekyll website

I see there is a website/_site directory with some content in it. Aren't we supposed to not add this content to the git repo, but rather generate this content using "jekyll s" ?

That's what we did with the web app, but not sure what we wanted here. I
liked looking at the generated site code to make sure it had correct
relative paths. Either way is fine with me though.
On Tuesday, November 3, 2015, Santosh Marella<EMAIL_ADDRESS>wrote:

I see there is a website/_site directory with some content in it. Aren't
we supposed to not add this content to the git repo, but rather generate
this content using "jekyll s" ?
—
Reply to this email directly or view it on GitHub
https://github.com/apache/incubator-myriad/pull/30#issuecomment-153413712
.

Let's just keep the source in git, generate the website locally and push the generated artifacts to SVN.
Let me know if you'd like me to do it while merging the PR. I'm currently installing everything required for jekyll on my dev box.

I tried out the website locally after installing jekyll. It works as expected and the website looks awesome.
@klucar - great work!

Forgot to mention one thing, perhaps we should add a website/README.md that captures instructions on how to install jekyll locally, generate the artifacts, test the website locally and push them to SVN. I believe a lot of the content would be very similar to Apache Kylin's: https://github.com/apache/incubator-kylin/blob/master/website/README.md.


CI fails with EADDRNOTAVAIL

Multiple tests are failing sporadically when an address cannot be acquired by the node or a client
example:
Casper-Test Nightly Test Status: Failure
Repo: casper-test
Author: marc-casperlabs
Drone Build: #512
Commit Link: ec2f21d5ff

Removing this from 1.5.0, since it does not affect the release.

Preliminary anaylsis:
We are getting some intermittent errors in CI and every now and then I get a bug report from that. These errors are usually hard to reproduce and I get a sneaking suspicion that they are related to overprovisioning on Drone's end.
As an example, we recently had a failure that I am looking at now (https://github.com/casper-network/casper-node/issues/3252), which looks like this:

error sending request for url (http://localhost:11101/rpc): error trying to connect: tcp connect error: Cannot assign requested address (os error 99)

This (EADDRNOTAVAIL = 99) indicates that a client could not create an "outgoing" (they're all loopback) TCP connection because no ephemeral source port could be allocated for the initiating socket. Usually a few thousand of these are available, but they can get scarce if:

Multiple things are running on a shared interface, taking up ports,
the range of available ports has been reduced (e.g. we'd need to check what's in /proc/sys/net/ipv4/ip_local_port_range),
older jobs have been run on the interface that still have lingering (as in TIME_WAIT or similar) connections,
we're plain running too many things at once (maybe a high refresh rate requiring TCP connections, but we'd have seen that locally as well), or
something's just plain broken on the host.

@dwerner pointed out that there is no reusage of reqwest::Client instances, which may be the underlying issue. Fixing that may already solve this problem.

The EADDRNOTAVAIL error must come from a connect syscall as the other syscalls which can yield this error are N/A (bind for example would error with EADDRNOTAVAIL if a nonexistent interface was provided, which is not the case for us). After looking at the node code, the EADDRNOTAVAIL error couldn't have come from there as the test would have exited with some other error (like ECONNREFUSED if the node crashed and nobody was listening on that address).
This means the bug is coming from somewhere inside the testing stack (NCTL, casper-test, casper-client). From the error message, we know it was yielded by casper-test when attempting an RPC call.
The man explanation for EADDRNOTAVAIL on connect is:

       (Internet domain sockets) The socket referred to by sockfd
       had not previously been bound to an address and, upon
       attempting to bind it to an ephemeral port, it was
       determined that all port numbers in the ephemeral port
       range are currently in use.  See the discussion of
       /proc/sys/net/ipv4/ip_local_port_range in [ip(7)](https://man7.org/linux/man-pages/man7/ip.7.html).

The bug never reproduced locally, so it must have something to do with limited resources on the drone testing machine. This coupled with the fact that the Client instances were not reused meant it was very feasible for the drone machine to run out of resources, as pointed out by @dwerner and @marc-casperlabs respectively. My hunch is that we reached a point where we do so many requests in a normal test-all casper-test session that we reach the port exhaustion limit.
PRs for casper-test and casper-client are up fixing the reqwest::Client usage in both repositories. This hopefully fixes the problem and confirms the hypothesis above.
To summarize, a node problem is ruled out, most likely the testing machine is running out of ports because of inefficient reqwest::Client usage.

The diagnostic script running after failures in casper-test showed that the port range was vast. Moreover, when testing locally only around 200 ports were used. These findings exclude the possibility of port exhaustion.

The bug never reproduced locally, so it must have something to do with limited resources on the drone testing machine.
@TomVasile suggested we run the test locally, but inside a docker container, mimicking the drone setup. This made the bug reproduce almost all of the time. A sample netstat output shows that some nodes do not open their RPC ports by the time the 15 second timeout expires. This is because said nodes take longer to reach the participating state. Excerpt netstat -tunap output after a failed test:

tcp        0      0 <IP_ADDRESS>:14105           <IP_ADDRESS>:*               LISTEN      31407/casper-node
tcp        0      0 <IP_ADDRESS>:14104           <IP_ADDRESS>:*               LISTEN      31405/casper-node
tcp        0      0 <IP_ADDRESS>:14103           <IP_ADDRESS>:*               LISTEN      31380/casper-node
tcp        0      0 <IP_ADDRESS>:14102           <IP_ADDRESS>:*               LISTEN      31353/casper-node
tcp        0      0 <IP_ADDRESS>:14101           <IP_ADDRESS>:*               LISTEN      31354/casper-node
tcp        0      0 <IP_ADDRESS>:22105           <IP_ADDRESS>:*               LISTEN      31407/casper-node
tcp        0      0 <IP_ADDRESS>:22104           <IP_ADDRESS>:*               LISTEN      31405/casper-node
tcp        0      0 <IP_ADDRESS>:22103           <IP_ADDRESS>:*               LISTEN      31380/casper-node
tcp        0      0 <IP_ADDRESS>:22102           <IP_ADDRESS>:*               LISTEN      31353/casper-node
tcp        0      0 <IP_ADDRESS>:22101           <IP_ADDRESS>:*               LISTEN      31354/casper-node
tcp        0      0 <IP_ADDRESS>:11103           <IP_ADDRESS>:*               LISTEN      31380/casper-node
tcp        0      0 <IP_ADDRESS>:11102           <IP_ADDRESS>:*               LISTEN      31353/casper-node
tcp        0      0 <IP_ADDRESS>:11105           <IP_ADDRESS>:*               LISTEN      31407/casper-node
tcp        0      0 <IP_ADDRESS>:11104           <IP_ADDRESS>:*               LISTEN      31405/casper-node
tcp        0      0 <IP_ADDRESS>:18105           <IP_ADDRESS>:*               LISTEN      31407/casper-node
tcp        0      0 <IP_ADDRESS>:18104           <IP_ADDRESS>:*               LISTEN      31405/casper-node
tcp        0      0 <IP_ADDRESS>:18103           <IP_ADDRESS>:*               LISTEN      31380/casper-node
tcp        0      0 <IP_ADDRESS>:18102           <IP_ADDRESS>:*               LISTEN      31353/casper-node
tcp        0      0 <IP_ADDRESS>:18101           <IP_ADDRESS>:*               LISTEN      31354/casper-node

Now that we know the client connect error is justified since there sometimes isn't anything to connect to, we have two distinct problems that only affect us inside the docker container:

Why are some nodes now taking longer to reach the participating state?
Why is the error we get EADDRNOTAVAIL instead of ECONNREFUSED?

For the first problem, the time difference on average for reaching participating state on the laziest node on my machine is 25s inside the container and 9s on the host. Another problem why did it start happening only about a month ago. It would be very difficult to study container performance compared to native and it is most likely related to networking. I tried following the process with strace and the process sleeps a lot for 100ms, meaning it probably does fetch_and_store_next a lot and runs out of peers, which would indicate the network is slow since the NTCL/test requirements for reaching the participating state haven't changed recently.
The second problem is harder to diagnose and would require a deep dive into the linux network stack code and docker's setup as well. Since at the time the test failed there was no RPC port listened to (as netstat would show), all documentation points to an ECONNREFUSED error. The man description is:

A connect() on a stream socket found no one listening on the remote address.

Other people have signaled issues regarding unexpected EADDRNOTAVAIL errors on connect when containerizing their applications using docker. Also, we only get this error inside the container.
At this point, I'd argue the first problem is more important than the second and we should focus on that. In local test runs, an increase to the node readiness timeout from 15s to 30s gives the nodes enough time to reach the participating state and fixes the issue. Fully understanding what caused this is yet to be determined.

The initial issue seems to be fixed, but now the CI fails at another point, namely when running the single node join test spec. Messages like the following are logged every 5 seconds and then the test fails after 5 minutes:

2022-09-04T05:44:20.111731Z  WARN process{trigger=ensure did not crash, on all nodes}: casper_test::spec::checks: node reports stopped (but not crashed) node=nctl-node 0

This might be because the time is still not enough for one node to reach participating and it could never recover from that state, therefore compromising the testing scenario

2022-09-04T05:44:20.102840Z  WARN casper_test::environment::nctl: not all nctl nodes reported readiness after timeout failed_nodes=nctl-node 4 timeout=30s

We can try to increase the timeout once again as the previous figure of 15s -> 30s was based on observations on my local machine and it might not be suitable for the drone environment.

The original issue was fixed by https://github.com/casper-network/casper-test/pull/108. The second problem of the failing simple_join test was fixed by @TomVasile in https://github.com/casper-network/casper-test/pull/109. The test are running smoothly. Closing the issue.


Any future plans to support jsonPointer syntax?

Any future plans to support jsonPointer syntax?
using
#/store/book/0
in place of
$.store.book[0]

No plans for JsonPointer syntax. Sorry!


[REPO] build basic tooling: core/lib3h branching

As a networking developer, I can rely on basic tooling for dev work so that I don't get annoyed with wasting time doing mundane things over and over (and over).

[ ] SPIKE: Workflow doc && automation tools for opening feature branches && PRs on both lib3h and core repositories

Who wants the tooling here? David B prefers writing things himself when needed.


Put types in exports for modern TypeScript

Revitalizing an old project, I'm now getting this error with this package:
error TS7016: Could not find a declaration file for module '@soorria/solid-dropzone'. [...]
  There are types at<EMAIL_ADDRESS>but this result could not be resolved when respecting package.json "exports". The '@soorria/solid-dropzone' library may need to update its package.json or typings.

I think this might be the result of some TypeScript updates? Manually editing<EMAIL_ADDRESS>according to this PR fixed the issue with me.

Thanks!

Need to manually release, but will do tonight.


Hiding titlebar

I'm trying to create a minimal MacVim experience by removing the titlebar from the application. I was inspired by https://tuananh.org/2015/01/11/a-minimal-iterm2-setup/ which was actually being picked up by the development team as an option.
Basically I did
diff --git a/src/MacVim/MMWindowController.m b/src/MacVim/MMWindowController.m
index b87079b..ecea307 100644
--- a/src/MacVim/MMWindowController.m
+++ b/src/MacVim/MMWindowController.m
@@ -126,7 +126,7 @@

 - (id)initWithVimController:(MMVimController *)controller
 {
-    unsigned styleMask = NSTitledWindowMask | NSClosableWindowMask
+    unsigned styleMask = NSClosableWindowMask
             | NSMiniaturizableWindowMask | NSResizableWindowMask
             | NSUnifiedTitleAndToolbarWindowMask;

Everything compiles and it actually removes the titlebar as intended BUT the window doesn't accept any keyboard input (I just hear the bell).
As an unfortunate side effect  this removes the ability for amethyst window manager to move the window. Maybe that is even the issue for MacVim.
Unfortunately my knowledge about Objective-C is limited, so my experiment stopped. But maybe somebody else knows how to move this forward?

By removing NSTitledWindowMask (0x1), you've essentially set NSBorderlessWindowMask (0x0); none of the other values you are still OR'ing into the style masks set the low bit of the value to 1.
A window with NSBorderlessWindowMask can't become key or main, and thus can't get keyboard input (that's why you hear the bells when you type). The NSWindow needs to return YES from canBecomeMainWindow and/or canBecomeKeyWindow to change this behavior.
Fortunately MacVim already has a window subclass (MMWindow), so you should be able to fix this by adding one or both of:
-(BOOL) canBecomeMainWindow {
    return YES;
}

-(BOOL) canBecomeMainWindow {
    return YES;
}

to MMWindow.m. I think (I haven't tested it).
I'm not sure whether or not supporting this is something MacVim would want (and if so, how to expose the preference), that's probably for @douglasdrumond to decide.

Hmm, no-title-bar window is not fancy for me, but you can try the pull request https://github.com/macvim-dev/macvim/pull/111

#111 is ready to merge. @oschrenk could you test it?

#111 merged.


feat: silent in test

Pull Request Test Coverage Report for Build 199

0 of 0   changed or added relevant lines in 0 files are covered.
1 unchanged line in 1 file lost coverage.
Overall coverage decreased (-0.3%) to 93.704%

Files with Coverage Reduction
New Missed Lines
%

src/index.ts
1
91.51%

Totals

Change from base Build 197:
-0.3%

Covered Lines:
413

Relevant Lines:
425

💛  - Coveralls


Sponsoring David

hey,
Can we sponsor https://david-dm.org/ ?
best!

Hi @alexandresaiz please drop me an email with your thoughts -<EMAIL_ADDRESS>


feature: add json diff with unit tests

currently there are few tests but those fail, we need to update those and try to increase coverage.
If tests pass we shall also ensure that every new pr runs these unit tests before merging.

Can I work on this issue, @shivamsouravjha.

sure @mdxabu currently coverage is around 85% we need to ensure it reaches to maximum possible limit. and also ensure that the tests run when a PR is opened to ensure nothing is breaking


Added a Profile!

Pull Request

Description:

I have added my profile in this repository.
Related Issue:

Closes #XXXXX

Hey, @prathamesh-borse  please review my profile!


Add support for rover wheel encoders in PX4

Describe problem solved by the proposed feature
Many rovers, including the Aion R1 which is being used for development, incorporate wheel encoders. These could play a similar role to optical flow and RTK sensors, in providing local, small-scale velocity feedback.
Describe your preferred solution
Create a driver which reads wheel encoder data from the BasicMicro RoboClaw motor driver on the Aion R1, and publishes it as a uORB topic. Create a module which uses this data for navigation.
Describe possible alternatives
The existing optical flow module could be used for similar navigation purposes, but calibrating the sensors properly might be difficult due to how low they would be to the ground.

According to https://discuss.px4.io/t/pixhawk-enabling-gpio-output/2457 , It's possible to read wheel encoders signal directly from GPIO pins.
Ardupilot have already implemented this, http://ardupilot.org/rover/docs/wheel-encoder.html#wheel-encoder

The roboclaw driver https://github.com/PX4/Firmware/pull/12416 has been merged but more work would be required to fuse this into the estimator.

The estimator part is tracked in #12350, closing.


Force lower-case during path normalization.

File paths are never case-sensitive. This fixes an issue that leads to false negatives when matching globs.

File paths are typically case-sensitive outside Windows.

Codecov Report

Merging #150 into master will decrease coverage by 0.2%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master     #150      +/-   ##
==========================================
- Coverage   97.77%   97.56%   -0.21%
==========================================
  Files          35       35
  Lines        4800     4801       +1
==========================================
- Hits         4693     4684       -9
- Misses        107      117      +10

Impacted Files
Coverage Δ

src/luacheck/fs.lua
88.17% <100%> (-3.14%)
:arrow_down:

src/luacheck/lua_fs.lua
84% <0%> (-12%)
:arrow_down:

src/luacheck/config.lua
91.86% <0%> (-1.63%)
: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 c3fc4ff...1cea9d2. Read the comment docs.

Oh. Right. Guess it never came up in my time using Ubuntu so brain just forgot about it. Fixed it.

Thank you!


Ability to log sql query via boolean from Sql2o or Query classes

This is a simple request but one could avoid writing pesky log statements in multiple places to log sql query.
My take:

To define it globally we can make use of Sql2o class.
To define per query provide an ability in Query class.

Sql2o and Query both could provide a method something like:
setSqlLogging(boolean enable, LogLevel ..);
Log Level could decide which level should be used for logging SQL. Default could be debug / error.

I have added logging of the SQL just before the statement is executed. It will log the parsed query, so that parameters are logged as ?. Instead of adding a setSqlLogging() or similar, it will simply log queries at DEBUG level, so that it utilizes default logging behavior.


Download full chat history

Hi Nils,
my question is the title :)
Is it possible to download the full chat history in one file?
thanks for your help,
best regards
Tobit

There used to be a way to download the chat but I disabled it because some users expressed privacy concerns.

Btw. you can find some chat logs here: http://overrustlelogs.net/
I'm in no way affiliated with the site though and I don't know how accurate or complete these logs are.


fixnum shift not becoming fixnum-shift-fast

This should optimize the shift to fixnum-shift-fast but it doesn't:
[
    { fixnum object } declare
    integer>fixnum dup 0 >= [
        neg shift even? not
    ] [ 2drop f ] if
] optimized.

It clearly knows that the inputs and outputs of shift are fixnum, but I'm not sure why it doesn't optimize to fixnum-shift-fast.
[
    integer>fixnum dup 0 fixnum>= [
        -1 fixnum*fast fixnum-shift 1 >R R> fixnum-bitand 0 eq?
        [ f ] [ \ t ] if
    ] [ 2drop f ] if
]

Should it? The only thing we know about the top of the stack here is that it is:

a fixnum (class propagation from the declare + integer>fixnum)
non-positive (value range propagation into the branch from dup 0 >= then neg)

We can (and the compiler already does) optimize shift to fixnum-shift. But fixnum-shift-fast is for small shifts (where we can't possibly overflow to a bignum), which this is not:
[
    { fixnum object } declare
    integer>fixnum dup 0 >= [
        neg shift even? not
    ] [ 2drop f ] if
] build-tree optimize-tree
[ #if? ] find nip children>> first
[ { [ #call? ] [ word>> \ fixnum-shift eq? ] } 1&& ] find nip
node-input-infos [ interval>> ] map .

! V{
!     T{ interval
!         { from { -576460752303423488 t } }
!         { to {<PHONE_NUMBER>03423487 t } }
!     }
!     T{ interval
!         { from { -576460752303423487 t } }
!         { to { 0 t } }
!     }
! }

cell-bits tag-bits get - [ neg ] keep [a,b]

! T{ interval { from { -60 t } } { to { 60 t } } }

But aren't you forgetting that the second shift operand is <= 0 so the result will always be a fixnum if the  first operand is a fixnum? E.g <fixnum> 1234 shift could overflow <fixnum> -123456789 shift can't.

I misunderstood. The problem isn't overflow it's that the shift operand must fit into an 8-bit register to be able to use the shr and shl instructions. Maybe it would still be possible to optimize an expression like { fixnum } declare -2000 shift better (result will always be 0) but maybe it's not worth the bother.

Okay, I'm closing this for now then.


Extending pc integral trick to non-uniform op costs

There seems to be the likelihood that certain ops, especially memory ops (i.e. reg load, jmp which requires a random instruction seek), might need to be charged higher amount of compute units, for the reason that they can be several times slower than an alu op (100ns RAM seek is ~300x slower than an i32 add).
This is a good explanation for Serum's bad CU/us ratio, with a median of 7. That's because Serum's critbit tree data structure does a lot of random reads from a 1MB+memory region, which maybe it lives in L3 cache or even loaded cold from RAM - so dominated by opcodes 30-300x slower than ALU opcode.
In the model we consider, the majority of opcodes have a cost of 1, and they dominate.
For every expensive opcode, during emission, we increase the compute_meter by the opcode cost minus 1. Opcode extra costs are stored in an array, so one can index directly into it during instruction emission via the u8 insn.opc. The load and add instruction is not emitted when the extra cost is 0 (obviously).
At the very least, the cost of adding a constant value to the compute meter during execution, being an ALU operation, is at least comparable to the cost of an expensive operation. For instance, a memory operation will probably always have to be at least 30x CUs of an ALU, so the cost of loading the compute meter, probably living in the L1 cache, and adding a constant to it will consume far fewer cycles by comparison.
Another option is if the bpf can be analysed and segmented into basic blocks, thus reducing the need to deal with arbitrary jumps. (Edit: I guess this is ongoing work with static analysis).
For every ordinary opcode, we do nothing as per the constant 1 integral.

Thankfully, static analysis is always possible as there are no arbitrary code jumps in eBPF - jumps are always to an inlined offset.

For the reason that static analysis may be expensive in the malicious or even non-malicious scenario, I think this approach may be a good way to perform "intermediate JIT" in the non-uniform opcode cost case.
The static analysis could then only be applied to programs that live for a long time in the executor cache, as a one-time cost.

Even if the static analysis is expensive, it would probably be possible to compile asynchronously in a background thread, and silently replace the JITed binary by acquiring a write lock to the cache.

Thankfully, static analysis is always possible as there are no arbitrary code jumps in eBPF - jumps are always to an inlined offset.

Unfortunately, we have ebpf::CALL_REG (callx instruction) which is a dynamic (unpredictable) jump.

May I know if a non-uniform opcode compute unit cost table is on the horizon?

Yes, I don't see why not. In fact it is a lot simpler than you think and works with the current approach out-of-the-box.
We only have to add an explicit cumulative cost table instead of using the pc directly. There is no need to emit any extra x86 instructions for more expensive BPF instructions.

Here, I sketched a small python prototype to illustrate how it works:
import random

def generate_randomized_trace(cost_limit, cost_of):
    cumulative_cost = reduce(lambda c, x: c + [c[-1] + x], cost_of, [0])
    program_length = len(cost_of)
    interpreter_instruction_meter = 0
    jit_instruction_meter = cost_limit
    cost_limit_reached = False
    ip_pc = 0
    while True:
        if ip_pc + 1 >= program_length:
            print("Program reached the end")
            return
        interpreter_instruction_meter += cost_of[ip_pc]
        print("ip/pc={} interpreter={}/{} jit={}/{}".format(ip_pc,
            interpreter_instruction_meter, cost_limit,
            cumulative_cost[ip_pc + 1], jit_instruction_meter,
        ))
        interpreter_limit_reached = cost_limit <= interpreter_instruction_meter
        jit_limit_reached = jit_instruction_meter <= cumulative_cost[ip_pc + 1]
        if (interpreter_limit_reached or jit_limit_reached) and not cost_limit_reached:
            cost_limit_reached = True
            print("Cost limit reached by interpeter={} jit={}".format(
                interpreter_limit_reached, jit_limit_reached))
        if random.randint(0, 100) < 20:
            target_ip_pc = random.randint(0, program_length - 1)
            jit_instruction_meter -= cumulative_cost[ip_pc + 1]
            jit_instruction_meter += cumulative_cost[target_ip_pc]
            print("Jump to ip/pc={}".format(target_ip_pc))
            if cost_limit_reached:
                print("JIT aborted branch")
                return
            else:
                ip_pc = target_ip_pc
        else:
            ip_pc += 1

generate_randomized_trace(64, [random.randint(1, 3) for _ in range(0, 100)])

Which, for example generates the following trace:
ip/pc=0 interpreter=1/64 jit=1/64
ip/pc=1 interpreter=4/64 jit=4/64
ip/pc=2 interpreter=6/64 jit=6/64
ip/pc=3 interpreter=9/64 jit=9/64
ip/pc=4 interpreter=11/64 jit=11/64
Jump to ip/pc=8
ip/pc=8 interpreter=12/64 jit=17/69
Jump to ip/pc=63
ip/pc=63 interpreter=14/64 jit=128/178
ip/pc=64 interpreter=17/64 jit=131/178
Jump to ip/pc=89
ip/pc=89 interpreter=18/64 jit=177/223
ip/pc=90 interpreter=19/64 jit=178/223
ip/pc=91 interpreter=20/64 jit=179/223
ip/pc=92 interpreter=22/64 jit=181/223
Jump to ip/pc=45
ip/pc=45 interpreter=23/64 jit=90/131
ip/pc=46 interpreter=25/64 jit=92/131
ip/pc=47 interpreter=26/64 jit=93/131
ip/pc=48 interpreter=28/64 jit=95/131
Jump to ip/pc=69
ip/pc=69 interpreter=29/64 jit=142/177
ip/pc=70 interpreter=30/64 jit=143/177
ip/pc=71 interpreter=32/64 jit=145/177
ip/pc=72 interpreter=33/64 jit=146/177
Jump to ip/pc=29
ip/pc=29 interpreter=34/64 jit=59/89
ip/pc=30 interpreter=36/64 jit=61/89
ip/pc=31 interpreter=37/64 jit=62/89
ip/pc=32 interpreter=38/64 jit=63/89
ip/pc=33 interpreter=39/64 jit=64/89
ip/pc=34 interpreter=40/64 jit=65/89
ip/pc=35 interpreter=43/64 jit=68/89
ip/pc=36 interpreter=46/64 jit=71/89
ip/pc=37 interpreter=49/64 jit=74/89
ip/pc=38 interpreter=50/64 jit=75/89
ip/pc=39 interpreter=53/64 jit=78/89
ip/pc=40 interpreter=54/64 jit=79/89
ip/pc=41 interpreter=57/64 jit=82/89
Jump to ip/pc=47
ip/pc=47 interpreter=58/64 jit=93/99
ip/pc=48 interpreter=60/64 jit=95/99
ip/pc=49 interpreter=63/64 jit=98/99
ip/pc=50 interpreter=64/64 jit=99/99
Cost limit reached by interpeter=True jit=True
ip/pc=51 interpreter=67/64 jit=102/99
ip/pc=52 interpreter=68/64 jit=103/99
ip/pc=53 interpreter=71/64 jit=106/99
ip/pc=54 interpreter=73/64 jit=108/99
ip/pc=55 interpreter=76/64 jit=111/99
Jump to ip/pc=75
JIT aborted branch

So the only difference to how it currently is, is that cumulative_cost is not the identity function anymore, but the lookup can happen at compile time.

Yep, that integral trick is very elegant. Still makes me worried about long straight-line programs.

Still makes me worried about long straight-line programs.

We could emit phony branches if we detect long linear runs, but these are not particularly useful anyway.
And, yes I am aware that these programs are still turing complete and things like the movfuscator exist, but they also prove how limited this approach is as it bloats the program size tremendously.

@Lichtso my worry is not the detection per-se but rather to catch such programs in the act so they don't run for say 100ms rather than say a target 10ms.
There's actually a separate issue involved, which is that if the program throws an error or panics after it was supposed to have run out of budget, then it may return a different return type. I guess this wouldn't be a problem if every error or branch into an error also first checks the compute meter (perhaps already subsumed under the conditions for returning)

There's actually a separate issue involved, which is that if the program throws an error or panics after it was supposed to have run out of budget, then it may return a different return type

Interesting idea, might not be covered so far, but would have to write a test case for that.
This is what we currently have:
https://github.com/solana-labs/rbpf/blob/42ca251fdb77ce106a57b37f1ad353a0b0207209/src/jit.rs#L436


added support for angular 1.5 component

Hi, I'd like to add support for Angular 1.5 components.
I've tried creating a simple component with it (just passed an object in and display the value) and it worked. I used Dojo as my AMD loader, though I expect it should also work with Requirejs.
Angular 1.5 components pass a JS object (option) instead of a function (constructor) as the second parameter, but since everything is just being passed directly to Angular I don't see this being an issue.
BTW I would like to mention that the way angularAMD was written, it made it easy to add support for an additional Angular feature. Thanks for making the code easy to modify, and thank you for making angularAMD.

See also PR #163
I think the build seems to fail in the main branch as well so it's probably not your commit causing it to fail.
@marcoslin
Any ideas on why build is failing? Is this repo no longer maintained?

Thanks @andidev. For some reason I can't get npm test to run on my windows machine even with a bash shell, so I've been relying on travis-ci.

@andidev you're right, I undid my changes and pushed, the build is still breaking

Hi there,
does it function meanwhile? I mean the component support?


[NUCLEO_L152RE] RTOS clock config enhanced

What was the reason of closing this?
Please provide description for PR - brief summary, thanks

I can't pull the request because some files are not in write access.
So I decide to close the request and re-do it later with a clean of my local GIT before.


Add package dependency 'editorconfig' in Readme?

I see that one of the recent pr #7 introduces a dependency.

Thanks for your suggestion.
I also add a dependency declaration in copilot.el, so it can be resolved automatically if use straight.el.


update edmf documentation

Purpose

To-do

Content

[ ] I have read and checked the items on the review checklist.

This is not finished, but I will merge the current changes and work on the documentation later.


[Run] Modify background transparency

Description of the new feature / enhancement

Scenario when this would be used?
搜索是背景变成亚克力或者透明
Supporting information
No response

/dup #4794


Solve security access problem

The tornado backend server should be deployed only on loopback interface.

Hi @andfoy I run a vulnerability database at https://pyup.io - quick question, was this a vulnerability fix? Thanks!


!virus!

Trojan horse virus detection in NvRemixBridge.exe file
remix version-0.2.0

This is likely a false positive if you downloaded Remix from either GitHub or built it yourself.
Remix is known to trigger some antiviruses likely due to some of the strange things it does compared to most applications, we sign the GitHub release binaries which helps antiviruses not freak out as much I think, but CI builds from GitHub are unsigned and may cause more false positives as a result.


feature: Add subgraph enumerator

Signed-off-by: xiejiann<EMAIL_ADDRESS>Proposed changes
Issue Number: close #xxx
Add subgraph enumerator to find the best plan
Problem summary
For DPHyp, we need an enumerator to find the best plan
Checklist(Required)

Does it affect the original behavior:

[ ] Yes
[ ] No
[ ] I don't know

Has unit tests been added:

[ ] Yes
[ ] No
[ ] No Need

Has document been added or modified:

[ ] Yes
[ ] No
[ ] No Need

Does it need to update dependencies:

[ ] Yes
[ ] No

Are there any changes that cannot be rolled back:

[ ] Yes (If Yes, please explain WHY)
[ ] No

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 35.33 seconds
load time: 456 seconds
storage size:<PHONE_NUMBER>6 Bytes
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20221116013138_clickbench_pr_46688.html


Added SleepSort [java]

Fixes #490
By submitting this pull request I confirm I've read and complied with the below declarations.

[x] I have read the Contribution guidelines and I am confident that my PR reflects them.
[x] I have followed the coding guidelines for this project.
[x] My code follows the skeleton code structure.
[x] This pull request has a descriptive title. For example, Added {Algorithm/DS name} [{Language}], not Update README.md or Added new code.
[x] This pull request will be closed if I fail to update it even once in a continuous time span of 7 days.

Hi! Thanks for showing interest in contributing to this repository.
Please make sure that you have ticked the points mentioned in PR description correctly.
Thanks again!

Hi @singhpratyush ,
My code has now passed the checks by travis however it has failed the gitmate check.
Are there any other changes required?

@ashutosh-wad: We're okay with that.

Hi @singhpratyush ,
Is there anything else required from my end?


support building in koji for new dist-git commits

Support koji builds for new dist-git commits.

[ ] Verify, that we accept new events for dist-git commits.
[ ] Implement the handler (decide with the team):

[ ] Either enhance the KojiBuildHandler to differentiate between upstream and downstream git forge and act differently.
[ ] Or, create a new handler and new job type.

Edit: complete rewrite v2 by @lachmanfrantisek

@TomasTomecek can you elaborate on this one? The team is confused. (Is this still needed/wanted?)

@lachmanfrantisek good point, I actually didn't remember what this really was; updated and scoped it down as much as possible

Yep, we still need to be able to build downstream.

Still relevant.

@lachmanfrantisek this is pretty much your task in this sprint, right?

@TomasTomecek I saw koji build and agreed, but this is about propose-downstream, isn't it? I implemented only upstream triggers -- PR, branch-push and release.

When is this expected to run? When the downstream PR is created?
Do we want to inform the user in upstream or downstream?

Good points, we'd need to spend some time on designing this. Ideally we'd just build on dist-git pushes and inform people in the upstream if something goes wrong

Laura is fixing the sync-from-downstream job that requires reacting to dist-git commits as well. We are getting closer.

Yes, we just need to figure out a mechanism for people to configure downstream jobs in the upstream - having .packit.yaml in dist-git was a dead-end from my PoV.

Thinking about this, the workflow used in upstream sends the SRPM directly to Koji so it's not what we want here.
We should:

[ ] Verify, that we accept new events for dist-git commits.
[ ] Implement the handler:

Either enhance the KojiBuildHandler to differentiate between upstream and downstream git forge and act differently.
Or, create a new handler and new job type. (A bit confusing for users but cleaner from the code perspective I think.)

I interpreted this RFE incorrectly before :-( ... so lemme dump a wish here (as I believe it would be for free, if this  RFE #55 was implemented)...
Even when Packit upstream workflow is not in use -- it would be nice if we (maintainers) could just manually push to dist-git, and the build was automatically submitted into Koji (submit can be done by any service, but if Packit did this, I'm +1).  Configuration like this would be enough.
auto-koji-build-upon-push: [praiskup, ...]

It would be a pity if we bound this cool thing only to upstream-packit workflows, and to the propose_downstream.
I feel a slight mismatch here... meh, so in case this is inapropriate request - perhaps we should consider if we shouldn't implement something like this elsewhere...

auto-koji-build-upon-push: [praiskup, ...]

I mean, I don't want to break releng's scripts, etc. - so perhaps we shouldn't trigger builds for everybody without asking ... therefore the configured list of push event "authors"...

@praiskup You are right, the term propose-downstream is here a bit misleading. The task (as I understand it) is to react to a new dist-git commit and submit a koji build for that commit.
The (only) question here is, how this can be configured/enabled (can be combined):

Packit config in downstream.
Hardcoded in the service.
Dashboard or some web-UI to enable this.
Some comment/issue we can react on and automatically save this value to the database.
... anything else?

Anything works for me (if that matters) but if the config lived in dist-git, that would be super trivial to setup IMO.

We should have a card to discuss our plans for downstream so just a few notes for the assigned person to cover more points of view on this:

Configuration / how to enable this (packit config x separate service to turn this on x ...)
Code (inside packit and reuse all the listeners and scheduling x do a separate service from scratch)
Packit's instance (reuse the one(s) we have x separate)
Fedora identity in downstream (do we need/want to ask for a new one?)

Regarding the wider audience, do you think creating a new service can bring a wider audience? (We already promised our plans for this on behalf of Packit that finally is somehow known.)
After some thinking about this, I like the idea of decoupling the configuration and adding the functionality as new handlers. Or start with packit config, implement the functionality, test it with packit configs in downstream and do the separate (proper) way of turning this on afterwards. (To have smaller chunks of work and some MVP sooner.)

sync to jira

sync to jira, please

sync to jira, pretty please


Host on NPM? / use npx

Any chance this will end up being hosted on npmjs.com so we could use npx to run instead of installing globally?

Also, fwiw, I used this yesterday to scaffold the OSHPD theme. Worked great. Thanks!!

Yeah, it should be published after we've QA'd it to death. I'll keep this open and assign it to myself as a reminder.

Closing this out: https://www.npmjs.com/package/@10up/create-10up


Add NativeScripts

Basing this on #866 because it only works with CSL fee calculation.
Closes #791
Pre-review checklist

[x] All code has been formatted using our config (make format)
[x] The integration and unit tests have been run (npm run test) locally
[x] The changelog has been updated under the ## Unreleased header, using the appropriate sub-headings (### Added, ### Removed, ### Fixed), and the links to the appropriate issues/PRs have been included

Converting to draft, because without https://github.com/Plutonomicon/cardano-transaction-lib/issues/871 this API is mostly unusable.

Should we add an example that can be run in the browser as well?

We need multiple parties. Too hard to implement with wallets.


Add an option to set ufunc identity with vectorize?

Another way to write (some) custom aggregation functions, other than my suggested approach in #825, would be use plain old ufuncs.
This has the advantage of passing off the axis handling/looping to numpy's ufunc.reduce method. And in fact, it already almost works:
@vectorize(['float64(float64, float64)'])
def _nanadd(a, b):
    if np.isnan(b):
        return a
    else:
        return a + b

nansum = _nanadd.reduce

As a bonus, this method is consistently fast. It's generally slightly (~20%) slower than bottleneck, but it has better worst case performance: bottleneck.nansum slows down by a factor of 4x when aggregating over a non-contiguous dimension (e.g., axis=0 for a 2-dimensional C contiguous array), but the nansum ufunc doesn't miss a beat. I suspect this is because numpy has some clever logic for picking the optimal ordering for nested iteration for ufunc.reduce.
What's missing? There's no way to set _nanadd.identity = 0.0, which we would need to ensure that the calculation is correct if any of the first values are missing.
So I propose that vectorize should gain the optional keyword argument identity to set this variable. Right now it is always set to None: https://github.com/numba/numba/blob/1f4bee0a86edc20c9d3de07046af0d77dfa75469/numba/npyufunc/_ufunc.c#L5

Or perhaps make the identity attribute writable, to avoid adding another parameter to vectorize?

Ah, but that doesn't work due to the attribute not being writable on numpy ufuncs. Scratch that.

Ok, Numpy allows for four different identity (or unit) values:

zero
one
none, meaning no unit, and the order of operations cannot be reordered (sic); for example subtract, divide, power
reorderable none, no unit, and the order of operations can be reordered (sic); for example maximum and minimum

All cases except "none" allow reduction with multiple axes at once.

Interesting-- does numpy really only allow those specific values? I can see other also being potentially useful, e.g., -1 or NaN as sentinel values.
On Thu, Jan 8, 2015 at 8:54 AM, Antoine Pitrou<EMAIL_ADDRESS>wrote:

Ok, Numpy allows for four different identity (or unit) values:

zero
one
none, meaning no unit, and the order of operations cannot be reordered (sic); for example subtract, divide, power
reorderable none, no unit, and the order of operations can be reordered (sic); for example maximum and minimum
All cases except "none" allow reduction with multiple axes at once.

Reply to this email directly or view it on GitHub:
https://github.com/numba/numba/issues/829#issuecomment-69209598

I was surprised too:
https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/ufuncobject.h#L141-L142
https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/ufuncobject.h#L271-L290

I guess numba would need to define a ReorderableNone constant in order to allow the last case? It looks like there is no python exposure of that constant in numpy.

I guess numba would need to define a ReorderableNone constant in order to allow the last case?

I was thinking a string (e.g. "reorderable") would be sufficient.


Can't get the console of a LXD container.

Is it possible to get a console to a LCD container?

Regards,

Unfortunately that hasn't worked in awhile and I'm not sure why. I'll need to talk to the OpenStack charmers to figure out why

@rhickstedjr can you please help me?
seems your installation is working
I have been having issues installing this thing and no luck for almost 3 months now
are you installing Openstack Autopilot or the LXD version?

LXD version I just saw a demo in Austin at the last summit.
Thanks,
Sent from my iPhone
On May 7, 2016, at 4:13 PM, babatundebusari <notifications<EMAIL_ADDRESS>wrote:
@rhickstedjrhttps://github.com/rhickstedjr can you please help me?
seems your installation is working
I have been having issues installing this thing and no luck for almost 3 months now
are you installing Openstack Autopilot or the LXD version?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Ubuntu-Solutions-Engineering/conjure-up/issues/14#issuecomment-217674771

@rhickstedjr Did you ever try to install Openstack Autopilot
That one i think does not work

I have installed the ubuntu juju based openstack install on 12x Intel NUCs.  I have not really used autopilot.
Thanks,
Rick

From: babatundebusari<EMAIL_ADDRESS>Sent: Saturday, May 7, 2016 4:42:47 PM
To: Ubuntu-Solutions-Engineering/conjure-up
Cc: Rick Hicksted; Mention
Subject: Re: [Ubuntu-Solutions-Engineering/conjure-up] Can't get the console of a LXD container. (#14)
@rhickstedjrhttps://github.com/rhickstedjr Did you ever try to install Openstack Autopilot
That one i think does not work

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Ubuntu-Solutions-Engineering/conjure-up/issues/14#issuecomment-217677299

@rhickstedjr how? using conjure-up? or using the Ubuntu 14.04 LTS Openstack Autopilot using landscape?
If you can help me take a look what am doing wrong will highly appreciate it man
I have been trying this thing for 3 months, i have reinstalled OS like so many times, its crazy
Also installing OS takes over 30 minutes, i mean not sure am if its me or just takes that long. Even my hard drives are wearing out with the writes every time
Can't seem to get this thing to work and not sure what is wrong and where

How do i access the dashboard for the LXD version?
I started installation but because my VPN connection to the datacenter keeps reconnecting, i might have lost the realtime SSH session for the installation so am stuck on this screen after like an hour or more now

So i think the installation probably finished, because from htop the machine is pretty busy and its over an hour since installation started.

So how do i know if it really has completed? and how do i access the dashboard GUI?

So you can re-run conjure-up openstack -s with the (-s) and it'll reconnect to your deployment. If you want to access your dashboard from a remote system do something like:
sshuttle -r user@host <IP_ADDRESS>/24

Then you should be able to connect directly to the dashboard's ip address <IP_ADDRESS> using admin/openstack to login

Also be aware of https://bugs.launchpad.net/juju-core/+bug/1574844 which is a problem with juju and ipv6 which you seem to be hitting as well. It can easily be fixed by disabling ipv6
see https://askubuntu.com/questions/440649/how-to-disable-ipv6-in-ubuntu-14-04

When it is done you will see the Horizon access URL at the bottom of the conjure-up screen.
Thanks,
Rick

From: babatundebusari<EMAIL_ADDRESS>Sent: Saturday, May 7, 2016 5:56 PM
To: Ubuntu-Solutions-Engineering/conjure-up
Cc: Rick Hicksted; Mention
Subject: Re: [Ubuntu-Solutions-Engineering/conjure-up] Can't get the console of a LXD container. (#14)
How do i access the dashboard for the LXD version?
I started installation but because my VPN connection to the datacenter keeps reconnecting, i might have lost the realtime SSH session for the installation so am stuck on this screen after like an hour or more now
[screen shot 2016-05-07 at 8 52 42 pm]https://cloud.githubusercontent.com/assets/6054104/15095473/e1ba4f78-1495-11e6-8e7d-7d98c032c27c.png
[https://cloud.githubusercontent.com/assets/6054104/15095473/e1ba4f78-1495-11e6-8e7d-7d98c032c27c.png]
So i think the installation probably finished, because from htop the machine is pretty busy and its over an hour since installation started.
[screen shot 2016-05-07 at 8 52 14 pm]https://cloud.githubusercontent.com/assets/6054104/15095482/3a83aac8-1496-11e6-8e28-fefc91c2031a.png
So how do i know if it really has completed? and how do i access the dashboard GUI?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Ubuntu-Solutions-Engineering/conjure-up/issues/14#issuecomment-217681137

Looks like the reconnects automatically itself, so apparently it takes REALLY long to complete installation
Still progressing as i can see

here is where am at now, don't know if this will fail again after probably over 2 hours now

Yea neutron-api has a ipv6 address which causing it to be in error, you'll want to reference that bug i posted earlier

@battlemidget
so i should disable ipv6 right now as the installation is currently running?
Also to disable ipv6, i need to do this?
up vote
96
down vote
accepted
To disable ipv6, you have to open /etc/sysctl.conf using any text editor and insert the following lines at the end:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
If ipv6 is still not disabled, then the problem is that sysctl.conf is still not activated.

To solve this, open a terminal(Ctrl+Alt+T) and type the command,

sudo sysctl -p
You will see this in the terminal:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
After that, if you run:

$ cat /proc/sys/net/ipv6/conf/all/disable_ipv6
It will report:

1
If you see 1, ipv6 has been successfully disabled.

@battlemidget if i disable ipv6 now the installation is still running, won't that break installation?
or i have to rerun the installation all over again from scratch?

ok since no quick reply i have gone ahead and disabled ipv6

and now the installation still hows ipv6 though not sure if things will complete now

@battlemidget
Ok i have disabled ipv6, what do i do next to make this installation complete successfully?

I disabled IPv6 to get mine installed as well.
Thanks,
Sent from my iPhone
On May 7, 2016, at 6:53 PM, babatundebusari <notifications<EMAIL_ADDRESS>wrote:
@battlemidgethttps://github.com/battlemidget
Ok i have disabled ipv6, what do i do next to make this installation complete successfully?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHubhttps://github.com/Ubuntu-Solutions-Engineering/conjure-up/issues/14#issuecomment-217682548

@rhickstedjr
one quick question
when you choose the ip block to be used by LXD, what ip block did you choose?
do you have to have a vlan dedicated for LXD?
Am asking because LXD choose to use <IP_ADDRESS>/24 and now it says i can access dashboard on http://<IP_ADDRESS>/horizon but i have no network connection to get to that network.
I can get to the VLAN  i created and that VLAN can get to that network , but i can't go directly to that network.
So wanted to know how to choose the network to be used by LXD

never mind
just figured i have to choose an IP block in my VLAN for lxd

Bonjour,
Juste to say that i try to deploy it, if someone has a howto , I'm interested. especially for the physical architecture multi servers. conjure-up will plaise me.
Merci.

ok just tried another brand new install of Ubuntu 16.04 LTS on a different server
and getting errors
I also made sure no ipv6 for this install this time
screesnhots posted below

So there is an update waiting to be pushed to the archive that fixes this error, for now though you can add our ppa,
apt-add-repository ppa:conjure/ppa

Soon as it gets approved it'll be in the archive, you don't need to re-install everything though just running
conjure-up openstack -s

Will bring you back to the status screen and kick off the post processing to make sure your services are configured. Then you can access the dashboard (via sshuttle as posted earlier)

@battlemidget
ok i did that
ubuntu@ubuntu101:~$ sudo apt-add-repository ppa:conjure/ppa
[sudo] password for ubuntu:
 Contains the conjure runtime and applicable packages supported by conjure
 More info: https://launchpad.net/~conjure/+archive/ubuntu/ppa
Press [ENTER] to continue or ctrl-c to cancel adding it

gpg: keyring `/tmp/tmpnnivzn1i/secring.gpg' created
gpg: keyring `/tmp/tmpnnivzn1i/pubring.gpg' created
gpg: requesting key 4CD5D8B2 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpnnivzn1i/trustdb.gpg: trustdb created
gpg: key 4CD5D8B2: public key "Launchpad PPA for conjure" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
ubuntu@ubuntu101:~$ conjure-up openstack -s

and here is what i get after

ok i am having problem connecting to the ip address block created by LXD
LXD creates this IP address block so how does one route to that network block?
the machine where LXD is setup has access to the block
ubuntu@ubuntu101:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.055 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.068 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=0.059 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=64 time=0.053 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=64 time=0.064 ms
^C
--- <IP_ADDRESS> ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5001ms
rtt min/avg/max/mdev = 0.049/0.058/0.068/0.006 ms
ubuntu@ubuntu101:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.065 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.068 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.076 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=0.067 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=64 time=0.073 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=64 time=0.060 ms
^C
--- <IP_ADDRESS> ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 0.060/0.068/0.076/0.007 ms

but another machine with another IP address on VLAN cannot get to it
ubuntu@ubuntu102:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.430 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.219 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.235 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=0.226 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=64 time=0.292 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=64 time=0.206 ms
^C
--- <IP_ADDRESS> ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4997ms
rtt min/avg/max/mdev = 0.206/0.268/0.430/0.077 ms
ubuntu@ubuntu102:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
From <IP_ADDRESS> icmp_seq=1 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=2 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=3 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=4 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=5 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=6 Destination Host Unreachable
^C
--- <IP_ADDRESS> ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7039ms
pipe 3

What do i do now? and how do i select ip address block of LXD so that i can still route to the ip network?

@rhickstedjr  I think the post above this comment was meant to highlight you and not me. :-)

The solution for this was on the issue 8 thread:
hit enter without typing any passwords in
$ ssh-keygen
$ source /usr/share/openstack/bundles/common-openstack/novarc
$ openstack keypair create —public-key $HOME/.ssh/id_rsa.pub ubuntu-keypair
Thanks,
Rick

On May 8, 2016, at 8:19 AM, babatundebusari<EMAIL_ADDRESS>wrote:
@battlemidget
ok i did that
ubuntu@ubuntu101:~$ sudo apt-add-repository ppa:conjure/ppa
[sudo] password for ubuntu:
Contains the conjure runtime and applicable packages supported by conjure
More info: https://launchpad.net/~conjure/+archive/ubuntu/ppa
Press [ENTER] to continue or ctrl-c to cancel adding it
gpg: keyring /tmp/tmpnnivzn1i/secring.gpg' created gpg: keyring /tmp/tmpnnivzn1i/pubring.gpg' created
gpg: requesting key 4CD5D8B2 from hkp server keyserver.ubuntu.com
gpg: /tmp/tmpnnivzn1i/trustdb.gpg: trustdb created
gpg: key 4CD5D8B2: public key "Launchpad PPA for conjure" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
OK
ubuntu@ubuntu101:~$ conjure-up openstack -s
and here is what i get after
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@rhickstedjr
Did you see my last response about not able to access the IP of dashboard?
How did you setup your networking?
You can read my last comment above

I took the defaults configuring the LXD bridge.

Thanks,
Rick

On May 8, 2016, at 7:22 PM, babatundebusari<EMAIL_ADDRESS>wrote:
@rhickstedjr
Did you see my last response about not able to access the IP of dashboard?
How did you setup your networking?
You can read my last comment above
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

@rhickstedjr
Ok will apply the fix you sent, but to be honest i generated SSH keys earlier before and since then never got any error messages anymore, as you see from my latest screenshots, everything seem to be fine now only need to access the dashboard
Also do you mind giving an example of how your networking for LXD is? What is your VLAN like and what was the ip address block like?
From the networking i think i may have issues accessing is still just from what i posted earlier, i couldn't ping that ip address from another machine

@battlemidget
I sent you the login to this machine to your email
Thanks

As I posted at least twice already, you need to use sshuttle to be able to access the dashboard from a remote machine

@battlemidget
Where did you mention sshuttle?
I am already using a VPN, or how do you think i connect to those machines on their private IP addresses? I only give you the public IP address because its easier than setting you up with VPN to get in
Were you able to login to see the machine?
Am i missing anything?
Please look at the previous message i wrote above
will paste it below again

@battlemidget
@rhickstedjr
ok i am having problem connecting to the ip address block created by LXD
LXD creates this IP address block so how does one route to that network block?
ip address of horizon dashboard is <IP_ADDRESS>8
VLAN is <IP_ADDRESS>/16
LXD ip network block is <IP_ADDRESS>/24
the machine where LXD is setup has access to the block
ubuntu@ubuntu101:~$ ifconfig
enp4s0f0  Link encap:Ethernet  HWaddr 78:e7:d1:21:e9:e8
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::7ae7:d1ff:fe21:e9e8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3271187 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2389657 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2999060691 (2.9 GB)  TX bytes:354598731 (354.5 MB)
          Memory:ef000000-ef01ffff
ubuntu@ubuntu101:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.055 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.068 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=0.059 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=64 time=0.053 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=64 time=0.064 ms
^C
--- <IP_ADDRESS> ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5001ms
rtt min/avg/max/mdev = 0.049/0.058/0.068/0.006 ms
ubuntu@ubuntu101:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.065 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.068 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.076 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=0.067 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=64 time=0.073 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=64 time=0.060 ms
^C
--- <IP_ADDRESS> ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5006ms
rtt min/avg/max/mdev = 0.060/0.068/0.076/0.007 ms

but another machine with another IP address on VLAN cannot get to it
ubuntu@ubuntu102:~$ ifconfig
enp4s0f0  Link encap:Ethernet  HWaddr 78:e7:d1:21:e7:e8
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3659723 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2166837 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3001811726 (3.0 GB)  TX bytes:394821470 (394.8 MB)
          Memory:ef000000-ef01ffff
ubuntu@ubuntu102:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from <IP_ADDRESS>: icmp_seq=1 ttl=64 time=0.430 ms
64 bytes from <IP_ADDRESS>: icmp_seq=2 ttl=64 time=0.219 ms
64 bytes from <IP_ADDRESS>: icmp_seq=3 ttl=64 time=0.235 ms
64 bytes from <IP_ADDRESS>: icmp_seq=4 ttl=64 time=0.226 ms
64 bytes from <IP_ADDRESS>: icmp_seq=5 ttl=64 time=0.292 ms
64 bytes from <IP_ADDRESS>: icmp_seq=6 ttl=64 time=0.206 ms
^C
--- <IP_ADDRESS> ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 4997ms
rtt min/avg/max/mdev = 0.206/0.268/0.430/0.077 ms
ubuntu@ubuntu102:~$ ping <IP_ADDRESS>
PING <IP_ADDRESS> (<IP_ADDRESS>) 56(84) bytes of data.
From <IP_ADDRESS> icmp_seq=1 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=2 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=3 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=4 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=5 Destination Host Unreachable
From <IP_ADDRESS> icmp_seq=6 Destination Host Unreachable
^C
--- <IP_ADDRESS> ping statistics ---
8 packets transmitted, 0 received, +6 errors, 100% packet loss, time 7039ms
pipe 3

What do i do now? and how do i select ip address block of LXD so that i can still route to the ip network?

Use sshuttle as I said before:
https://github.com/Ubuntu-Solutions-Engineering/conjure-up/issues/14#issuecomment-217681478

@battlemidget
So where do i use sshuttle from?
From my computer or from a desktop in the VLAN?
From my computer i already use VPN to get into my remote infrastructure in a datacenter
So where exactly will sshuttle command be ran from?

In addition to using your VPN you would run this sshuttle command to access the LXD containers from your computer.

Ok so before this issue was hijacked I've create the necessary bugs to have Horizon support a Console via Nova LXD.
https://github.com/lxc/nova-lxd/issues/128
@rhickstedjr as it stands now there isn't a way to make this work and those bugs are for tracking that progress.

Closing this as it's being ttracked in the previous comments bug


update to 6.0.201

Checklist

[x] Used a personal fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Thanks @acesnik! I added the automerge label so it will merge when CI passes. feel free to remove that if you want to make any changes, otherwise if you push any further commits it should be automatically removed.


Some improvements

Hello,
I was looking for something to do what your script does, decided I needed to make some small changes and ended up rewriting a fair bit of it.
These are the main changes:

Configuration file location can be passed as an argument (which is useful, e.g., to run this as an unprivileged user or in systems with a different file system structure)
The format of the permit/reject lines is configurable (which is useful for things other than Postfix)
The script now runs in shells other than Bash. I tried to rewrite so that it can be run in any POSIX shell.
Redundant code for whitelist/blacklist was minimised.
printf no longer takes external inputs directly (e.g., printf $dns_record was rewritten as printf %s $dns_record)
the IP validation code now will only accept valid IPv4 addresses (but no validation or normalisation is done yet for IPv6)

I'd be great if you'd accept my changes, although I understand if you don't, as I've rewritten a fair chunk of it. However, you may still find the first two changes useful and those don't require as much rewriting.

Hi, @corrideat. Wow! Impressive work. Thank you! I'm traveling this weekend, but will definitely check out the changes when I'm back home on Monday, test, and merge!


Feat/#37 cli generate entity

This PR to create a new js file to help generate entity file
To test please follow these steps.
cd  <your_workspace>/aloxide
node generate-entity.js

And then answers the questions that will be appeared on your screen to generate your entities

Codecov Report

Merging #125 (701009f) into develop (f2fcf20) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #125   +/-   ##
========================================
  Coverage    95.16%   95.16%
========================================
  Files           69       69
  Lines         1096     1096
  Branches       129      129
========================================
  Hits          1043     1043
  Misses          53       53

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 f2fcf20...701009f. Read the comment docs.


Materialize is broken in the latest version of orionjs:materialize (1.4.9)

Here is the error I get:
Uncaught TypeError: Cannot set property 'guid' of undefined
global-imports.js:4 Uncaught TypeError: Cannot read property 'Materialize' of undefined
template.home.js:2 Uncaught ReferenceError: Template is not defined
template.layout.js:2 Uncaught ReferenceError: Template is not defined
template.loading.js:2 Uncaught ReferenceError: Template is not defined
routes.js:1 Uncaught ReferenceError: FlowRouter is not defined
kadira_flow-router.js:1927 There is no route for the path: /Router._notfoundRoute @ kadira_flow-router.js:1927
softwarerero_accounts-t9n.js:41 Uncaught ReferenceError: UI is not defined

I have the same problem few hours ago. Try adding<EMAIL_ADDRESS>version because<EMAIL_ADDRESS>package does not work in Meteor yet.

Check this https://github.com/Dogfalo/materialize/issues/2043

oh I see! so the problem is with materialize:materialize 0.97.1. I'll just use 0.97.0 until they fixed it.
Thank you for the solution!


[Blocked] Write an Athena Query to split out per-hub EFS cost

Based on https://github.com/2i2c-org/infrastructure/issues/4465, we're going to be using AWS Athena to query billing data
For this task, we need to write an SQL query that provides these 4 columns as output

start_time
end_time
hub_name
cost

If there is any EFS cost that isn't assigned to a hub, that should also be reported.
What goes into this query should be guided by item 2 of definition of done below.
Definition of done

SQL query when executed provides information for all 3 hubs on the openscapes cluster
If you add the cost values for all the hubs, they must add up to what shows up under 'Elastic File System' in 'Cost Explorer' under 'Billing' in the AWS console.

Resources

Query Editor
Workshop with example Athena SQL queries against billing data - https://wellarchitectedlabs.com/cost-optimization/cur_queries/
Data dictionary for columns in billing export

Preliminary closed, but can be reopened if Athena becomes relevant.


MenuBar list items are not following high contrast in entire pane.

Copied from internal issue.
Pre-requisite:
Turn on High Contrast Mode. (Keyboard Shortcut: Alt+Shift+PrintScreen).
Repro steps :
Launch XAML Controls Gallery.
Activate MenuBar from All Controls Page.
Navigate to File/Edit/Help ->Activate it and observe it in high contrast.
Expected result:
List items should change its color according to high contrast.
In HC Black: Background should be Black with White text.
In HC White:Background should be white with black text.
Actual result:
List items are appearing in grey background in entire control page.

I can't seem to repro this using the MUXControlsTestApp:

Could this be an issue with the XAML Controls Gallery?

I can't seem to repro this using the MUXControlsTestApp:

Could this be an issue with the XAML Controls Gallery?

@chingucoding No, this is in MUXControlsTestApp:

I am not sure what you are referring to @Chips1234 , in the screenshot you posted the background of the flyout seems to be correct.

I am not sure what you are referring to @Chips1234 , in the screenshot you posted the background of the flyout seems to be correct.

@chingucoding Ah, I'm sorry. Now I see what the error is.

@StephenLPeters Can you still repo this issue?

I agree, this doesn't repro for me.


In iOS 18.2, the contextmenu cannot hide the "Copy Link With Highlight" option.

Is there an existing issue for this?

[x] I have searched the existing issues

Current Behavior
In iOS 18.2, the contextmenu has introduced the "Copy Link With Highlight" option. The previous implementation:
_contextMenu = ContextMenu(   settings: ContextMenuSettings(hideDefaultSystemContextMenuItems: true), );
is unable to hide this new option.
Expected Behavior
when hideDefaultSystemContextMenuItems: true can hide "Copy Link With Highlight"
Steps with code example to reproduce

Steps with code example to reproduce
// Paste your code here

Stacktrace/Logs

Stacktrace/Logs
<Replace this line by pasting your stacktrace or logs here>

Flutter version
v3.24.3
Operating System, Device-specific and/or Tool
ios 18.2
Plugin version
v6.1.5
Additional information
No response
Self grab

[ ] I'm ready to work on this issue!

same

you can remove    builder.remove(menu: .share) in  InAppWebView.swift

you can remove builder.remove(menu: .share) in InAppWebView.swift

Thank you, it works