Ramping the xbeach grid

capability to add offshore boundary ramp extending the bathymetry and grid

● Expand the offshore and cross-shore grid boundaries to provide smooth/consistent
boundary bathymetry
○ Offshore boundary:
■ User-specified maximum depth - defaults to -25.0m
■ User specified minimum-slope - defaults to -0.3 per metre
■ Maximum slope default is -0.3 * grid cell size
○ Cross-shore boundaries:
■ Expand grid by 5, duplicate bathymetry
from Simon's notes

As an aside, having the capacity to expand boundaries may be generally useful, XBeach-GPU requires boundaries have side lengths that are multiples of I think 16, in that case we've just duplicated the edge n lines identically to meet the computational requirement (which is just about domain decomposition for the GPU architecture).


User defined subsets (separate from selection)

We discussed giving the user the ability to define a subset of nodes/edges/tracks/lineages separate from (more persistent than) selection. This will be useful for visualizing only cells of interest to reduce visual clutter, setting attributes, and eliminating annoying issues with using selection to determine what is viewed when editing changes the selection. We can also re-use the UI to show subsets that are defined by attributes (e.g. pins, divisions)

Outcome of discussion:
The user can define groups of nodes, tracks, or lineages. Each group has a user defined name. Groups are stored in a dictionary in the Tracks object (probably), and potentially group names are also attributes (but this may not be necessary). "Pinned" or edited can be a group that is automatically created when the user edits. There could also be a "selection" group created automatically.
There are 3 types of group:

Lineage group - defined by a set of nodes, where each node is the earliest node in a lineage. (Note: need to update the start node if delete the first node or add a new first node) * this is easiest to start with, we think
Track group - defined by a set of nodes, where each node is the earliest node in a track. (Note: need to update the node if delete the first node or add a new first node). Alternatively, we could just list the track ids that are included in the group (and check if we deleted the whole track). (note #2: recoloring a whole track removes it from the group, because you delete the nodes and create new ones).
Node group - defined by a set of nodes. Edges with both endpoints in the set are included. (Note: need to delete nodes here when they are deleted from the UI).

There will be a tab in the right hand UI showing the current groups and allowing the user to create a new group, or delete a group (similar to the TracksList). Each group will show summary statistics (group type, number of nodes/tracks/lineages) in the list. Clicking on the group will update the "current" group, and allow the option in the "all"/"selected lineage"/"group" menu to only show things in the group (implemented for lineages already, needs some implementation for the other types of group) (note: maybe we don't need lineage anymore?). You can also save the group the same way you can save a tracks object (zeros out segmentation for nodes not in group). You can add selected nodes to the "current" group with a button/keybind (they are automatically added to the selection group).
P.S. For implementing the node group display. There is an issue with displaying only certain nodes from a track, because the napari layer doesn't let you set the colormap differently in different time points. A permanent solution would be to separate the Tracks.segmentation and the napari layer.data into different objects, and then the layer could actually put zeros in the time points it doesn't want ot be visible. A temporary solution would be what Anniek was doing to update the transparency of the colormap at every change of timepoint to hide tracks that don't have nodes in the current time point.

Ideas for groups that are automatically generated and updated:

current selection (we have this already)
edits/pins (as mentioned above)
lineages visible in the current field of view of the data (it might be nice if zooming in on the sample will also automatically hide the elements in the tree that are outside the view, especially when you have data with many objects).

Features on the Tracks, and then a separate Groups object in the data views part of the code. (No longer a dictionary on the Tracks)


Bump autofill to v15

Task/Issue URL: https://app.asana.com/0/72649045549333/1208618749197984/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

#5183  👈
develop

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @cmonfortep and the rest of your teammates on  Graphite


Plans to release Flamingov2 model weights

Hey, thanks for your great contributions. I saw a comment here (https://twitter.com/BoLi68567011/status/1684028048998559747) that you have trained Flamingo-Llama2-Chat7B and Flamingo-MPT7B models. However, unfortunately I couldn't find the corresponding weights for these models on HF: https://huggingface.co/luodian
Are you planning to release them soon, or if they are already released please let me know where I can access them :)

hi the flamingo one is there~
https://huggingface.co/luodian/Flamingo-Llama2-Chat7B-CC3M/tree/main

Thanks for the prompt response, can we simply load it like this?
from flamingo.modeling_flamingo import FlamingoForConditionalGeneration
flamingo_model = FlamingoForConditionalGeneration.from_pretrained("luodian/Flamingo-Llama2-Chat7B-CC3M", device_map=auto)

Or would the model class still have to be OtterForConditionalGeneration?

Awesome, thanks so much!


PWA-749 fix for test suite

Pull Request Test Coverage Report for Build 1603

0 of 5 (0.0%)  changed or added relevant lines in 3 files are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage remained the same at 0.0%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

e2e/integration/consistency/FavoritesPage.js
0
1
0.0%

e2e/integration/consistency/StartPage.js
0
2
0.0%

e2e/integration/functional/SearchPage.js
0
2
0.0%

Files with Coverage Reduction
New Missed Lines
%

e2e/integration/consistency/FavoritesPage.js
1
0.0%

e2e/integration/functional/SearchPage.js
1
0.0%

Totals

Change from base Build 1601:
0.0%

Covered Lines:
0

Relevant Lines:
5126

💛  - Coveralls


Release proposal: v1.30.1

I'm planning a patch release to address build errors on Android and Cygwin. I'm planning to make the release between today (7/2) and Friday (7/5). Please raise any questions, comments, or concerns here.

I merged #2324 today which might be less suitable for a patch release. You can revert, release and revert-revert it if you want.

I've rebased that commit out for now. I'll put it back when I make the release.

CI: https://ci.nodejs.org/view/libuv/job/libuv-test-commit/1450/
Node.js Integration CI: https://ci.nodejs.org/view/libuv/job/libuv-in-node/100/


fix and re-land "re-enable android_view_test (#54214)"

Description
The tests were broken because each test assume it starts from the home page but none return to the home page after finishing.
Added mechanisms for each test page to go back to the home page.
Related Issues
https://github.com/flutter/flutter/issues/54022
Tests
I added the following tests:
'MotionEvent recomposition
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I read the Tree Hygiene wiki page, which explains my responsibilities.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Did any tests fail when you ran them? Please read Handling breaking changes.

[x] No, no existing tests failed, so this is not a breaking change.
[ ] Yes, this is a breaking change. If not, delete the remainder of this section.

[ ] I wrote a design doc: https://flutter.dev/go/template Replace this with a link to your design doc's short link
[ ] I got input from the developer relations team, specifically from: Replace with the names of who gave advice
[ ] I wrote a migration guide: Replace with a link to your migration guide

@amirh done!


alignment/comparison with coreos/toolbox

Let's discuss overlap with https://github.com/coreos/toolbox/commit/598df78f6b09a9bb19b636bdc983e90f723ae256
here.
One broad concern I have here is the very name of the project; in Fedora we go to a lot of effort to have most of "Fedora" branding inside fedora-release, and there's a generic-release.
This one seems to assume a full desktop login and be run as non-root, where as for the coreos-toolbox we instead assume the user is running as root on a console, and should have full system wide privileges.
But really...the overlap in implementation and scope is big.
My 2c is that we call it "coreos-toolbox" as a project name, but just "toolbox" implicitly when discussing in a Fedora/CoreOS context.

A bit of background on the new coreos-toolbox: it was designed to be a very simple admin/debug container with full privileges, essentially a port from the old one (for CL) but for RHCOS/FCOS systems. In that sense the scope is much smaller.

One broad concern I have here is the very name of the project; in Fedora
we go to a lot of effort to have most of "Fedora" branding inside
fedora-release, and there's a generic-release.

(tl;dr: I am happy to switch to a downstream agnostic name.)
Well, this isn't about bits of trademarks, configuration, names and version numbers that define a specific Fedora release, though. It's more like fedora-packager, which has a bunch of fedora prefixed tools, and fedpkg.
Even though a toolbox container is a generic concept, the mix of upstream technologies (ie., Buildah, Podman), and downstream consumers (eg., Fedora Silverblue) make it uniquely "Fedora".  It probably already works on, say, Debian, but I haven't tested it, nor is it the primary reason for the tool to exist. At least it's not my priority today.
Hence, the fedora prefix.
That said, if a fedora prefix is considered problematic, then I am happy to go with a name that's completely detached from any downstream.

This one seems to assume a full desktop login and be run as non-root,
where as for the coreos-toolbox we instead assume the user is running
as root on a console, and should have full system wide privileges.

(tl;dr: I am aware of CoreOS' needs and happy to address those.)
Well, it wasn't really a secret that we are working on a toolbox for Silverblue and what our needs are. :)
We have discussed this in #fedora-coreos, #fedora-containers, on fedora-coreos-tracker, etc..
I am aware that Fedora CoreOS' needs are different from Silverblue's. My impression was that we are happy to share as much of the toolbox as we can for the two flavours. However, I haven't heard anything from the CoreOS team after the initial discussion, and I don't know what the current plans or priorities are. Just the other day, I dropped a couple of comments about the current status of fedora-toolbox, but I haven't heard any updates.
Meanwhile, in Silverblue land, the toolbox is pretty crucial. Otherwise we can't use Silverblue as a development environment, and I really want to use my shiny XPS 13 running Silverblue as much as I can. :) So we had to choose a name and move forward.

My 2c is that we call it "coreos-toolbox" as a project name, but just "toolbox"
implicitly when discussing in a Fedora/CoreOS context.

As I mentioned earlier, fedora-toolbox is loosely inspired from coreos/toolbox. Loosely, because the original coreos/toolbox required root and used a different technology stack.
One of the reasons I didn't fork and continue with the original repository, was because I wasn't sure what to do with the governance and process related bits in there. A code of conduct, contribution guidelines, etc. are important things to have, but I also wanted to make it clear that this is happening under the Fedora banner. Not knowing exactly how the Fedora banner looks like, I didn't want to just git rm those bits in a commit, and I badly needed a Git repository to point people at. I had been pointing people to a tarball that I manually kept updated for weeks. :)
Secondly, since the underlying tools were going to be completely different, it meant that the script would have to be rewritten. Hence I was not too worried about preserving the Git history.

I agree with all that Debarshi said here.
I don't think there's much value in 'genericizing' this. It is about giving access to ready-made fedora tools containers, so calling it fedora-toolbox seems obvious and natural.

fwiw, this is a bit of tangent, but i find the name "toolbox" weird. a toolbox is something you pull tools out of, not something you work inside.  I personally wish it was called workbox or something.

fwiw, this is a bit of tangent, but i find the name "toolbox" weird.

(Hm, so if we drop fedora and toolbox, the project could just be called - :wink: )

(tl;dr: I am aware of CoreOS' needs and happy to address those.)
Well, it wasn't really a secret that we are working on a toolbox for Silverblue and what our needs are. :)

Yep, I heard there was a discussion, sorry I am only now circling back to this after seeing the Silverblue PR.

Meanwhile, in Silverblue land, the toolbox is pretty crucial.

Agree, though I don't feel blocked myself right now having my own custom scripts for this, I do think we need to have an opinionated out of the box solution too.
Now, I find myself agreeing with this comment:
https://github.com/coreos/fedora-coreos-tracker/issues/38#issuecomment-417714930

It is about giving access to ready-made fedora tools containers, so calling it fedora-toolbox seems obvious and natural.

So, I work on Red Hat CoreOS and...I am not entirely sure that when we ship the tool should default to Fedora userspace.  There are a whole lot of implications to that - some good, some bad.
Now particularly when you're talking about the command line, Fedora is packages and particularly given the default to a Fedora userspace, calling it "fedora-toolbox" does make sense.  But that said I still have concerns over the branding.
The idea of solving two problems at once by merging the coreos-toolbox and fedora-toolbox and just calling it "toolbox" hence has a lot of appeal.

Sure, merging the two makes a lot of sense, which is why we reached out earlier to discuss that. If the name is a problem, how about something like "workshop", as the place where you keep your toolboxes and get work done ?

Meanwhile, in Silverblue land, the toolbox is pretty crucial.

Agree, though I don't feel blocked myself right now having my own custom
scripts for this, I do think we need to have an opinionated out of the box
solution too.

Well, you are one of those very special people who are well-versed in both containers and modern graphical OSes. Hapless mortals have been known to struggle with little things like leaking in the display server socket, and so on. :)

Now, I find myself agreeing with this comment:
coreos/fedora-coreos-tracker#38 (comment)

Yes, I like Dusty's idea too.
However, I don't know what troubleshooting exactly looks like in this case.
To be fair, my understanding of development is also skewed towards "should be possible to do jhbuild-style development", which is basically "install some tools from the distribution, build and install things into a separate prefix and run them". I'd really appreciate it if people with different workflows and development setups would try it out and give feedback.

So, I work on Red Hat CoreOS and...I am not entirely sure that when we ship
the tool should default to Fedora userspace. There are a whole lot of implications
to that - some good, some bad.

This seems a bit like fedpkg and rhpkg. Although, I haven't studied how those two assert their individual identities.
My assumption was that Fedora CoreOS/Silverblue and Red Hat CoreOS/Silverblue would share the usual relationship between Fedora and RHEL. Admittedly, Red Hat CoreOS is probably a very real thing while Red Hat Silverblue is probably just vapourware. :)

Now particularly when you're talking about the command line, Fedora is
packages and particularly given the default to a Fedora userspace, calling it
"fedora-toolbox" does make sense. But that said I still have concerns over the
branding.

Yes, I understand. My operating principal has been to mimic a familiar RPM-based environment with the toolbox. So, I'd expect a Fedora toolbox to have Fedora RPMs, and a RHEL toolbox to have RHEL RPMs. At least by default, because one can always fiddle with the flags and create a Fedora toolbox on RHEL and what not. Just like the toolbox defaults to the host's VERSION_ID.
It's just that I work on Silverblue, and while Fedora Silverblue is a real thing, I have never even heard of Red Hat Silverblue. Hence the bias towards all things Fedora comes from a desire to keep it simple and get the ball rolling. I certainly don't want to enforce Fedora content on RHEL users by default.

The idea of solving two problems at once by merging the coreos-toolbox and
fedora-toolbox and just calling it "toolbox" hence has a lot of appeal.

Yes, just toolbox (or workshop) sounds fine to me. Would we also rename the Git repository, RPM package, etc.? Or shall we just rename the script?
I am apprehensive of claiming a spot in the global namespace. Especially for the Git repository because toolbox is such a generic name.

so the scope of this program isn't just for people working on fedora, right?  it's primarily for people who happen to use fedora to get completely unrelated work done. fedpkg is for people packaging programs for fedora. it's for us, not for our users.  this program is for our users.

so the scope of this program isn't just for people working on
fedora, right? it's primarily for people who happen to use fedora
to get completely unrelated work done. fedpkg is for people
packaging programs for fedora. it's for us, not for our users.
this program is for our users.

Yes, that's right.
However, at least for the time being, we are not focused on making this work on every single distribution out there; and some bits of configuration (eg., the URL of the OCI image registry, the name of the default image, etc.) might change between Fedora and RHEL.

From the other issue (regarding coreos v. silverblue):

Yes, we did identify the differences during our chat in #fedora-coreos but my understanding was that we still wanted to share it as much as possible.

Yes, I agree. Apologies for mis-interpreting the initial discussions. Since the coreos use case was much smaller I opted to create a very simple toolbox to build into our existing pipeline. Moving forward I think consolidating the two would definitely make sense.

However, I don't know what troubleshooting exactly looks like in this case.

So I can only speak to what RHCOS originally envisioned to use the toolbox for: essentially run a debug tool inside a failing host. In that sense the toolbox command only had to run a privileged container that can mount the host fs and that's all.

So, I'd expect a Fedora toolbox to have Fedora RPMs, and a RHEL toolbox to have RHEL RPMs.

Alternatively, the fedora toolbox can just by default run a fedora image, and the rhel toolbox to default to a rhel image would probably work as well?

Yes, just toolbox (or workshop) sounds fine to me.

The main reasoning from a coreos perspective is that that was the chosen name for CL: https://github.com/coreos/toolbox I have no strong feelings either way regarding naming.
I'll try out @debarshiray's toolbox on coreos systems later this week and see if there's any compatibility issues. Again, apologies for the lack of follow up, and thanks for trying to consolidate!

Hi,

However, at least for the time being, we are not focused on making this work on every single distribution out there; and some bits of configuration (eg., the URL of the OCI image registry, the name of the default image, etc.) might change between Fedora and RHEL.

Okay, my take is that's not a strong enough reason to include fedora in the name.  I mean we don't call firefox fedora-firefox because it's default start page is start.fedoraproject.org.  Distros are expected to do per distribution customizations of software, I think.
I don't think it's a big issue if it doesn't work on other distros either.  I mean that's the responsibility of other distros, if they see the value.  of course, if it explicitly should be fedora only that's a different story.

I'll try out @debarshiray's toolbox on coreos systems later this week and see if there's any compatibility issues.

thanks @yuqi-zhang !

A couple of initial questions:

RHCOS systems do not have buildah by default. It may be nicer to have a split between the image creation and the container creation functionality-wise?
I'm not very familiar with descriptors, where does 2>&42 pipe the error to? On RHCOS systems this causes an error: 42: Bad file descriptor, or am I using this wrong?
The container fails to start with and error that claims it doesn't exist, even though I created it and can see it through podman. This is possibly because some of the flags are causing issues, I will investigate further.
Would it be a good idea to allow for dynamic mounts? Or just more/less custom environment vars in genera?

RHCOS systems do not have buildah by default. It may be nicer to
have a split between the image creation and the container creation
functionality-wise?

Yes, sure.
The customized image that's locally created with buildah is there to fill in the pieces that are specific to each user. eg., creating a user to match $USER on the host. If those things are not needed in CoreOS, or if they can be done differently, then the intermediate image isn't necessary.

I'm not very familiar with descriptors, where does 2>&42 pipe the
error to? On RHCOS systems this causes an error: 42: Bad file descriptor,
or am I using this wrong?

This comes from commit d7219ba512434315a3be0b4bcaa00b16cf7e478c
Usually file descriptor 42 points at /dev/null. When you pass the --verbose flag it points at stderr. I couldn't find a better way to implement --verbose. Ideas welcome.
I am curious why it doesn't work on CoreOS, though.

The container fails to start with and error that claims it doesn't exist, even
though I created it and can see it through podman. This is possibly because
some of the flags are causing issues, I will investigate further.

Interesting. Was it with local changes in your tree?
I just happened to try the toolbox with --sudo after a long time, and ran into various podman errors. The fedora-toolbox --sudo create worked, but then sudo podman ps --all and fedora-toolbox --sudo enter, etc. are erroring out:
[rishi@bollard ~]$ fedora-toolbox --sudo create
[rishi@bollard ~]$ sudo buildah images
IMAGE ID             IMAGE NAME                                               CREATED AT             SIZE
9ffedc39f7f2         registry.fedoraproject.org/f28/fedora-toolbox:28         Sep 26, 2018 18:07     602 MB
1b2c5602ac02         localhost/fedora-toolbox-rishi:28                        Nov 6, 2018 19:53      602 MB
[rishi@bollard ~]$ sudo podman ps --all
error decoding container status for container dd1c6b885b53c712c177ce14ed23a63572802fd374d8086d1ddc9200e5a725f9: EOF
[rishi@bollard ~]$ fedora-toolbox --sudo -v enter
unable to get container state: error decoding container status for container dd1c6b885b53c712c177ce14ed23a63572802fd374d8086d1ddc9200e5a725f9: EOF
/usr/bin/fedora-toolbox: failed to start container fedora-toolbox-rishi:28
[rishi@bollard ~]$

I have:
[rishi@bollard ~]$ rpm -q podman runc
podman-<IP_ADDRESS>-3.gitdb08685.fc28.x86_64
runc-1.0.0-57.dev.git9e5aa74.fc28.x86_64

Looks like a podman bug that needs to be reported.

Would it be a good idea to allow for dynamic mounts? Or
just more/less custom environment vars in general?

Umm... I guess it depends on the specific use-case?

So, where do we stand with the naming issue? I am fine with dropping the fedora prefix if you think that toolbox or workbox aren't terribly generic names to put in the global /usr/bin namespace.
Or have we chosen to swallow the fedora-toolbox moniker for the time being?

I have no strong feelings either way and defer to more experienced folks regarding naming, but I think it's looking like the generic "toolbox" name is in the majority?
Sorry for the delayed response, I am on a trip until next week. I'll look into the issues above when I'm back.

I have no strong feelings either way and defer to more experienced folks regarding naming, but I think it's looking like the generic "toolbox" name is in the majority?

toolbox works for me

i'm surprised you all think toolbox was the majority favorite. i thought consensus had clearly settled on @cgwalters idea of -

I started the renaming paperwork. With the 0.0.5 release just out and lingering in Fedora's updates-testing repository, this is as good a time as any.
This Git repository itself has now been renamed to toolbox.
Next I will rename the various bits and pieces inside the repository - sources, build system, etc.. Then it's matter of rolling a new tarball and going through the Fedora packaging process.

The contents of this Git repository have been renamed in #52.
All that remains is rolling out a new tarball and the downstream packaging. I'd like to wait a bit so that the 0.0.5 release gets a chance to hit the stable updates repositories before rolling the next release.
Closing.


Adding basic Failsafe support

This PR intended to add Failsafe support to Spring Cloud Circuitbreaker. This closes #30

[x] Creating failsafe module
[x] Configurable RetryPolicy and CircuitBreaker
[x] Add support for customizers

The Failsafe support is basic (similar to one based spring-retry template). Next step should include support for reactive extensions (with Async callbacks in Failsafe)

Please add some documentation

Catched up with documentation.


compat: module resolution, 'deno' conditional exports

CC @guybedford

Before landing I want to add information about usage of package managers and add example of running eslint with compat mode.


StableDiffusion

Sync with Ean

[ ] lowerings in the spirit of stateless llama

[ ] Unet
[ ] VAE
[ ] CLIP

[ ] support for arbitrary model formats -- HF ID, civitai checkpoints, torch.nn.modules, .mlir input
[ ] support for loading LoRAs
[ ] support for ControlNet
[ ] support fake weights / loading .ckpt at runtime
[ ] support for LoRA training

@aviator19941 there are a few more missing pieces, mostly small preprocessors/schedulers that I'd like to have turbine implementations ready for. Please take a look at the following list of tasks and let me know if you have any questions.

[ ] Support for dynamic SD schedulers -- refer to SHARK sd_schedulers.py -- currently we import all of these upon loading a model config so they are easily switchable at runtime, but most of them run on CPU (base pytorch) -- only SharkEulerDiscrete and SharkEulerAncestralDiscrete are available as .mlir/vmfb at the moment but we should support all of them as compiled modules.
[ ] Support for controlnet adapters -- see controlled UNet and StencilControlNetModel (do me a favor and don't use the term 'stencil' for this part, as it's misleading. these are just controlnet adapters)
[ ] Support for controlnet preprocessors -- see canny, openpose, zoedepth. These just take an input image and convert it to some mask/mapping. They are fed into the unet latents through the stencil adaptors.
[ ] LoRA support
[ ] Lycoris support

I can take Controlnet and the preprocessors @monorimet @aviator19941

sounds good @gpetters94

@aviator19941 can we implement VAE encode for img2img? we can split into two files or just have a separate API e.g. export_vae_encode_model and export_vae_decode_model or just use a keyword export_vae_model(hf_model_id, variant="encode", ... )

@stellaraccident @dan-garvey VAE encode when calling sample() is not able to return the self.wrapped_f function correctly. I am not sure how to go about fixing this error. I have a small example that reproduces the same error, but when I provide concrete integers in place of inp.shape in the forward function, i.e. torch.randn(1, 4, 64, 64, ...) it is able to compile to torch. Do you have any suggestions on how to fix this?
The Traceback is below:
Traceback (most recent call last):
  File "/home/avinash/nod/SHARK-Turbine/python/turbine_models/custom_models/sd_inference/vae_encode.py", line 37, in <module>
    exported = aot.export(sample_model, example_x)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/exporter.py", line 199, in export
    cm = Exported(context=context, import_to="import")
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/compiled_module.py", line 538, in __new__
    do_export(proc_def)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/compiled_module.py", line 535, in do_export
    trace.trace_py_func(invoke_with_self)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/support/procedural/tracer.py", line 121, in trace_py_func
    return_py_value = _unproxy(py_f(*self.proxy_posargs, **self.proxy_kwargs))
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/compiled_module.py", line 516, in invoke_with_self
    return proc_def.callable(self, *args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/exporter.py", line 183, in main
    return jittable(mdl.forward)(*args)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/support/procedural/base.py", line 137, in __call__
    return current_ir_trace().handle_call(self, args, kwargs)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/support/procedural/tracer.py", line 137, in handle_call
    return target.resolve_call(self, *args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/builtins/jittable.py", line 207, in resolve_call
    transformed_f = functorch_functionalize(transformed_f, *flat_pytorch_args)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/passes/functorch.py", line 47, in functorch_functionalize
    new_gm = proxy_tensor.make_fx(
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/experimental/proxy_tensor.py", line 809, in wrapped
    t = dispatch_trace(wrap_key(func, args, fx_tracer, pre_dispatch), tracer=fx_tracer, concrete_args=tuple(phs))
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_compile.py", line 24, in inner
    return torch._dynamo.disable(fn, recursive)(*args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_dynamo/eval_frame.py", line 328, in _fn
    return fn(*args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_dynamo/external_utils.py", line 17, in inner
    return fn(*args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/experimental/proxy_tensor.py", line 468, in dispatch_trace
    graph = tracer.trace(root, concrete_args)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/_symbolic_trace.py", line 817, in trace
    (self.create_arg(fn(*args)),),
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/experimental/proxy_tensor.py", line 485, in wrapped
    out = f(*tensors)
  File "<string>", line 1, in <lambda>
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/passes/functorch.py", line 65, in wrapped
    out = function(*args_functional)
  File "/home/avinash/nod/SHARK-Turbine/python/shark_turbine/aot/builtins/jittable.py", line 202, in flat_wrapped_f
    return self.wrapped_f(*pytorch_args, **pytorch_kwargs)
  File "/home/avinash/nod/SHARK-Turbine/python/turbine_models/custom_models/sd_inference/vae_encode.py", line 30, in forward
    sample = torch.randn(inp.shape, generator=generator, device="cpu")
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/utils/_stats.py", line 20, in wrapper
    return fn(*args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/experimental/proxy_tensor.py", line 555, in __torch_dispatch__
    return self.inner_torch_dispatch(func, types, args, kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/experimental/proxy_tensor.py", line 580, in inner_torch_dispatch
    return proxy_call(self, func, self.pre_dispatch, args, kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/fx/experimental/proxy_tensor.py", line 361, in proxy_call
    out = func(*args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_ops.py", line 448, in __call__
    return self._op(*args, **kwargs or {})
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/utils/_stats.py", line 20, in wrapper
    return fn(*args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_subclasses/fake_tensor.py", line 1250, in __torch_dispatch__
    return self.dispatch(func, types, args, kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_subclasses/fake_tensor.py", line 1487, in dispatch
    op_impl_out = op_impl(self, func, *args, **kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_subclasses/fake_tensor.py", line 422, in constructors
    r = func(*args, **new_kwargs)
  File "/home/avinash/nod/SHARK-Turbine/turbine/lib/python3.10/site-packages/torch/_ops.py", line 448, in __call__
    return self._op(*args, **kwargs or {})
RuntimeError: aten/src/ATen/RegisterCompositeExplicitAutograd.cpp:3404: SymIntArrayRef expected to contain only concrete integers

import torch
import torch._dynamo as dynamo
from torch._export import dynamic_dim
from torch._export.constraints import constrain_as_size, constrain_as_value
from typing import Optional
from shark_turbine.aot import *
from iree.compiler.ir import Context

class SampleModel(CompiledModule):

    def run_forward(self, inp=AbstractTensor(1,4,64,64, dtype=torch.float32)):
        sample = self.forward(inp)
        return sample

    @jittable
    def forward(inp) -> torch.FloatTensor:
        sample = torch.randn(inp.shape, device="cpu")
        # make sure sample is on the same device as the parameters and has same dtype
        sample = sample.to(device="cpu", dtype=torch.float32)
        return sample

sample_model = SampleModel(context=Context(), import_to="IMPORT")
print(str(CompiledModule.get_mlir_module(sample_model)))

seems to fix your issue. Can you model the full thing this way?

import shark_turbine.aot as aot
import torch
import torch._dynamo as dynamo
from torch._export import dynamic_dim
from torch._export.constraints import constrain_as_size, constrain_as_value
from typing import Optional
from diffusers import AutoencoderKL
from shark_turbine.aot import *
from iree.compiler.ir import Context

hf_model_name = "CompVis/stable-diffusion-v1-4"
hf_auth_token = "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"

vae = AutoencoderKL.from_pretrained(
    hf_model_name,
    subfolder="vae",
    token=hf_auth_token,
)
class VaeModel(CompiledModule):

    def run_forward(self, inp=AbstractTensor(1, 3, 512, 512, dtype=torch.float32)):
        x = self.forward(inp)
        return x

    @jittable
    def forward(inp) -> torch.FloatTensor:
        latents = vae.encode(inp).latent_dist.sample()
        return 0.18215 * latents

vae_model = VaeModel(context=Context(), import_to="IMPORT")
print(str(CompiledModule.get_mlir_module(vae_model)))

I think the issue might be when the jittable calls another function that needs to use the input shape directly. Seems like this example also fails the SymIntArrayRef check.


no table route info; nested exception is java.lang.IllegalStateException: no table route info

I obviously added TableRuleConfiguration, but I still get an error.

The error message is not enough, can you provide more information, follow template below is a good idea:
Bug Report
For English only, other languages will not accept.
Before report a bug, make sure you have:

Searched open and closed GitHub issues.
Read documentation: ShardingSphere Doc.

Please pay attention on issues you submitted, because we maybe need more details.
If no response more than 7 days and we cannot reproduce it on current information, we will close it.
Please answer these questions before submitting your issue. Thanks!
Which version of ShardingSphere did you use?
Which project did you use? Sharding-JDBC or Sharding-Proxy?
Expected behavior
Actual behavior
Reason analyze (If you can)
Steps to reproduce the behavior, such as: SQL to execute, sharding rule configuration, when exception occur etc.
Example codes for reproduce this issue (such as a github link).

Sharding-JDBC：4.0.0-RC1
2.0.3 version works fine, when I adapt to 4.0.0-RC1 error

My profile is as follows

what is your SQL?

Hibernate:
select
storage0_.id as id1_0_,
storage0_.created_by as created_2_0_,
storage0_.created_date as created_3_0_,
storage0_.deleted_by as deleted_4_0_,
storage0_.deleted_date as deleted_5_0_,
storage0_.deleted_flag as deleted_6_0_,
storage0_.last_modified_by as last_mod7_0_,
storage0_.last_modified_date as last_mod8_0_,
storage0_.db_id as db_id9_0_,
storage0_.address as address10_0_,
storage0_.backgroundpicpath as backgro11_0_,
storage0_.description as descrip12_0_,
storage0_.detector_no as detecto13_0_,
storage0_.device_no as device_14_0_,
storage0_.en_name as en_name15_0_,
storage0_.height as height16_0_,
storage0_.ispublic as ispubli17_0_,
storage0_.name as name18_0_,
storage0_.owner as owner19_0_,
storage0_.picpath as picpath20_0_,
storage0_.tel as tel21_0_,
storage0_.width as width22_0_
from
sample_storage storage0_
where
storage0_.db_id=1
and storage0_.deleted_flag=1
order by
storage0_.id desc limit ?

The configuration you provided is not ShardingSphere's configuration, what's it?
Can you provide ShardingSphere's configuration?

I just wrap it into the springboot2.X configuration file

When there are more than 100 data sources, the configuration file of ShardingSphere is very troublesome to configure, so it is packaged based on the springboot configuration file mechanism.

I suggest one issue just focus one problem.
I just want to know, can you provide ShardingSphere's configuration?  I don't know what is your sharding strategy.

It seems like you do some additional development for ShardingSphere, can you try to original ShardingSphere first?

I will close this issue soon if no response any more


Pkg 4785 <IP_ADDRESS> initial

Destination channel: defaults
Links

PKG-4785

Explanation of changes:

Part of CUDA 12.4 build, following conda-forge's pattern which was developed in conjunction with Nvidia. I don't see a need to stage these then release them all at once. They won't cause a problem released one at a time.
Please check the main branch too, this has just been forked
Changes made to adjust feedstock for differences between conda-forge and defaults. Please see commit messages for description of changes.

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_c69zyrgev7/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:95: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:96: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:55: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:96: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:23: invalid_url: https://developer.download.nvidia.com/compute/cutensor/redist/libcutensor/linux/libcutensor-linux-<IP_ADDRESS>-archive.tar.xz : Not reachable: 404
clone/recipe/meta.yaml:95: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:23: missing_hash: The recipe is missing a sha256 checksum for a source file
===== Final Report: =====
4 Errors and 3 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_59q4ofy8jf/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:98: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:99: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:58: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:98: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:99: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 3 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_157lkkdlhy/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:98: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:99: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:58: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:98: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:99: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 3 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(124): `conda run conda-lint /tmp/abs_515yhjo5c1/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:98: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:58: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:99: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:98: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:99: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 3 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_d8x71d96j8/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:58: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.
clone/recipe/meta.yaml:99: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:98: license_file_overspecified: Using license_file and license_url is overspecified.

===== ERRORS =====

clone/recipe/meta.yaml:99: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:98: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 3 Warnings were found

Linter check found the following problems:
ERROR conda.cli.main_run:execute(125): `conda run conda-lint /tmp/abs_66xyybh22j/clone` failed. (See above for error)
The following problems have been found:
===== WARNINGS =====

clone/recipe/meta.yaml:99: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:98: license_file_overspecified: Using license_file and license_url is overspecified.
clone/recipe/meta.yaml:58: host_section_needs_exact_pinnings: Linked libraries host should have exact version pinnings.

===== ERRORS =====

clone/recipe/meta.yaml:99: missing_license_family: The recipe is missing the about/license_family key.
clone/recipe/meta.yaml:98: missing_license_family: The recipe is missing the about/license_family key.
===== Final Report: =====
2 Errors and 3 Warnings were found


Add params on list repo commits

I added since and until parameters on List repository commits, and updated URL on doc comment.

Thanks @griffin-stewie! LGTM!


pipenv install still doing full lock resolution

In pipenv 2024.0.0 we made changes to install path, and my assumption was it would behave more like the upgrade path, but I saw first hand today its re-locking everything.

Analysis for Issue #6267:
Analysis of Pipenv Issue #6267
1. Problem Summary:
The user reports that despite changes to the install path in Pipenv 2024.0.0, pipenv install still triggers a full lock resolution instead of behaving like the upgrade path, which should ideally resolve only the newly added package and its dependencies.
2. Comment Discussion Analysis:
The issue currently has no comments, so there's no further context or discussion to analyze.
3. Proposed Resolution:
The issue highlights a discrepancy in how Pipenv handles dependency resolution for install vs. upgrade. While the exact changes in 2024.0.0 aren't specified, the goal is to make pipenv install more efficient by resolving only the necessary dependencies when adding a new package.
3.1 Identify the Affected Code:
The primary area to investigate is the do_install function within pipenv/routines/install.py. This function controls the core logic of the pipenv install command. It likely needs modifications to distinguish between installing a single package and installing all packages from the Pipfile.
3.2 Proposed Code Changes:

Differentiate between single package and full installation: Inside do_install, check if specific packages are provided as arguments.
Conditional Resolution: If specific packages are provided:

Add them to the Pipfile.
Create a temporary constraint file containing only the new packages and their dependencies, similar to the upgrade path.
Invoke the resolver with this constraint file, limiting the scope of resolution.

Full Resolution: If no specific packages are provided, proceed with the existing full lock resolution logic.

4. Code Snippet:
def do_install(
    project,
    # ... existing parameters
    packages=None,
    editable_packages=None,
    # ...
):
    # ... existing code

    # Check if specific packages are provided
    if packages or editable_packages:
        # ... (Add packages to Pipfile)

        # Create a temporary constraint file with only the new packages
        temp_constraints = create_constraint_file(
            packages, editable_packages, requirements_dir
        )

        # Invoke the resolver with the limited constraint file
        resolve_deps(
            deps=temp_constraints,
            which=project._which,
            project=project,
            # ... other parameters
        )
    else:
        # Perform full lock resolution as before
        # ... (Existing code)

5. Additional Steps/Investigations:

Thorough Testing: Create comprehensive test cases covering single package installations, full installations, and edge cases to ensure the intended behavior.
Performance Benchmarking: Compare the performance of the modified install path to the previous full resolution approach, particularly for projects with a large number of dependencies.
Documentation: Update the Pipenv documentation to clearly explain the new behavior of pipenv install when specific packages are provided.

Note: This proposal focuses on improving efficiency by limiting the scope of dependency resolution. It's important to maintain the accuracy of the lockfile and ensure all necessary dependencies are resolved, even when installing a single package.
==================================================

fyi -- Testing out some Gen AI code analysis of recent issues


File not running

it cut off so heres the full error ModuleNotFoundError: No module named 'scipy._lib.array_api_compat.numpy.fft'

I ran into a similar problem when I created an executable from my Python project.
TL;DR: Add scipy._lib.array_api_compat.numpy.fft and scipy.special._special_ufuncs to your "hidden imports" in your .spec file.
I will try to give some details:
It seems my error message was due to the imports below:
from statsmodels.tsa.holtwinters import ExponentialSmoothing
from statsmodels.tsa.exponential_smoothing.ets import ETSModel

I could run my main.py script without trouble inside VS Code (using Python 3.12.3), but not as an executable.
When I ran the executable I got an error like yours that complained 'scipy._lib.array_api_compat.numpy.fft' could not be found.
I created the executable by first installing "Pyinstaller" (with pip install pyinstaller) and then I ran the command below (in Powershell on Windows 11):
python -m PyInstaller --onedir main.py
Change "main.py" to whatever is the entry point in your project.
From this command I got the executable that didn't work.
Then I googled and found this stackoverflow thread: https://stackoverflow.com/questions/78234168/modulenotfounderror-no-module-named-scipy-linalg-basic
So I tried to add --hidden-import to the pyinstaller command, followed by the name of the module that could not be found, like this:
python -m PyInstaller --onedir --hidden-import scipy._lib.array_api_compat.numpy.fft main.py
Then I got a new error, still a ModuleNotFoundError but this time for the module "scipy.special._special_ufuncs". I added this module name to the hidden imports too, and then the resulting executable could run without problem.
In the end I switched to running the command pyinstaller your_spec_file.spec in order to build the .exe, and before running the command I also specified the hidden imports in my main.spec file (which was generated from running either of the pyinstaller commands above). They can be specified as follows:
# beginning of main.spec
# -*- mode: python ; coding: utf-8 -*-

a = Analysis(
    ['main.py'],
    pathex=[],
    binaries=[],
    datas=[],
    hiddenimports=['scipy._lib.array_api_compat.numpy.fft','scipy.special._special_ufuncs'],
    hookspath=[],
    hooksconfig={},
# remainder of main.spec ...

I'm running into the same issue. I can run my python scripts fine, but I get this error when trying to build an executable via pyinstaller

I'm running into the same issue. It only occurs when I try to import circle_fit library, otherwise this error doesn't occur for me. I can run my python scripts fine, but I get this error when trying to build an executable via pyinstaller

you can try using the hidden imports like python -m PyInstaller --onedir --hidden-import scipy._lib.array_api_compat.numpy.fft main.py but replace main.py and scipy._lib.array_api_compat.numpy.fft with yout own imports

I'm running into the same issue. It only occurs when I try to import circle_fit library, otherwise this error doesn't occur for me. I can run my python scripts fine, but I get this error when trying to build an executable via pyinstaller

you can try using the hidden imports like python -m PyInstaller --onedir --hidden-import scipy._lib.array_api_compat.numpy.fft main.py but replace main.py and scipy._lib.array_api_compat.numpy.fft with yout own imports

A mix of hidden imports and submodules seemed to work for me. My executable works now when I build it with this command:
pyinstaller .\app.py --collect-submodules=numpy.f2py --hiddenimport=scipy._lib.array_api_compat.numpy.fft --hiddenimport=scipy.special._special_ufuncs

Hey, just use the ModdedPysilon version, it covers every bug and it make sure your discord account never get banned.
Leave me a star if you like my project ;)


Roi component

This is a suggestion for a change in ROI and I want to emphasize as a suggestion this can also be rejected, I can also see reasons for that. This is mostly personal preference and a sense of what is better that I can't really explain, there is however one positive point, the new ROI is independent of Vradar and therefore can be used (in the future) with grid.
The new ROI may be found in the components menu in the menubar. But this is open to discussion.
Take your time with this, this is NOT a priority and I pretend to focus more in the documentation

I like the idea behind this and was thinking of something similar in terms of relocating the ROI function as a component. I'll need to look through and see how this is set up.
By the way, is there documentation of how to call a component? I think this will be important to let users know how to use the plugins effectively.

I'm working in a tutorial for writing scripts right now, this may help, but keep this idea we will need it

Good deal, thanks!
I've been doing some mental coding (trying to get a structure in my head) with some of these issues. I am trying to decide what would be really nice to have done by Sep AMS radar conference. We'll be presenting ARTView as an option in the open source software short course. So any tutorials you think might be useful please let me know.
Hopefully I can get back to this soon. I have a couple other things I need to finish up.

You can keep up with what I'm doing here. The reference manual is a lot more complete, the tutorial is a work in progress. Just let me say I'm famous for some terrible spelling errors, there is probably a lot there.
If you have clear ideas about what you need, let me know.

Okay, so this all seems to work just fine.
I guess I don't really know how the components work. I see that ROI is now a component as well as tool (let's keep it that way for now). But selecting it does not "run" anything.
Could you note the procedure here or elsewhere (maybe you've done this already and I don't recall)?

Ok, that is missing a warning, you must select a display before starting it. You probably just clicked start right way and that resulted in an error in the terminal


Update default TTL action in Alluxio

Ⅰ. Describe what this PR does
change alluxio.user.file.create.ttl.action to FREE rather than default DELETE
Ⅱ. Does this pull request fix one issue?
Fixes https://github.com/fluid-cloudnative/fluid/issues/234
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #251 into master will increase coverage by 0.03%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master     #251      +/-   ##
==========================================
+ Coverage   17.96%   18.00%   +0.03%
==========================================
  Files          50       50
  Lines        2171     2172       +1
==========================================
+ Hits          390      391       +1
  Misses       1740     1740
  Partials       41       41

Impacted Files
Coverage Δ

pkg/ddc/alluxio/transform_optimization.go
96.70% <100.00%> (+0.03%)
:arrow_up:

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 1e3e2a6...90463eb. Read the comment docs.

Thanks， @apc999


[Flow layouts] Migration Guide is not accurate

Description
I'm trying to migrate appcompanist FlowRow to foundationlayout FlowRow. in the migration guide it says that instead of mainAxisSpacing and crossAxisSpacing we must use
horizontalArrangement = HorizontalArrangement.spacedBy(50.dp, Alignment.Start)
and
verticalArrangement = VerticalArrangement.spacedBy(50.dp, Alignment.Top) like this:
FlowRow(
    modifier = Modifier,
    horizontalArrangement = HorizontalArrangement.spacedBy(50.dp, Alignment.Start),
    verticalArrangement = VerticalArrangement.spacedBy(50.dp, Alignment.Top),
    content = content
)

For horizontalArrangement parameter there isn't any provider named HorizontalArrangement so I replaced it with Arrangement.spacedBy(50.dp, Alignment.Start) and it fixed the issue but there isn't any parameter named verticalArrangement in FlowRow. FlowRow has verticalAlignment and for that parameter there isn't any provider like Alignment.spacedBy(50.dp, Alignment.Top).
So have can I have crossAxisSpacing in new FlowRow?

Thanks for filing that issue, sorry about that error in the migration guide. I will fix that up.
Cross axis spacing was added in Compose 1.5 which is currently in beta. The verticalArrangement should be there and let you achieve what you are trying to do.
Your fix of using Arrangement not HorizontalArrangement is correct and will work with vertical as well in 1.5.

I am migrating from accompanist-flowlayout:0.28.0 to fundation:1.5.4, the migration guide from Accompanist website states that

For FlowRow
mainAxisAlignment is now horizontalArrangement
crossAxisAlignment is now verticalArrangement

The crossAxisAlignment in Accompanist FlowRow behaves like the one in Row. However fundation FlowRow only provides verticalArrangement but no verticalAlignment. According to Flow layouts docs, we need to use Modifier.align() on row items.
Thus the following code
FlowRow(crossAxisAlignment = FlowCrossAxisAlignment.Center) {
    Item()
    Item()
}

should be migrated to
FlowRow {
    Item(modifier = Modifier.align(Alignment.CenterVertically))
    Item(modifier = Modifier.align(Alignment.CenterVertically))
}


[Error] StructureTooBigException error when exporting

Hello,
I am trying to export a large area of a world (663Wx605Lx173H) and each time I try to save the export it gives the following error:
Error during <function exportSelection at 0x000000000A57C668>: StructureTooBigException()
This is obviously stopping me from creating the schematic that I need so could you help me to solve the issue so that I can create this schematic please?
Thanks in advance....

I am also getting the same error when trying to export a different structure that is a size I have exported many times before (166Wx200Lx105H):
0x000000000A404668

I'll look into this. Could you send us a screenshot of the console window? It could give us some more I for that could help us

Hi,
I am not able to do so as I have reverted to using version <IP_ADDRESS> and the errors do not occur in this version. I am able to create both of the schematics.
regards

I'm getting the same error. Here's my console dump:
Running in fixed mode. Support files are in your Documents folder.
Splash load...
[ ****** ] ~~~~~~~~~~ Starting MCEdit-Unified v<IP_ADDRESS>
[ WARNING][            mcplatform.py:1276]:Initializing window management...
Minecraft_Server.jar storage initialized.
Each server is stored in a subdirectory of C:\Users\dagbel\Documents\MCEdit\Serv
erJarStorage named with the server's version number
Cached servers:  [u'Release 1.8.3']
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/ebf374c287
d34de593ca55a3ad8c8bcc"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/76c47dc440
424411909cadf2681850f4"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/0f22d2ca32
b84eb4a4192b1cf493f210"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/bc32789416
664c1fbf6e411bbfed3adb"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/cc29829691
0445829dd6e21cc33a7a7e"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/c80c2fe25b
1d43909d6dc69de5b49612"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/6b9ade8514
ea4ec4b31091b760c6c3c3"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/3af15f5865
494c698b077e57eeae818c"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/1a2e965792
6141c2a8d6603d24c7ccf4"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/980c13d889
96459ea5ad865d1b761cb9"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/5d2b0d23ea
9344f0b3c6b2bdf5fee608"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/05e88dce71
4d4218be77fade8b5dfa3c"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/69b92341b9
2b465496e22e615ae97f0d"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/9f94b55930
fe417fa1875dfa336fcc71"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/3ca077aa67
fd3d32b5300253ac456d7f"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
Exception in thread Thread-2:
Traceback (most recent call last):
File "threading.py", line 801, in __bootstrap_inner
File "threading.py", line 754, in run
File "mcedit.py", line 708, in fetch_version
File "release.py", line 54, in fetch_new_version_info
File "urllib2.py", line 154, in urlopen
File "urllib2.py", line 431, in open
File "urllib2.py", line 449, in _open
File "urllib2.py", line 409, in _call_chain
File "urllib2.py", line 1240, in https_open
File "urllib2.py", line 1197, in do_open
URLError: <urlopen error [Errno 11004] getaddrinfo failed>
An error occurred checking for updates.
[ WARNING][          version_utils.py:369]:Encountered an URLError while trying
to access "https://sessionserver.mojang.com/session/minecraft/profile/cc29829691
0445829dd6e21cc33a7a7e"
[ WARNING][          version_utils.py:370]:Error: [Errno 11004] getaddrinfo fail
ed
Couldn't find Image file (player-skins\cc298296_9104_4582_9dd6_e21cc33a7a7e.png)
or the file may be corrupted
Clipping:  _Vector(x=13, y=45, z=13)
C:\Users\dagbel\DOWNLO~1\Games\MINECR~1\SUPPLE~1\MCEDIT~1\154~1.1\mcedit\rendere
r.py:1115: VisibleDeprecationWarning: boolean index did not match indexed array
along dimension 0; dimension is 16 but corresponding boolean dimension is 13
Clipping:  _Vector(x=13, y=45, z=13)
Error getting file name:  (0, 'GetSaveFileNameW', 'No error message is available
')
Clipping:  _Vector(x=13, y=45, z=13)
[   ERROR][                    root.py:62]:Exception:
Traceback (most recent call last):
File "mceutils.py", line 56, in _alertException
File "editortools\select.py", line 1228, in exportSelection
File "leveleditor.py", line 842, in exportSchematic
File "pymclevel\schematic.py", line 809, in fromSchematic
structure = cls(size=(schematic.Width, schematic.Height, schematic.Length),
mats=namedMaterials[schematic.Materials])
File "pymclevel\schematic.py", line 776, in init
self._check_bounds(self._size)
File "pymclevel\schematic.py", line 729, in _check_bounds
raise self.StructureTooBigException()
StructureTooBigException
Clipping:  _Vector(x=13, y=45, z=13)
[   ERROR][                    root.py:62]:Exception:
Traceback (most recent call last):
File "mceutils.py", line 56, in _alertException
File "editortools\select.py", line 1228, in exportSelection
File "leveleditor.py", line 842, in exportSchematic
File "pymclevel\schematic.py", line 809, in fromSchematic
structure = cls(size=(schematic.Width, schematic.Height, schematic.Length),
mats=namedMaterials[schematic.Materials])
File "pymclevel\schematic.py", line 776, in init
self._check_bounds(self._size)
File "pymclevel\schematic.py", line 729, in _check_bounds
raise self.StructureTooBigException()
StructureTooBigException
Clipping:  _Vector(x=13, y=45, z=13)
[   ERROR][                    root.py:62]:Exception:
Traceback (most recent call last):
File "mceutils.py", line 56, in _alertException
File "editortools\select.py", line 1228, in exportSelection
File "leveleditor.py", line 842, in exportSchematic
File "pymclevel\schematic.py", line 809, in fromSchematic
structure = cls(size=(schematic.Width, schematic.Height, schematic.Length),
mats=namedMaterials[schematic.Materials])
File "pymclevel\schematic.py", line 776, in init
self._check_bounds(self._size)
File "pymclevel\schematic.py", line 729, in _check_bounds
raise self.StructureTooBigException()
StructureTooBigException
Clipping:  _Vector(x=13, y=45, z=13)
[   ERROR][                    root.py:62]:Exception:
Traceback (most recent call last):
File "mceutils.py", line 56, in _alertException
File "editortools\select.py", line 1228, in exportSelection
File "leveleditor.py", line 842, in exportSchematic
File "pymclevel\schematic.py", line 809, in fromSchematic
structure = cls(size=(schematic.Width, schematic.Height, schematic.Length),
mats=namedMaterials[schematic.Materials])
File "pymclevel\schematic.py", line 776, in init
self._check_bounds(self._size)
File "pymclevel\schematic.py", line 729, in _check_bounds
raise self.StructureTooBigException()
StructureTooBigException
Clipping:  _Vector(x=13, y=45, z=13)
[   ERROR][                    root.py:62]:Exception:
Traceback (most recent call last):
File "mceutils.py", line 56, in _alertException
File "editortools\select.py", line 1228, in exportSelection
File "leveleditor.py", line 842, in exportSchematic
File "pymclevel\schematic.py", line 809, in fromSchematic
structure = cls(size=(schematic.Width, schematic.Height, schematic.Length),
mats=namedMaterials[schematic.Materials])
File "pymclevel\schematic.py", line 776, in init
self._check_bounds(self._size)
File "pymclevel\schematic.py", line 729, in _check_bounds
raise self.StructureTooBigException()
StructureTooBigException

Fixed by fc47bec

Sorry to comment here, but could you please do a new official release post this fix...? The last release is from sep 3.

I agree the last release is a bit old, but I can't figure how the issue you're experiencing is related to the structure size...
What are you trying to 'build' ?

So, I'm trying to copy large structures inside MCEDIT.
I'm trying to build the python repo from the last commit.
Build here refers to python, not building inside MCEDIT :)

If you want to use the last commit, you shall run from source.
The process to set up Python and install the dependencies can be found in the README.md file.
Note that PyOpenGL minimum version shall be 3.1.0.
The source code for the binary files _nbt.pyd and leveldb_mcpe.pyd has not changed since last release, so, you van reuse the ones in you current MCEdit-Unified installation.

Yeah, I tried running from source but failed. It wasn't as easy as I
thought, and then I even have years of (non-python) coding experience. I'm
sure there is a significant user base with no coding experience at all that
would love to see a new binary released.
On Sat, Dec 10, 2016 at 1:32 AM, LaChal<EMAIL_ADDRESS>wrote:

If you want to use the last commit, you shall run from source.
The process to set up Python and install the dependencies can be found in
the README.md file.
Note that PyOpenGL minimum version shall be 3.1.0.
The source code for the binary files _nbt.pyd and leveldb_mcpe.pyd has
not changed since last release, so, you van reuse the ones in you current
MCEdit-Unified installation.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Khroki/MCEdit-Unified/issues/722#issuecomment-266192324,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALpWUW5nYop9BiYIJiQ22SY9EEwn46IRks5rGnG0gaJpZM4J49Oc
.


[Feature Request] display the "group" on manga page

The manga page currently has columns for chapter number, language, title, download status and read status
This is sufficient if there's only one group working on a manga, but it's likely to see different groups working on the same series. And not necessarily in succession, so sometimes the same chapter gets uploaded by two or even more groups and if they don't differ in title or don't even have titles at all you cannot tell them apart - currently looks like this:

Right now, I have to download both chapters to identify which one I want/need.
On the other hand, columns for download status and read status can be narrowed if you have to.
Not sure if it's necessary to also add the group to the target folder name for downloading. I leave that up to your decision.

ok this one is non-trivial so expect not to see much updates on this so far (im also busy with uni atm)

Feared so - guess this would have been implemented already, if it was a three lines of code no-brainer.
But I'm glad you consider my suggestion instead of flat-out rejecting it.
Good look on your studies.

it's doable so i wont close it. i just need the time to implement it haha.
i could just slap some code to get it to work for now tho, and then find a better solution later on.

Good to know. I'll leave that to your discretion and see what happens.

well... u know the drill, download latest release blah blah
enjoy!


Remove unnecessary call to 'file -l'

x-ref: https://github.com/julian-r/file-windows/blob/c10e2ccfee9fa3731e3880f274a741d0c19cfea2/CMakeLists.txt#L123-L127


Revert "docs(Contributing.md): Add Contributing.md"

Reverts pesto-students/babitz-backend#3

I have removed the merge commits from main and force pushed the same.


Add Clubs API

Right now, all the info about every club is fetched for prototyping purposes.
WARNING: the code may not work because there had been an undocumented schema change which will most likely require change in structs.
In particular, the way the code steps through the groups (by iterating through discord) may have to be changed later on.

Migration to sqlc has been completed. The Club API now seems to be compliant with the other APIs offered by the backend.
Note: Further testing may be needed


community: Add InMemoryVectorStore

This is a basic VectorStore implementation using an in-memory dict to store the documents.
It doesn't need any extra/optional dependency as it uses numpy which is already a dependency of langchain.
This is useful for quick testing, demos, examples.
Also it allows to write vendor-neutral tutorials, guides, etc...

@cbornet would you mind moving this to: https://github.com/langchain-ai/langchain/blob/f8078e41e5e599d022101a886f439db060806d53/libs/core/langchain_core/vectorstores.py#L12-L12

All in memory implementations are pretty fundamental -- useful as both reference implementations and for testing purposes
cc @baskaryan

Standby! We're trying to figure whether it's langchain-core or langchain

Also whereas the core currently depends on numpy, I’m not sure it’s really used and maybe it could be removed.

But a no-numpy, zero-dep, less performant implementation could also probably be written.

OK we can merge as is for now. We're working on breaking langchain dependency on langchain community. Once that's broken, we're likely going to invert it with langchain containing reference implementations / general algorithms, but this will be after 0.2.0 release.


Provide method to define sorting order

Once https://github.com/glossarist/glossarist-ruby/issues/86 is implemented.

@ronaldtse sort_by filter is already implemented. Here is an example -> https://github.com/metanorma/metanorma-plugin-glossarist/blob/main/spec/metanorma/plugin/glossarist/dataset_preprocessor_spec.rb#L84
Is there anything else that we need to add to this?

@HassanAkbar can you update documentation so users can know how to use it?

Thanks!


Question: Long Running Hooks - Yes or No?

Hi I have a question regarding the usage of hooks, as it is not very clear from the documentation:
Is it recommended to design hooks that run for a very long period of time (e.g. hours up to days?) or should those rather be designed as standard-jobs?

Chart hooks are designed for specific tasks which are reflected in their name. Is there a need for a post-install hook that runs for hours or days? A hook is part of the process for Helm (a package manager) to install, upgrade, or delete an instance of a chart. Helm will wait on hooks to complete as part of this process. So, a hook that runs for hours will leave Helm running (with a long timeout) as it processes a hook for installing, upgrading, or deleting.
Most of the time, a long running hook (for hours or days) isn't a good idea. For example, if the network drops between the Helm client and the Kubernetes API the release information (stored by default as a secret) won't be updated to show the process completed.
If something is part of an app it shouldn't be a hook. That should be a job or other Kubernetes resource since it's not part of the install, upgrade, or delete process.
Does that help?

Thanks that answers the question.
Essentially I'm talking about stuff like db-data-migration that can take a long time.
I guess one could still say the data-migration is part of the upgrade process, but I assume according to your answer this would rather be considered a part of the application


Versioned geocoding vs. logs

So the core difficulty of the geocoder in my mind will be providing versioning/time-sensitive capabilities. As I understand it, this capability is important because we need a way to verify the return value of a geocode operation done at a given time.
So, alternatively to providing some sort of temporal hierarchy within elasticsearch, what is the downside to just having fine-grained logs on the returns of calls to the geocoder?
If someone is claims they got a different value in some past state of the geocoder, rather than requiring time-sensitive queries, we could just search our logs for their query. In the logged result we'll see what the past return value was... so in this way we could allow verify the output of the geocoder without having to introduce the time complexity to its code base.
Thoughts? Do we want anyone to be able to verify geocoder returns by date or is this something that needs to be done internally?

Good question.  I think it probably depends on the true purpose/value of returning historical geocodes.  Is it purely for resolving disputes related to geocode conflicts, or is there greater utility?  Also, are we assuming that they are only using the history to check our history, or would they be using it to check against results they'd received from other geocoders.
Searching the logs seems dicey.  We're not requiring an API key, so how would we identify their search?  We could query the logs for the address (assuming the logs will also be in Elasticsearch), and return the resulting JSON if found, but could they game this system?  What if a user requests large batches of addresses just to see if anyone has done a searches on those address?

Also, are we planning on returning why a geocode changed?

Data source updated
Data source changed (ex: from TIGER to Arkansas state data)

And if yes, do we need to report back the actual data source a temporal geocode came from?

@wpears The idea is intriguing, but as @hkeeler has commented it has some problems. Also, doing what you suggest would require for us to treat logs as a source of truth, i.e. make them persistent forever and put in place the architecture necessary for not losing any log entry. This is hard to do with generic solutions. Having said that, we will need to discuss what we mean by versioniong exactly. We can think of a transaction log for every geocode operation performed. It might also be the case that we only care about versioned geocodes for those entities that are under regulation, and not a generic user (how we differentiate those without API key is up for discussion; most likely wouldn't be at this level and the responsibility of another service).
@hkeeler I don't think we have flushed out the details that you are asking about yet, so answer to your question is that we haven't planned to return why a geocode has changed, but it's something that we will probably need to discuss at some point. As for returning which data source the geocode came from, we might not be able to do that depending on licenses and terms of the data source. Otherwise I'd be in favor of returning it (or a proxy such as "quality" to identify how "good" the source data is).

So re: identification/API keys, we haven't talked about how we are confirming/authenticating FIs from Panel, would part of that process be registration of the registration be the generation of an API key that we use both for data intake and to stratify geocodes into versioned / non-versioned (if that is a goal)?


9.2.0 downgrade N3DS

So iam at the part where im trying to downgrade to 9.2.0 everything have gone fine until this part.
When pressing (Y) for downgrade the following happens.
Checking for am:u...
Did not get am:u handle!
Attemting svchax...
Initted svchax...
Innited services...
Checking for am:u...
Got am:u handle!
Beginning downgrade...
Getting firmware files information...
Getting firmware files version...
NATIVE_FIRM<PHONE_NUMBER>000002.cia) is v17120
Verifying firmware files...
titleException:
main.cpp:200: Result: 0x0
Too many titles in /updates/ found!
Have tried different sources for the 9.2.0 update but still get stuck on this. Im on E version if that matters.
What could be wrong?

You should not need to try different sources for the update.
There should be 104 .cia files in your updates folder, you seem to have too many. Just delete the whole folder, get the update from here and verify its file integrity.
To do so either use your torrent client's verification option or a checksum generation tool.
Your 9.2.0-20E(Full)_n3DS.zip file should have the following checksums:
MD5: aaa5960a3061da1f08d944d8e7017bd6
SHA-1: 306d0aa8cd195f9ee4388a9686db5658a330b59b
SHA-256: e7fbaf4ee01b81a3c2297028ef3fddc002f6933bfd20c2453bc6137bda89e5fd
Afterwards copy the updates folder from 9.2.0-20E(Full)_n3DS.zip to the root of your SD card and retry the downgrade process.

checksums are a match to what you wrote and there are 104 files in the updates folder on the root of the SD card.

A similar problem occurred at my n3ds as well. My n3ds is 10.7.0-32J now and I want to downgrade to 9.2.0-20J. I downloaded the 9.2.0-20J(Full)_n3DS.zip file here and there is total 102 .cia inside. But sysDowngrader still reported too fewer titles. How many .cia files should be there in 9.2.0-20J(Full)_n3DS.zip? Thanks a lot!

Plailect/sysDowngrader/issues/3

Are the filelists of J and E the same?

no if i recall correctly the J cias should be fewer. In past tutorials one had to delete some cias if they had a J console. Don't qoute me on that though.

Oh it works! Great! I tried v2 earlier and failed. This time I used the latest v5 and finally succeeded!

Another question, my n3ds automatically reboot after downgrade without taking away the tf card. I can see the version No. 9.1.0-20J in settings and I can launch Decrypt9WIP in HBL. Is this a perfect downgrade?

Fixed with https://github.com/Plailect/sysDowngrader/commit/44b462f527cf8fdc79c71ad6e4f427c01f7a561e, release coming soon

@Plailect any idea when the new release with this fix will drop? I'm using 1.0.3 and still getting this issue. Any recommendations on what I can do in the meantime to fix this?


Testing for repository smart contracts

This PR aims to contribute unit and simulation tests of the smart contracts in the repository.

I just tested this on an M1 Mac, and added a PR with some QoL additions for running it on M1.
While the sandbox tests seem to work fine, resulting in two passed tests:
 ✔ main contract: nft metadata view (13.9s)
 ✔ main contract: nft mint call (17s)

The testnet tests timeout with no other info.
 ✖ Timed out while running tests

 2 tests were pending in __tests__/basic_flow.ava.ts

 ◌ main contract: nft metadata view
 ◌ main contract: nft mint call

Any ideas if I'm doing something wrong while testing?

Just edited the scripts to fix github test runners #26

Deprecated


[CRON] Cron Support for Laravel

Description:
Sentry recently shipped Cron Monitoring (open beta at the time of writing)
Laravel developers could uniquely benefit from this functionality as well.
Feel free to join the discussion or comment here

duplicate https://github.com/getsentry/sentry-laravel/issues/628


Redirect payment support

Hi there,
I am looking for similar abstraction layer above different payment gateways. We already did several integrations with payment gateways, but they are all redirect based. This method consists of 2 steps:

We redirect our user to payment gateway webpage where he will enter his credit card details.
Once he done, the payment gateway calls a return page that is mapped to our REST API with payment status and payment token (partial credit card and customer details).

So I am trying to understand whether the J2pay payment flow has the redirect payment method support.
Thank you

Hey,
Thanks for reaching out.
J2pay does not support redirection methods.
It is designed to only worked on server side.
But we are interested to expand our library.
If you could help us with the redirection integrations i believe we can do that.
Thanks

No j2pay doesn't support redirect payment method.
You will have to get card details at your own page and then your system
will call j2pay with reference to the gateway on which you want to process
payment.
J2pay will respond to you about payment confirmation.
In this way customer will always remains at your own website.
Hope this helps
On Tue, Feb 19, 2019, 9:12 PM David Roberin<EMAIL_ADDRESS>wrote:

Hi there,
I am looking for similar abstraction layer above different payment
gateways. We already did several integrations with payment gateways, but
they are all redirect based. This method consists of 2 steps:

We redirect our user to payment gateway webpage where he will enter
his credit card details.
Once he done, the payment gateway calls a return page that is
mapped to our REST API with payment status and payment token (partial
credit card and customer details).

So I am trying to understand whether the J2pay payment flow has the
redirect payment method support.
Thank you
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/tranxactive/J2PAY/issues/22, or mute the thread
https://github.com/notifications/unsubscribe-auth/ARixlGplewLLGULTEdlQN7h8goZ-6GfVks5vPCJcgaJpZM4bDUoG
.


Make HTTPS optional

Due to the server crashing when a https section in the config object isn't defined, and the first example code for the project seems to not have a https section in it, I decided to do a small pull request that addresses exactly this.
node_http_server.js now checks if this.config.https is available and only then will it open up an HTTPS server.
Same for the WSS server - if this.httpsServer isn't defined, it won't create the WSS server or add HTTPS .listen methods.

I should additionally add that my main intention for this was solely the RTMP part.
As in, being able to stream to it and watch it back in VLC from another device.
That's why I, personally, don't need the HTTPS part, for example, and I assume there's other people out there that wouldn't require it either.

Exactly, i think will be nice to turn https optional.
btw, this module it's amazing. Thanks a lot!

This is fine, I forgot to check this option.

thanks


Trigger release for debian base

Issue #, if available: https://github.com/aws/eks-distro-build-tooling/issues/1056
Description of changes: release new debian base with new go version
/hold
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm

/approve
/hold cancel


[WIP]: px4_fmu-v5, px4_fmu-v5x, modalai_fv-v1 switch to new InvenSense IMU drivers (icm20602 & icm20689)

Requires https://github.com/PX4/Firmware/pull/14207.
@PX4/testflights could you try this on all px4_fmu-v5 (pixhawk 4, 4 mini, CUAV v5+, CUAV Nano) vehicles?

@modaltb FYI

Rad, I can test this out for sure.  Thanks for the heads up.

Tested on CUAV nano V5
Indoor Flight Test
Modes Tested
Stabilized Mode: Good.
Procedure
Arm and Take off in stabilized mode.
Notes
No issues noted, good flight in general.
Log https://review.px4.io/plot_app?log=6a74189a-82d2-4241-91ac-03a5b0dc2ca8

Tested on Pixhawk4 v5 f-450
Indoor Flight Test
Modes Tested
Stabilized Mode: Good.
Procedure
Arm and Take off in stabilized mode.
Notes
No issues noted, good flight in general.
Log
https://review.px4.io/plot_app?log=f3f445fb-bbf4-433e-bf44-2c5314dce720
Tested on pixhawkmini v5 f-450
Indoor Flight Test
Modes Tested
Stabilized Mode: Good.
Procedure
Arm and Take off in stabilized mode.
Notes
No issues noted, good flight in general.
Log
https://review.px4.io/plot_app?log=39718629-fc97-4b0b-a62b-707e0a8dc0df

Continued in https://github.com/PX4/Firmware/pull/14473.


Lock screen notifications do not display on Android Q Beta 2

Expected behavior
When an email is received and notifications are configured appropriate, a notification of the new message should appear on the lock screen.
Actual behavior
When only one new email has been received, nothing is displayed on the lock screen.  If two or more new emails are received, the lockscreen notifications work as normal.
Steps to reproduce

Install and configure K9 on an Android Q device or emulator
Receive a mail
Go to the lock screen and see that no notification is displayed
Receive another mail
Go to the lock screen and see that notifications are displayed normally

Environment
K-9 Mail version: 5.600
Android version: Q beta 2
Account type (IMAP, POP3, WebDAV/Exchange): IMAP

Probably no longer an issue with K-9 Mail 5.800 or newer.


docs: integrations/providers/unstructured update

Updated a page with existing document loaders with links to examples. Fixed formatting of one example.

@efriis Could you please check the Vercel errors? I don't have access to them. Thanks!

@eyurtsev  Could you please check the Vercel errors? I don't have access to them. Thanks!
docs_build works fine locally. I've checked all new and changed links.

@baskaryan  Could you please send me the Vercel errors? I don't have access to them. Thanks!
docs_build works fine locally. I've checked all new and changed links.

@efriis Could you please send me the Vercel errors? I don't have access to them. Thanks!
docs_build works fine locally. I've checked all new and changed links.

@efriis Could you please send me the Vercel errors? I don't have access to them. Thanks! docs_build works fine locally. I've checked all new and changed links.

broken link
[ERROR] Error: Docusaurus found broken links!
09:35:41.421 |
09:35:41.421 | Please check the pages of your site in the list below, and make sure you don't reference any path that does not exist.
09:35:41.421 | Note: it's possible to ignore broken links with the 'onBrokenLinks' Docusaurus configuration, and let the build pass.
09:35:41.421 |
09:35:41.422 | Exhaustive list of all broken links found:
09:35:41.422 |
09:35:41.422 | - On source page path = /docs/integrations/providers/unstructured:
09:35:41.422 | -> linking to /docs/integrations/document_loaders/unstructured
09:35:41.422

@efriis Thanks!