camera FOV

Hi. Two possibly related questions.

How can I set a camera FOV when using orbit-controls-component?
What is minZoom and maxZoom for? The term zoom is used in enableZoom and zoomSpeed, but I can't get minZoom and maxZoom to do anything, since mouse-scroll is actually dolly-ing the camera. In the code, it seems all zoom-related actions (by mouse and by touch) are handled via dolly-ing. The limits minDistance and maxDistance are working fine here, but I need actual zoom.

Am I missing something? Thanks.

Hey @jaap3d,
i have to issue a small disclaimer before trying to answer your questions. I'm not a classic programmer, but a designer that practices programming to build prototypes. I ported this component from the threeJS because i needed it in a project. This was – due to my limited experience – mostly copy pasting and tweaking stuff until it worked. I then put it on github because i thought why not and now i'm here. Anyways, it is great to see people actually using it and wanting it to improve. I will try my best to do so.
Trying to answer your questions:

It's not possible until now but i will look into it and add it as a feature request, ok?
I don't think you're missing something. I will look in this.

Hey @jaap3d,
i took the time to look through the whole source code and compare it with the original OrbitControls. It turns out the zoom is just for orthographic cameras that cannot dolly like a perspective camera can. I will update the README to reflect this restriction.
Can you maybe explain your use case for the zoom? I currently can't see that you can't achieve the same effect with the position/dolly.
Thanks a lot and cheers,
Till

Hey @jaap3d,
i just found that POV and zoom can be set on the camera entity. Please have a look at the basic example of v0.1.3.
Thanks!

Hi @tizzle,
Thanks a lot for looking into this. I'm a designer (just like you) and really not a programmer. My issue with zoom instead of dolly was because I'm working on a project with a small object: interacting with a phone. When close to the object, with dolly, the perspective angles get exaggerated when rotating the thing. If you keep a bit of distance and actually zoom in, the object stays nicely in proportion. Also, you see much less of the background whooshing by.
You mentioned v0.1.3. This was the master branch? Is it now changed to v0.1.4. Are older versions still accessible? I have a problem with your examples. They reference <script src="../build.js"></script> and when I run the master-branch locally, I don't have this build.js. Again: am I missing something? :)
Cheers.

Hey @jaap3d,
i feel i forgot something, as i always use the npm packages. I will have a look.
Cheers
Till

Hey @jaap3d,
the build.js was not added to the repository and only available once you built it locally. I now updated the repository to also include this. The examples now should work out of the box, i also added a link to examples in the README.
Once you cloned this repository (newest version v0.1.5) you should be able to run the examples by simply opening the index.html in the examples folder.
Let me know how it goes!
Cheers

Hi.
Awesome work! The examples are great. Thanks for fixing the FOV issue.
Next, I'll be developing my mouse-interface (using your orbit-cam). In the past couple days, I've worked on the look-only interface for HMD's. I think it's very awkward and not really usable. If you like, take a look at my project over at jaapdankert.nl/iphone and tell me what you think (you're supposed to find 2 screws on the bottom and then pop the front off). It's going to be a demo of web-based technical training.
Cheers, Jaap.


Implement backup workflow

Investigate https://github.com/django-backup/django-backup.

Done. https://github.com/softwaresaved/fat#backup


Return 404 if Subscribable not found

As we are retrieving SubscriberList using find_by it can be nil when not found. This commit returns nil and 404 in this scenario rather than letting a 500 happen when we try to get the attributes.
Part of Trello

Thanks @tuzz I've put a card in to return appropriate JSON errors and we can revisit this.


Upgrade go-fuse to tagged revision

Description
#852 upgraded go-fuse to commit fc2c4d3, as it contained a fix for a bug that would cause cp/mv/install to hang on sparse files. This issue tracks upgrading go-fuse to a tagged revision once the fix is included in a release.
Steps to reproduce the bug
No response
Describe the results you expected
Upgrade go-fuse to a tagged revision once the fix is included in a release.
Host information

OS:
Snapshotter Version:
Containerd Version:

Any additional context or information about the bug
No response

Is it possible that we could get this released? eg release 0.4.1 containing this fix? This is blocking our ability to use SOCI indexes on ECS

Hey, sorry for the wait, we had some issues with updating our release process but they are resolved now. Release v0.4.1 is now out, so if you are consuming SOCI via ECS on EC2 you can now pull this release in. If you are using Fargate this should already be available to you. Thank you for your patience!


Clarify language around listener availability on gateway addresses

What would you like to be added:
Add language stating:

That implementations MUST be able to serve all attached routes from every address listed under the Gateway's address status.
That implementations MUST mark Gateways not Accepted if the requested listeners cannot all be provisioned on a single IP.

Add a catch-all Gateway Accepted reason indicating that the Gateway is not accepted because the implementation or environment cannot support it.
Why this is needed:
The Gateway API supports freely adding any combination of listeners that satisfy general conflict avoidance rules. However, implementations may not necessarily be able to a listener set that has no conflicts.
LoadBalancers that handle both TCP and UDP traffic may not be available:

MixedProtocolLBService was not GA in Kubernetes <1.26)
MixedProtocolLBService is not necessarily supported by cloud providers. For example EKS still has an open PR to support this and GKE has code that rejects mixed-protocol LoadBalancers

Implementations may be unable to support multiple protocols on the same port:

NGINX-based implementations separate http and stream (L4) proxying and cannot serve the two on the same IP:Port combo. They cannot, therefore, support both HTTPS and TLS listeners on the same port (absent elaborate configuration to double-proxy through an initial stream layer to an http layer behind).
I suspect, but do not know for sure, that cloud provider-integrated implementations may be unable to support mixed HTTPS and TLS, as they typically implement rich HTTP routing and filtering features in L7 load balancers that cannot process non-HTTP traffic.
As a counterexample, Envoy explicitly does support mixed HTTPS and TLS.

Existing condition reasons do not distinguish between spec violations and implementation/environment incompatibility.
The additional Gateway reason distinguishes these cases from cases where the listeners are invalid. Listener configuration may be valid (compliant with the general anti-conflict rules) but not satisfiable due to implementation or environment limitations.
Meeting discussion indicated we may wish to add additional listener conditions as well, but I think the existing port and protocol not accepted conditions are probably sufficient. We should add an "implementation reasons" clause to the ListenerReasonUnsupportedProtocol comment, but I think implementation-chosen messages in combination with the new broader Gateway accepted reason should be expressive enough.

Although cloud provider-level limitations will block acceptance of some Gateways, it's not clear that controllers have any way of determining this. There appears to be no standard means of determining that a cloud provider cannot provision a LoadBalancer:

Service status' LoadBalancerStatus only has room for positive information, to indicate an IP if the cloud provider has attached one. While absence of an IP may indicate a provisioning failure, it may also indicate that no load balancer provider is available or that it is still busy provisioning.
GKE assigns a Condition, but it appears these standard error reasons were intentionally removed from upstream core. There is no obvious successor.

Although controllers cannot determine this issue reliably, this is probably of less concern because the Service will never receive an IP, so we'll never indicate that the Gateway is live (by adding IPs to its status) anyway.

/triage accepted
/milestone v1.0.0
/area documentation

Went and read through the existing language more in depth and now think that we don't need additional Reasons. The existing ones do state they can be used for either protocol or implementation reasons, and that's maybe a murkier boundary than I initially thought anyway.
There are still clarity issues with the language around collapsing compatible Listeners:

You don't (AFAIK) really collapse compatible Listeners as stated--they're still separate entities in config and status, and really need to be separate in status since that's where attached routes info resides. Truly collapsing them would presumably mean saying that a TLSRoute is attached to an HTTPS protocol Listener, which doesn't really make sense.
We should clearly state that compatibility is at the discretion of the implementation, rather than a set of rules in the spec. Close reading does indicate that, but the prominence of the single example can make it seem like those are conditions that should generally be compatible
We don't clearly state here how an implementation should determine if it can consider Listeners compatible. The single IP requirement is elsewhere, but easy to miss reading this section alone. Not sure if there are other good criteria to call out.
The language around Hostname being a must condition for choosing the correct Listener gets a bit confusing given the mixture of L7 and L4 protocols. Can a UDP protocol Listener have a hostname? In the Listener struct, it can! and you could hypothetically direct traffic for it in some protocols. UDPRoute does not support hostnames, but we could hypothetically add some other route type that can attach to UDP listeners and does.

https://github.com/rainest/gateway-api/pull/1/files to stick similar notes inline.

I agree with the goals of the issue, and with the conclusions you've got in the initial comment. But I think that the above comment is worth digging into a bit:

You don't (AFAIK) really collapse compatible Listeners as stated--they're still separate entities in config and status, and really need to be separate in status since that's where attached routes info resides. Truly collapsing them would presumably mean saying that a TLSRoute is attached to an HTTPS protocol Listener, which doesn't really make sense.

I guess this is a "naming is hard" problem again - when we did this originally, we were all pretty clear that the rules were about "collapsing" Listeners from multiple Gateways, on the assumption that a single Gateway with incompatible Listeners would be rejected by the implementation with the Conditions and Reasons we describe. (You don't need to worry about creation time or object name in terms of Listener priority when everything is in the same Gateway, for example).
So yeah, "collapsing compatible Listeners" probably really should read "collapsing compatible Listeners between Gateways" instead.

We should clearly state that compatibility is at the discretion of the implementation, rather than a set of rules in the spec. Close reading does indicate that, but the prominence of the single example can make it seem like those are conditions that should generally be compatible

Agreed. This should be clearly stated, as should the fact that it's okay for implementations not to support these combinations. We should also codify combinations like this with Extended conformance tests and feature names (as far as we can), so they'll end up in the final conformance report.

We don't clearly state here how an implementation should determine if it can consider Listeners compatible. The single IP requirement is elsewhere, but easy to miss reading this section alone. Not sure if there are other good criteria to call out.

I think something like "here is a list of things that might make a set of Listeners incompatible, depending on the implementation. This list is not exhaustive".

The language around Hostname being a must condition for choosing the correct Listener gets a bit confusing given the mixture of L7 and L4 protocols. Can a UDP protocol Listener have a hostname? In the Listener struct, it can! and you could hypothetically direct traffic for it in some protocols. UDPRoute does not support hostnames, but we could hypothetically add some other route type that can attach to UDP listeners and does.

Hmm, yeah, we probably need to update this wording - maybe something like "If the hostname field is relevant for the Route type and protocol, then hostname must be distinct and compatible between Listeners (or whatever the rules actually are)", with an inline table including known route types and whether hostname is relevant.
tl;dr it turns out writing specs is hard, and I really appreciate the close reading @rainest!


Consider to use "unbescape" instead of "Coverity Escapers"

Coverity Escapers is extremely outdated and may or may not work correctly for current markup languages.
Unbescape is actively maintained and is used by other active template engines.
I may submit a pull request for this, but I wanted to draw attention to this first.

@ChristianCiach Sure just submit a PR for this

@ChristianCiach Gonna be available in next release

You really are fast! I planned to do that tomorrow :) Looks like it was even easier than I anticipated.

@ChristianCiach Release done ... gonna be available in maven central soon


Doesn't start on windows

Really excited to try this out but it doesn't look like it supports windows!
(venv) PS C:\Users\bubth\Development\test> python --version
Python 3.8.6
(venv) PS C:\Users\bubth\Development\test> pip install formation-studio
Requirement already satisfied: formation-studio in c:\users\bubth\development\test\venv\lib\site-packages (0.2.0)
Requirement already satisfied: lxml in c:\users\bubth\development\test\venv\lib\site-packages (from formation-studio) (4.6.2)
Requirement already satisfied: pywin32 in c:\users\bubth\development\test\venv\lib\site-packages (from formation-studio) (300)
Requirement already satisfied: Pillow in c:\users\bubth\development\test\venv\lib\site-packages (from formation-studio) (8.1.2)
(venv) PS C:\Users\bubth\Development\test> formation-studio
(venv) PS C:\Users\bubth\Development\test>

Nothing happens after running the formation-studio command.

Submitted a PR for this: https://github.com/ObaraEmmanuel/Formation/pull/6

Hello, thank you for using formation. Formation studio started out from windows so it's windows support should be excellent. I have never tried it out in a virtual environment though. Let me try and get back to you in a moment

Allright - the PR I submitted does fix this so it's not relying on any relative package directories and does fix this so it runs appropriately:

Feel free to ignore if you feel like the changes aren't appropriate.

FWIW - the way I usually test this is to run:
python setup.py sdist
pip install dist/<package-name>

Then I try and run the commands and make sure it doesn't error in a build job.
If that works for you but not for me I'd love to get you any more information that's helpful about the system I'm running - it's just a standard windows 10 installation with python3.8 installed from python.org.

The installation seems broken majorly because i forgot to add new packages to the set up file. See PR #6 for more details. Could we do this quickly and publish the fix to pypi asap


feat(progress-bar): setup basic

Description
Adding a cool progress bar to know what is going on.
Validation
Run this command and see progress bar
npx api-docs-tooling -i "/path/to/node/doc/api/*.md" -t legacy-html -o /tmp/out

Related Issues
Close #58
Check List

[x] I have read the Contributing Guidelines and made commit messages that follow the guideline.
[x] I've covered new added functionality with unit tests if necessary.

I'll take time today to fix this pr. When a generator as ended the process still running because the progressbar did't ended correctly

@ovflowd could you give last review ? 😄

Bump, @AugustinMauroy

IMO there should be a way to disable the progress bar, like --no-progress or something.

+1 would that be a --quiet mode (?) not sure we have any other sort of output

BTW @AugustinMauroy wdyt about https://github.com/bombshell-dev/clack feels like a nicer way for us to design this and looks neat!

BTW @AugustinMauroy wdyt about https://github.com/bombshell-dev/clack

I need to take a look before giving my opinion

+1 would that be a --quiet mode (?) not sure we have any other sort of output

Shouldn't it be the other way round? Shouldn't there be a flag displaying the progressbar?

Okay first look of clack, This may be an alternative to ordering, but the package does not have a progress bar feature. But it does have a spinner, which doesn't really help you keep track of the process.

Well you can always render:
:spinner: (1/40) - Generating: (module that it is generating)

We don't necessarily need a progress bar, but a way to track that there's progress.

+1 would that be a --quiet mode (?) not sure we have any other sort of output

Shouldn't it be the other way round? Shouldn't there be a flag displaying the progressbar?

I don't care either way, I just think there should be a toggle to disable/enable it. I don't care if it's toggle on or toggle off

+1 would that be a --quiet mode (?) not sure we have any other sort of output

Shouldn't it be the other way round? Shouldn't there be a flag displaying the progressbar?

I don't care either way, I just think there should be a toggle to disable/enable it. I don't care if it's toggle on or toggle off

I think it should be showing progress by default and an option to not show progress. Otherwise it doesn't make any sense lol

Okay first look of clack, This may be an alternative to ordering, but the package does not have a progress bar feature. But it does have a spinner, which doesn't really help you keep track of the process.

Well you can always render:
:spinner: (1/40) - Generating: (module that it is generating)

We don't necessarily need a progress bar, but a way to track that there's progress.

okay I'll try to do something like that:
https://github.com/bombshell-dev/clack/blob/main/examples/basic/spinner.ts
But note:

This package isn't tested
This package didn't publish npm release with npm provenance (what cli-progress doesn't do either)
Not yet in 1.0.0 and very recent

Okay first look of clack, This may be an alternative to ordering, but the package does not have a progress bar feature. But it does have a spinner, which doesn't really help you keep track of the process.

Well you can always render:
:spinner: (1/40) - Generating: (module that it is generating)

We don't necessarily need a progress bar, but a way to track that there's progress.

okay I'll try to do something like that<EMAIL_ADDRESS>But note:

This package isn't tested
This package didn't publish npm release with npm provenance (what cli-progress doesn't do either)
Not yet in 1.0.0 and very recent

That is just an example file, you can simply paste that here :)

BTW @AugustinMauroy is there any update here?

okay I use clack now. I din't have tested yet


Use move_metrics_to_cpu from Trainer to move metric computation to CPU

Is your feature request related to a problem? Please describe.

Moving metric computation to cpu is currently not working properly.

Describe the solution you'd like

We could instead use move_metrics_to_cpu in Trainer in config.yaml file. This way, PL would handle all the device assignments.

# PL Trainer Args. Don't add extra parameter here.
trainer:
  ...
  move_metrics_to_cpu: true
  ...

Might impact #110

The move_metrics_to_cpu argument is used to move the loss computation to CPU, so this is unrelated to the performance metric computation.
The only problem with the current approach for moving the performance metric computation to CPU, is that we have to explicitly move each tensor to the CPU before passing it to the metric collection, which somewhat clutters the code. Functionally, it works fine though.
Closing this issue


Global stats - stats about the competition in that year

Create a bunch of interesting statistics about the whole competition from that year. These statistics should be used for internal purposes only, to balance the competition and get insights about the current sules/competition.

„Turnaj mistrů“ – tournament with the highest average speaker points (excluding finals)
„Dream Team“ – team consisting of people with the highest average speaker points on that posision (each member can appear only once)
„Gaussova křivka“ – relative distribution of speaker points in the current season, and how it corelate with gaussian curve
number of debates in the season
number of teams in the season per each competition
number of novice teams and novice speakers in the season
average speaker points in the season
average speaker points per speaker position in the season
Win rates:
for each debater
for each motion
for each team

Jubilejní stá issue!

Issue edited with its purpose and scope changed


Allows for empty lines in URL wordlists

...because not every wordlist is 'clean'!

Thanks @g0tmi1k! Nice catch. I'll be working this into the mainline shortly.


Update UCP LDAP docs with change in behavior

File: datacenter/ucp/2.2/guides/admin/configure/external-auth/index.md

Also, when you switch from the built-in authentication to using LDAP authentication, all manually > created users whose usernames do not match any LDAP search results become inactive, with the > exception of the recovery admin user which can still login with the recovery admin password.

This is no longer true. Users that were manually created will still be active.

Yes, I noted this in the topic.

This is documented so we can close this one.


Add prettier

Update package.json to use latest dependencies and add devDependencies.
Remove old config files
Update travis-ci - linter dependencies are now automatically installed as part npm install
Let prettier reformat the code.
Correct outstanding linting errors

@jason-fox while i understand the purpose, i am not sure i am in favour of autofixing code.
personally, i prefer to have a failed build, and see what i have to change.
feelings?

@chicco785  - The philosophy behind the PR can be found here
The PR currently has a minimal config to show prettier standardizing code - the actual adding or positioning of { or what have you is not very relevant. The actual rules to apply can be configured of course.
The point is not that your coding style is better than mine or my coding style is better than yours,   it is that a robot applies a common neutral standard.

@jason-fox as said in general i prefer to have a failed build, because i don't comply, than having my code changed without any input on my side during a ci task.
it's not about being pro or against robot prettying your code. it's about applying automation carefully.
Currently beside, code being less readable (at least to me), it is inconsistent w.r.t. the style in which brackets are used. Which should not be the case, right?

to make and example, now we have a combination of
}

and
{}

Adding consistent whitespace around the brackets is easy enough, but not what prettier is about really. You need a code formatter like JsFormat for that.
What prettier did was to ensure that all if clauses had brackets e.g.:
   if (x)
       doSomething();

becomes:
   if (x)
       {doSomething();}

Which avoids problems like:
   if (x)
       doSomething();
       doSomethingElse();

Where doSomethingElse(); isn't in the if clause.
So why not improve with both standard syntax and standard formatting?
a. some-with-and-some-without-brackets . (Original)
b. all-with-brackets (Prettier)
c. all-with-brackets-and-nicely-indented (Prettier + JS Format)

Regarding failing the CI-build, all I have done is to amend the previous eslint as shown:
       before_script:
        - eslint --ext .json .
        - jshint .

       before_script:
        - npm run lint -C ./validator

The lint script is currently applying autofix via the --fix flag  this could of course be amended or split into two scripts or whatever.

as said, i would prefer no auto fix be applied by ci, but i am not stubborn about that :)
let's see @jmcanterafonseca feedback

With respect to whitespacing and brackets, adding a JavaScript beautifier should be kept as a separate PR. Obviously it will apply the same criteria over whether to autofix or not will apply for beautifying in the same manner as standardizing syntax.

@jmcanterafonseca  @chicco785 - maybe you would prefer that autofix is applied by husky on git commit rather than travis-ci.  I have altered the PR to use lint-staged.

This has the advantage that no 💩  reaches the git repository

It does however do things to your code when you commit (which may be unexpected)
I've also separated npm run lint and npm run prettier into two separate commands for local use.

it think it sounds better, because you will see changes locally before pushing to the remote repo, which also means that reverting is local and not remote, in case of need ;)

@chicco785 could you do a final check and LGTM it,  if suitable?

tested locally, LGTM!


GpuDebug flag and CSharp glue code

Please either update Window sample (which fails) or make this new parameter optional (meh)

Please either update Window sample (which fails) or make this new parameter optional (meh)
Done. Missed that file


there is any way to assign my api response to Yasr

i get  response from  sparqul  by using simple API call but now I want to pass my response to yasr and show that on webpage is there any way to assign my response to Yasr component in react

Hello @shanu3742,
You can do this by assigning YASR to a ref object and call yasrRef.current.setResponse
Let me know if this helps. Have a nice day!

Hi @GerwinBosch  i'm getting error like ncaught TypeError: yasrRef.current.setResponse is not a function

@shanu3742 I meant to put the instance of YASR in the ref when it is being initialized

Now I'm getting result in the form of rawResponse  but not in table from is any other things i have to do for that

I'm going to guess that you get back some kind of "normal" JSON. Make sure to add an accept header to your request. Use:  application/sparql-results+json (preferred), application/sparql-results+xml, CSV or TSV for Select queries and any kind of serialized triple format for construct queries

hi @GerwinBosch  sorry for all the basic question  and giving your valuable time , will you help me one more time how can I add other plugin like   'pivot','gchart' etc

Unfortunately, those are only available on yasgui.triply.cc and within TriplyDB see https://triply.cc/docs/yasgui-api#triplyDbPlugins
You can however write your own using https://triply.cc/docs/yasgui-api#writing-a-yasr-plugin

hi @GerwinBosch is there any way to disable the editing option in yasqe(query editor) I just want to show the query, not like interactive query edition
I'm custom selecting variables, query properties, and relations  from the input select fields so, I don't want the option like editing query on yasqe pannel

@srinivasAarth you can do that by setting readOnly:false

@GerwinBosch thanks for the response its working fine as like what I expected after adding the readOnly:true property

Oops got the boolean value wrong 😅. However, since your issues seem to be resolved can this issue be closed?

yes @GerwinBosch it was closed


Possible to get involved variables from functional form errors?

Hi, I'm trying out RxInfer and often running into ERROR: ProductOf object cannot be used as a functional form in inference backend. Use form constraints to restrict the functional form of marginal posteriors.. Is there any way to figure out which variables are involved in the ProductOf? As is I'm incrementally constructing a model to try to isolate variables, but it's pretty annoying.

Agreed, this should be improved


[bug] Version range without qualifiers creates ambiguous dependency retrieval

This issue was raised by @knrc
Today, Version ranges don’t have the ability to encode qualifiers, therefore, through a version range specified, it may be insufficient alone to retrieve the original package version used (with qualifiers and matching to hashes).
For example let's say we ingest SBOM 1 where
Artifact X1 --IsOccurrence--> Pkg X
Pkg X --IsDepedency { VersionRange: 1.3.0 }-> Pkg Y {Version 1.3.0, qualifiers: "OS=linux"} --IsOccurrence--> Artifact Y1
and we ingest SBOM 2 where
Artifact X2 --IsOccurrence--> Pkg X
Pkg X --IsDepedency { VersionRange: 1.3.0 }-> Pkg Y {Version 1.3.0, qualifiers: "OS=windows"} --IsOccurrence--> Artifact Y2
It would be impossible to be able to know just by retrieving and following the edges of Artifact X1 that it is using version 1.3.0 OS=linux instead of OS=windows. This introduces undifferentiatable ambiguity.

With https://github.com/guacsec/guac/pull/1125, this is no longer required since we can point directly to version nodes


[Beta] Tauri breaks when adding specific CSS properties

Here's the scenario:

Clone this repo: https://github.com/Orbitale/Compotes/tree/rewrite
Check out the rewrite branch
Run yarn install && yarn tauri deps install
Run yarn dev in a console
Open another console and run yarn tauri dev
Everything should work properly: you see a splash screen, and after a few seconds, it fades away, showing the "Hello world!" from the Svelte app.

Now, here's how to trigger the bug:

Open public/index.html at line 53
Uncomment the animation-name: orbitale_logo_rotation; CSS statement
The console in which you ran yarn tauri dev should display this:$ yarn tauri dev
yarn run v1.22.10
$ /var/www/Compotes3/node_modules/.bin/tauri dev
 app:spawn Running "/var/www/Compotes3/node_modules/@tauri-apps/cli/bin/tauri-cli tauri dev" +0ms

  Finished dev [unoptimized + debuginfo] target(s) in 0.11s
   Running `target/debug/app`

(WebKitWebProcess:6095): Gdk-ERROR **: 00:00:49.199: The program 'WebKitWebProcess' received an X Window System error.
This probably reflects a bug in the program.
The error was 'GLXBadFBConfig'.
  (Details: serial 172 error_code 163 request_code 149 (GLX) minor_code 21)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

The desktop app doesn't update

Other scenario:

Open the public/index.html file at line 30
Replace position: absolute; with position: fixed;
Error pops in your console and desktop app doesn't update.

Worth noting:

The animation that is bound to #splash_screen.remove works without any issue, it is related to the opacity property going from 1 to 0.
I tested to remove the animation on the #orbitale_logo selector and instead just transform: rotate(0deg);, to see if the issue was coming from the transform property, and the error didn't show, the logo is properly rotated. Only animating the property triggers the error.

Tested in Ubuntu 20.04 under WSL 2, display has been tested with a plain VcXsrv setup and with GWSL with different configs that didn't change anything, the error still pops.
Tomorrow I will test on a true Ubuntu 20.04 machine, I just don't have access to it right now, but maybe this could help leading some more investigation on this particular issue. I'll update this issue then.

I tested on a native Ubuntu machine, and I can confirm that the error does not appear, with any property.
So this is certainly a WSL-only issue 😕
I didn't test on native Windows because I have another issue ("cannot create webview"), I don't know (yet?) if it's related to the same subject.

Okay, I found a way to make it work!
Not sure it's a "definite" solution, but here is what I did:

At first, I ran export LIBGL_ALWAYS_INDIRECT=0
I updated my VcXsrv command and replaced -wgl with -nowgl
It now works

I honestly just jiggled with parameters after looking at bazillion posts and tutorials and stuff, and now it works...
I hope it will keep working 😅

So you just turned off webgl? I doubt this is going to be a good solution for consumers of your application and sounds very hacky since it treats the problem instead of solves it.

 I doubt this is going to be a good solution for consumers of your application and sounds very hacky since it treats the problem instead of solves it.

I agree, that's the reason why I think the "fix" isn't really a fix to me. WebGL seems to be mandatory for such app.
However, I think running this app on WSL isn't the purpose at all. I use WSL for development, but in the end, the linux version of it is supposed to be downloaded on linux platforms, not WSL.
Maybe I'm too skeptical to think that WSL is for development only, but I think that this isn't the "common" way of running apps 😅

closed it by accident 😅

Think its probably a good idea to close this issue for now.  If you want to use webkit-gtk under WSL right now, then you need to use WSL 1 not WSL 2.  In the meantime, Microsoft is developing a method to use GUI apps under WSL 2 that uses the GPU called WSLg.   Its in the dev branch of the insider build of windows right now though I don't recommend updating to it until its in the beta branch.


Setup Django API and ingest pipelines

For MVP, we'll focus on lightweight ingestion (e.g., JupyterNotebook) that technical stakeholders can add data with. In a future phase, we could build more dedicated ingest functionality (e.g., frontend, admin console, and authentication).

@willemarcel might decide to use FastAPI instead of Django. He'll chat with @leothomas and update here shortly.

Blocked until we hear back from the data consultant and their roles/tasks


Prime factorization?

With the merger of #145, I think we have just about everything needed. I've prepared a branch which adds math/factor for the purpose of evaluation.
Using this test script, I get timings like this:
pseudoprimes   1.003s, 47.74µs/body
small integers 0.469s, 4.688µs/body

Which is definitely fast enough to be of use.
One issue that I currently have is that math/gcd does not work with abstract types, although it does appear to be written by hand (and not a direct math.h function), so it could possibly be updated. I also think that the pollard-rho implementation could be cleaned up a bit.

Below are the times I got when using janet 1.30.0:
$ JANET_PATH=~/src/spork.primo-ppcg/jpm_tree/lib janet ~/scratch/test-factor.janet
pseudoprimes   1.002s, 82.27µs/body
small integers 0.603s, 6.029µs/body

FWIW, results were similar with janet's 7049f658.

/me is looking forward to upgrading hardware...

After https://github.com/janet-lang/janet/pull/1249 this became about 15% faster:
pseudoprimes   1.004s, 41.61µs/body
small integers 0.331s, 3.308µs/body

and the strange thing is, I don't even use any compare method... not directly anyway.

With that janet (7475362c), I got:
$ JANET_PATH=~/src/spork.primo-ppcg/jpm_tree/lib janet ~/scratch/test-factor.janet
pseudoprimes   1.004s, 75.69µs/body
small integers 0.432s, 4.316µs/body

So there is some speedup here too.

I've updated to handle int/s64 and int/u64:
> (factor<PHONE_NUMBER>23)
@[3 12049 3415409]
> (factor (int/s64<PHONE_NUMBER>23))
@[<core/s64 3> <core/s64 12049> <core/s64 3415409>]

It has become a bit slower, but that was expected. Not too bad, though:
pseudoprimes   1.001s, 42.47µs/body
small integers 0.428s, 4.278µs/body

The merge sort became a bit messy, because compare< doesn't handle nil elegantly.
(defn- merge-sorted
  "merge two sorted arrays"
  [a b]
  (def len (+ (length a) (length b)))
  (def c (array/new-filled len))
  (var [i j] [0 0])
  (forv k 0 len
    (let [u (get a i)
          v (get b j)]
      (if (not= nil u)
        (if (not= nil v)
          (if (compare< u v)
            (do (put c k u) (++ i))
            (do (put c k v) (++ j)))
          (do (put c k u) (++ i)))
        (do (put c k v) (++ j)))))
  c)

In particular, the repetition is a somewhat ugly. If someone could help clean that up, that'd be really nice :laughing:

Didn't have luck reducing duplication, but possibly the following is a bit easier to read?
(defn- merge-sorted-2
  "merge two sorted arrays"
  [a b]
  (def len (+ (length a) (length b)))
  (def c (array/new-filled len))
  (var [i j] [0 0])
  (forv k 0 len
    (def [u v] [(get a i) (get b j)])
    (cond
      (nil? u) (do (put c k v) (++ j))
      (nil? v) (do (put c k u) (++ i))
      (compare< u v) (do (put c k u) (++ i))
      (do (put c k v) (++ j))))
  c)

Definitely nicer to look at :+1:

or may be without the repeated destructuring in the loop could be better?

Destructuring is already compilter optimized :smiley:

I had another version which is longer and not as nice to view, but may be it does less comparisons sometimes...
(defn- merge-sorted-3
  "merge two sorted arrays"
  [a b]
  (def len (+ (length a) (length b)))
  (def c (array/new-filled len))
  (var [i j k] [0 0 0])
  (var [u v] [(get a i) (get b j)])
  (while (and (not= nil u) (not= nil v))
    (if (compare< u v)
      (do
        (put c k u)
        (++ i)
        (set u (get a i)))
      (do
        (put c k v)
        (++ j)
        (set v (get b j))))
    (++ k))
  (cond
    (nil? u)
    (while (< k len)
      (put c k v)
      (++ j)
      (set v (get b j))
      (++ k))
    #
    (nil? v)
    (while (< k len)
      (put c k u)
      (++ i)
      (set u (get a i))
      (++ k)))
  c)

Possibly not worth it.

I think that merge-sorted and merge-sorted-by could be nice complements to insert-sorted and insert-sorted-by in spork/misc.

I am sure it would be excellent :-).

Possibly not worth it.

Switching nil? for = nil is a more significant performance gain :wink:

If there were an array/blit (cf. buffer/blit), may be one could have done something like:
(defn- merge-sorted-4
  "merge two sorted arrays"
  [a b]
  (def len (+ (length a) (length b)))
  (def c (array/new-filled len))
  (var [i j k] [0 0 0])
  (var [u v] [(get a i) (get b j)])
  (while (and (not= nil u) (not= nil v))
    (if (compare< u v)
      (do
        (put c k u)
        (++ i)
        (set u (get a i)))
      (do
        (put c k v)
        (++ j)
        (set v (get b j))))
    (++ k))
  (when (< k len)
    (cond
      (not= nil v) (array/blit c a k i)
      (not= nil u) (array/blit c b k j)))
  c)

Switching nil? for = nil is a more significant performance gain

Often torn by these sorts of things because I find nil? (and zero?, one?, etc.) easier to read and less likely to mistype.

Often torn by these sorts of things because I find nil? (and zero?, one?, etc.) easier to read and less likely to mistype.

I think there's a reasonable expectation that core functions (and even "official contrib" functions) are a written approximately as efficiently as possible, i.e. a user likely wouldn't be able to write anything more efficient by hand. If I find that isn't the case, I make a PR about it.

Great work @primo-ppcg !

If there were an array/blit (cf. buffer/blit)

Was looking at @MikeBeller's janet-benchmarksgame for reasons (TM), and noticed this text:

An equivalent of buffer/blit for arrays (e.g. array/blit) would help as a lot of benchmarks involve moving things between arrays, and if you use Janet's indexed combinators, they are always allocating new arrays. (See fannkuch) array/reverse-in would also be great.

via https://github.com/MikeBeller/janet-benchmarksgame#ideas-for-improving-janet-performance


Slate does not round trip for some examples of markdown annotations around variables

Describe the bug
Some examples of markdown annotations (e.g., bold/italics) around CiceroMark variables disappear when doing a round-trip through the Slate Document Object Model.
For instance:
bash-3.2$ cat test.md
cat test.md
PROMISSORY NOTE
====

**<variable id="amount" value="1%2C000.00%20USD" format="0%2C0.00%20CCC"/>** **<variable id="date" value="01%2F30%2F2018"/>**

FOR VALUE RECEIVED, the undersigned, **<variable id="maker" value="%22Daniel%22"/>**, **<if id="individual" value="an%20individual%20residing" whenTrue="an%20individual%20residing" whenFalse="a%20company%20registered"/>** at **<variable id="makerAddress" value="%221%20Main%20Street%22"/>** (“Maker”), hereby promises to pay to the order of **<variable id="lender" value="%22Clause%20Inc.%22"/>**, a **<variable id="legalEntity" value="CORP"/>**, having offices at **<variable id="lenderAddress" value="%22246%205th%20Ave%2C%203rd%20Fl%2C%20New%20York%2C%20NY%2010001%22"/>**, or its successors and permitted assigns (“Lender” or the “Company”), the principal sum of **<variable id="principal" value="500.00%20USD" format="0%2C0.00%20CCC"/>**, plus any and all interest accrued thereon at the Note Rate (defined below), each due and payable in cash in lawful money of the United States on the dates and in the manner set forth in this Promissory Note (this “Note”).
....
bash-3.2$ markus normalize --sample test.md --output test3.md --slate
2:09:01 PM - info: Creating file: test3.md
2:09:01 PM - info:
PROMISSORY NOTE
====

<variable id="amount" value="1%2C000.00%20USD" format="0%2C0.00%20CCC"/> <variable id="date" value="01%2F30%2F2018"/>

FOR VALUE RECEIVED, the undersigned, <variable id="maker" value="%22Daniel%22"/>, <if id="individual" value="an%20individual%20residing" whenTrue="an%20individual%20residing" whenFalse="a%20company%20registered"/> at <variable id="makerAddress" value="%221%20Main%20Street%22"/> (“Maker”), hereby promises to pay to the order of <variable id="lender" value="%22Clause%20Inc.%22"/>, a <variable id="legalEntity" value="CORP"/>, having offices at <variable id="lenderAddress" value="%22246%205th%20Ave%2C%203rd%20Fl%2C%20New%20York%2C%20NY%2010001%22"/>, or its successors and permitted assigns (“Lender” or the “Company”), the principal sum of <variable id="principal" value="500.00%20USD" format="0%2C0.00%20CCC"/>, plus any and all interest accrued thereon at the Note Rate (defined below), each due and payable in cash in lawful money of the United States on the dates and in the manner set forth in this Promissory Note (this “Note”).
....
bash-3.2$

This bug also affects the current master branch based on Slate 0.57:
bash-3.2$ ~/git/markdown-transform/packages/markdown-cli/index.js normalize --sample test.md --output test3.md --slate
2:15:06 PM - info: Creating file: test3.md
2:15:06 PM - info:
PROMISSORY NOTE
====

<variable id="amount" value="1%2C000.00%20USD" format="0%2C0.00%20CCC"/> <variable id="date" value="01%2F30%2F2018"/>

FOR VALUE RECEIVED, the undersigned, <variable id="maker" value="%22Daniel%22"/>, <if id="individual" value="an%20individual%20residing" whenTrue="an%20individual%20residing" whenFalse="a%20company%20registered"/> at <variable id="makerAddress" value="%221%20Main%20Street%22"/> (“Maker”), hereby promises to pay to the order of <variable id="lender" value="%22Clause%20Inc.%22"/>, a <variable id="legalEntity" value="CORP"/>, having offices at <variable id="lenderAddress" value="%22246%205th%20Ave%2C%203rd%20Fl%2C%20New%20York%2C%20NY%2010001%22"/>, or its successors and permitted assigns (“Lender” or the “Company”), the principal sum of <variable id="principal" value="500.00%20USD" format="0%2C0.00%20CCC"/>, plus any and all interest accrued thereon at the Note Rate (defined below), each due and payable in cash in lawful money of the United States on the dates and in the manner set forth in this Promissory Note (this “Note”).
bash-3.2$ ~/git/markdown-transform/packages/markdown-cli/index.js normalize --sample test.md --output test3.md --cicero
~/git/markdown-transform/packages/markdown-cli/index.js normalize --sample test.md --output test3.md --cicero
2:15:24 PM - info: Creating file: test3.md
2:15:24 PM - info:
PROMISSORY NOTE
====

**<variable id="amount" value="1%2C000.00%20USD" format="0%2C0.00%20CCC"/>** **<variable id="date" value="01%2F30%2F2018"/>**

FOR VALUE RECEIVED, the undersigned, **<variable id="maker" value="%22Daniel%22"/>**, **<if id="individual" value="an%20individual%20residing" whenTrue="an%20individual%20residing" whenFalse="a%20company%20registered"/>** at **<variable id="makerAddress" value="%221%20Main%20Street%22"/>** (“Maker”), hereby promises to pay to the order of **<variable id="lender" value="%22Clause%20Inc.%22"/>**, a **<variable id="legalEntity" value="CORP"/>**, having offices at **<variable id="lenderAddress" value="%22246%205th%20Ave%2C%203rd%20Fl%2C%20New%20York%2C%20NY%2010001%22"/>**, or its successors and permitted assigns (“Lender” or the “Company”), the principal sum of **<variable id="principal" value="500.00%20USD" format="0%2C0.00%20CCC"/>**, plus any and all interest accrued thereon at the Note Rate (defined below), each due and payable in cash in lawful money of the United States on the dates and in the manner set forth in this Promissory Note (this “Note”).

(in master) In CiceroMark we have a Strong node around the variable:
{
          "$class": "org.accordproject.commonmark.Strong",
          "nodes": [
            {
              "$class": "org.accordproject.ciceromark.Variable",
              "id": "principal",
              "value": "500.00 USD",
              "format": "0,0.00 CCC"
            }
          ]
        }

But this gets pushed into a bold:true on the text inside the variable in Slate, not sure if that's right:
{
            "object": "inline",
            "type": "variable",
            "data": {
              "id": "principal",
              "format": "0,0.00 CCC"
            },
            "children": [
              {
                "object": "text",
                "text": "500.00 USD",
                "bold": true
              }
            ]
          }

Fixed in #216


Intern IDs that are likely to be repeated.

@plwhite this one is a bit more speculative.  It interns IDs that I expect to be duplicated a lot (profile IDs and tag IDs get used at least 4-8 times each so that might help quite a bit).  I'd appreciate if you or Alex could pass it through the scale test to see if it helps.

Intern white-listed fields while parsing JSON dicts and lists.
Intern EndpointID fields.

I ran a couple of basic FV tests against this and #610 merged together and they seemed to work.

I've added quite a few comments, all of them quite minor persnickerty things. Worth us proceeding to test this though, since none of them will have a major impact, and I think generally it looks most excellent.

I'm running the scale tests against this PR. Hopefully they'll finish before I leave the office; if not, I'll get them first thing tomorrow.

Only mid-way through code review markups so not ready to merge (might be worth a spin through the scale test though).

(Still some code review items to address)

Finished my markups.

@plwhite did you pass this back for me to fix up the conflict or something else?

Sorry, just to fix up the conflict. I thought I commented, but obviously failed to!

Conflicts fixed up. Back to you @plwhite

Sorry, but this still conflicts - presumably with something that I merged earlier today! Can you please fix and merge (no need for me to push the button). I'd do it myself but I need to get out to visit a customer now and we'd like that in today.

Conflict was just in CHANGES.md, so I just resolved after all and am now merging.


doesn't download "new" packages when getting dependencies

[MINGW-packages] [clangarm64] mingw-w64-python-pep517...
  [1/2] mingw-w64-clang-aarch64-python-pytoml-0.1.21-2-any.pkg.tar.zst
  [2/2] mingw-w64-clang-aarch64-python-setuptools-59.1.1-1-any.pkg.tar.zst
  ==> Adding package '/C/_REPO/clangarm64/mingw-w64-clang-aarch64-python-pytoml-0.1.21-2-any.pkg.tar.zst'
    -> Computing checksums...
    -> Creating 'desc' db entry...
    -> Creating 'files' db entry...
  ==> Adding package '/C/_REPO/clangarm64/mingw-w64-clang-aarch64-python-setuptools-59.1.1-1-any.pkg.tar.zst'
    -> Computing checksums...
    -> Creating 'desc' db entry...
    -> Creating 'files' db entry...
  ==> Creating updated database file '/C/_REPO/clangarm64/autobuild-clangarm64.db.tar.gz'
  :: Synchronizing package databases...
   autobuild-clangarm64 downloading...
   mingw32 downloading...
   mingw64 downloading...
   ucrt64 downloading...
   clang64 downloading...
   clang32 downloading...
   clangarm64 downloading...
   msys downloading...
  :: Starting core system upgrade...
   there is nothing to do
  :: Starting full system upgrade...
   there is nothing to do
  HEAD is now at eb5a8c7c9 enable package tree required to build tomli for clangarm64
  gpg: "gpg_KEY" not a key ID: skipping
  gpg: "gpg_KEY" not a key ID: skipping
  gpg: "gpg_KEY" not a key ID: skipping
  gpg: "gpg_KEY" not a key ID: skipping
  ==>  MINGW_ARCH: clangarm64
    -> Building clangarm64...
  ==> WARNING: PACKAGER should have the format 'Example Name<EMAIL_ADDRESS>  ==> Making package: mingw-w64-python-pep517 0.12.0-1 (Wed, Dec  1, 2021  1:48:35 PM)
  ==> Checking runtime dependencies...
  ==> Installing missing dependencies...
  error: target not found: mingw-w64-clang-aarch64-python-tomli
  ==> ERROR: 'pacman' failed to install missing dependencies.
  ==> Missing dependencies:
    -> mingw-w64-clang-aarch64-python-tomli

a) this seems to be in msys2-web, not autobuild, and b) it may be some sort of confusion about circular dependencies?

https://github.com/msys2-arm/msys2-autobuild/runs/4387514100?check_suite_focus=true
pep517 should have depended on tomli, but didn't.
virtualenv should have depended on setuptools-scm but didn't (and was actually attempted to be built before setuptools-scm as a result).

If my underlying assumptions are correct, maybe it would make more sense to put breaking dependency loops in autobuild instead of msys2-web.  autobuild's get_buildqueue_with_status would be able to know if some of them are already built and thus the "solution" would be obvious.

For context, it's that way currently so in case the cycle is already in the repo (the common case) it will fall back to the outdated package in the repo which usually works out.
I agree that autobuild could make smarter decisions if it had that info.

i think this only happens to python extensions right?

i think this only happens to python extensions right?

No, any dependency cycle could result in this.

I've removed this in https://github.com/msys2/msys2-web/commit/3c41af895f1734 now, so cycles will result in autobuild getting stuck if all of the cycle is missing.
But better than randomly missing deps I guess.

To prevent things getting stuck I've now added a manual list for breaking cycles:
https://github.com/msys2/msys2-autobuild/blob/a8d63e2852a11430d1be7c1fc5248f2bdf373f13/autobuild.py#L92
Not sure if this is the right approach.. we'll see. Other ideas welcome.

Ugh, it looks like maybe packages that are dependencies of -cc wind up in cycles.  I threw in +        "mingw-w64-openssl": ["mingw-w64-libxml2"], for the arm fork for now, but I think the libxml2 is coming in via cc, because it's only breaking on clang*.

Yeah.. Not really feasable...

I'll try to see how many cycles there are for a full rebuild.
The API currently only exposes all transitive dependencies, which isn't ideal for this. I might have to pull in all that dependency logic into autobuild.

There are 881 package pairs that are in cycles, so, no this doesn't scale.


How do I specify the compile option of GPU/CPU, when exec vcpkg install tensorflow-cc?

How do I specify the compile option of GPU/CPU, when exec vcpkg install tensorflow-cc?

It should be a tensorflow-cc new feature, not by compile option.

We hope your question was answered to your satisfaction; if it wasn't, you can reopen with more info.


Add back auth states

Adds back auth functionality that was accidentally removed in #13

Codecov Report

Merging #18 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #18   +/-   ##
=======================================
  Coverage   78.11%   78.11%
=======================================
  Files          16       16
  Lines         585      585
=======================================
  Hits          457      457
  Misses        128      128

Impacted Files
Coverage Δ

lib/constants.js
100% <ø> (ø)
: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 b452f83...8b9802f. Read the comment docs.


feat: Add boot subcommands to read boot entries

Codecov Report

Merging #57 (260cd8d) into master (cf034bf) will decrease coverage by 8.76%.
Report is 1 commits behind head on master.
The diff coverage is 0.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@            Coverage Diff             @@
##           master      #57      +/-   ##
==========================================
- Coverage   43.83%   35.07%   -8.76%
==========================================
  Files          20       26       +6
  Lines         924      975      +51
==========================================
- Hits          405      342      -63
- Misses        519      633     +114

Files Changed
Coverage Δ

efiboot/src/cli/boot/get_entries.rs
0.00% <0.00%> (ø)

efiboot/src/cli/boot/get_order.rs
0.00% <0.00%> (ø)

efiboot/src/main.rs
11.11% <0.00%> (-1.39%)
:arrow_down:

efivar/src/boot/boot_entries_reader.rs
0.00% <0.00%> (ø)

efivar/src/boot/boot_entry_parser.rs
0.00% <0.00%> (ø)

efivar/src/boot/boot_order_reader.rs
0.00% <0.00%> (ø)

efivar/src/boot/boot_var_reader.rs
0.00% <0.00%> (ø)

efivar/src/boot/parse/device_path.rs
0.00% <0.00%> (ø)

efivar/src/boot/parse/device_path_list.rs
0.00% <0.00%> (ø)

efivar/src/error.rs
0.00% <ø> (ø)

... and 1 more

... and 2 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


[BUG]: [dpg-dev | Pending Payments not coming for notice, summons and warrant (judge user role)]

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

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

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Hi @Ramu-kandimalla , kindly assign a ui dev to look into this.
cc: @prasanna2400


以图搜图如何使用自己的模型

在
p_embed = (
pipe.input('src')
.flat_map('src', 'img_path', load_image)
.map('img_path', 'img', ops.image_decode())
.map('img', 'vec', ops.image_embedding.timm(model_name=MODEL, device=DEVICE))
)
现在我有一个行人重识别的模型，在这里我需要怎么样做，才能替换为自己的模型。非常期待您的回复，感谢！

If you want to pass in the weights of a PyTorch model, you can pass it in as parameter: ops.image_embedding.timm(model_name=MODEL, device=DEVICE, checkpoint_path=YOUR_WEIGHTS_PATH)
If it contains PyTorch code, a new operator needs to be created.
https://towhee.readthedocs.io/en/latest/operator/usage.html#run-pipeline-with-named-operators
You can refer to this implementation
https://towhee.io/image-embedding/timm/raw/branch/main/timm_image.py

我可以使用timm库注册自己的模型吗

我可以使用timm库注册自己的模型吗

If you want to pass in the weights of a PyTorch model, you can pass it in as parameter: ops.image_embedding.timm(model_name=MODEL, device=DEVICE, checkpoint_path=YOUR_WEIGHTS_PATH) If it contains PyTorch code, a new operator needs to be created. https://towhee.readthedocs.io/en/latest/operator/usage.html#run-pipeline-with-named-operators You can refer to this implementation https://towhee.io/image-embedding/timm/raw/branch/main/timm_image.py

我可以使用timm库注册自己的模型吗

我想要替换掉以图搜图里的模型，使用自己的行人重识别模型。换句话说，我想让我的行人重识别模型可以像以图搜图项目那样部署在服务器上

If you want to pass in the weights of a PyTorch model, you can pass it in as parameter: ops.image_embedding.timm(model_name=MODEL, device=DEVICE, checkpoint_path=YOUR_WEIGHTS_PATH) If it contains PyTorch code, a new operator needs to be created. https://towhee.readthedocs.io/en/latest/operator/usage.html#run-pipeline-with-named-operators You can refer to this implementation https://towhee.io/image-embedding/timm/raw/branch/main/timm_image.py

我想要替换掉以图搜图里的模型，使用自己的行人重识别模型。换句话说，我想让我的行人重识别模型可以像以图搜图项目那样部署在服务器上

https://github.com/huggingface/pytorch-image-models/tree/main/timm/models
Can you find the model you are using there? If so, you can use timm.

https://github.com/huggingface/pytorch-image-models/tree/main/timm/models Can you find the model you are using there? If so, you can use timm.

这个里面没有我使用的模型

Then you'll have to implement an op yourself.

Then you'll have to implement an op yourself.
具体要怎么实现呢，可以具体说一下吗

Then you'll have to implement an op yourself.
具体要怎么实现呢，可以具体说一下吗

https://towhee.readthedocs.io/en/latest/operator/usage.html#run-pipeline-with-named-operators

@junjiejiangjjj
I found that there is ConvNeXt-V2 in timm, but I use https://github.com/open-mmlab/mmpretrain or https://github.com/facebookresearch/ConvNeXt-V2 for training. You can directly use timm to load this Is it a model trained by two warehouses?

@junjiejiangjjj I found that there is ConvNeXt-V2 in timm, but I use https://github.com/open-mmlab/mmpretrain or https://github.com/facebookresearch/ConvNeXt-V2 for training. You can directly use timm to load this Is it a model trained by two warehouses?

You can use checkpoint_path param to load your weights: ops.image_embedding.timm(model_name='resnet50', checkpoint_path="your weights file path")

@junjiejiangjjj

Why does the result graph when I run the same code look like this?
https://github.com/towhee-io/examples/blob/afbd207d9e65798d913b8f4eff8ba355000ada84/image/reverse_image_search/1_build_image_search_engine.ipynb

This op decodes the image in bgr format by default, so the displayed image color is incorrect. Use ops.image_decode.cv2('rgb') to display it normally.

@junjiejiangjjj Thank you for your prompt reply!


this.get('firebaseUtil') is returning undefined on 1.5.0

it works fine on 1.3, it doesn't seem to work on with 1.5
emberfire version: 2.0.7

@Ghostavio, make sure to inject the service. I removed the part where the service was injected automatically for explicitness.

Oh, ok, maybe that should be updated in the readme 😛

aaaand it already is, my bad!

Simply inject the firebase-util service.


Initial draft of AppLocal Deployment spec.

A few topics in need of feedback:

What is the preferred terminology: AppLocal, Self-Contained, In-App?
How does Windows App SDK AppLocal relate to .NET Self-Contained deployments?

Should we align on terminology?
Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property? If developers want to take a framework package dependency on .NET but an AppLocal dependency on the Windows App SDK or vice versa, we should keep these separate.

Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios?

We plan to deliver a preview of this in an upcoming 1.0 Preview release.

Hey @mikebattista is there an existing issue thread where we can provide feedback?
https://github.com/microsoft/WindowsAppSDK/tree/main/specs#authoring-an-api-spec

Hey @mikebattista is there an existing issue thread where we can provide feedback?
https://github.com/microsoft/WindowsAppSDK/tree/main/specs#authoring-an-api-spec

Please provide comments in the spec in the PR or here in the PR discussion. I'd prefer comments in the spec.

Will do. @jonwis I'm concerned the community is expecting the documented process to be followed and will miss review of this.

The linked process is for API design reviews which this is not. Though if filing an issue to "Support AppLocal Deployment of the Windows App SDK" will make it easier to get feedback, then I'm happy to do that.

Some initial feedback:
Q: What is the preferred terminology: AppLocal, Self-Contained, In-App?
A: I prefer Self-Contained however this should only be used if it is 100% consistent with the .NET publish --self-contained flag (see https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish) both in usage (ie using the --self-contained flag in the publish command) and outcome (ie packages the .net runtime). On the assumption that this is not the case I think In-App makes more sense. AppLocal is meaningless, please don't use this.
How does Windows App SDK AppLocal relate to .NET Self-Contained deployments?
Q: Should we align on terminology?
A: See previous answer - only if 100% consistent
Q: Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property? If developers want to take a framework package dependency on .NET but an AppLocal dependency on the Windows App SDK or vice versa, we should keep these separate.
A: The two should probably be kept separate - I can't think of why a developer would want to take a dependency on one and not the other but why not leave this option open, since there are countless different deployment requirements for different developers.
Q: Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios?
A: Yes, (unless I'm missing something) this completely negates the whole point of In-App deployment of the SDK. The goal should be xcopy deployment of apps - no installation of any component. The exception to this is where there needs to be some registration for say Identity, which should be done when app is executed (and needs corresponding Windows clean up task, for example if the app is deleted, moved etc).

Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages

The Main+Singleton packages depend on the Framework package. For Main+Singleton to work Framework must also be installed i.e. you need it all.
Applications using WinAppSDK via AppLocal don't (directly) need the MSIX packages
Main+Singleton MSIX packages always need the Framework package.
If AppLocal requires redist+install the Main+Singleton MSIX packages then ditto the Framework package.
Does that change the AppLocal equation?

Some initial feedback:
Q: What is the preferred terminology: AppLocal, Self-Contained, In-App?
A: I prefer Self-Contained however this should only be used if it is 100% consistent with the .NET publish --self-contained flag (see https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-publish) both in usage (ie using the --self-contained flag in the publish command) and outcome (ie packages the .net runtime). On the assumption that this is not the case I think In-App makes more sense. AppLocal is meaningless, please don't use this.

Agreed on only using Self-Contained if it meets the same definition as .NET. I don't think it does currently given the state of the MSIX packages that need to be redist. AppLocal has precedent, too, I know from CRT at least, but I'm not attached to any option.

Q: Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property? If developers want to take a framework package dependency on .NET but an AppLocal dependency on the Windows App SDK or vice versa, we should keep these separate.
A: The two should probably be kept separate - I can't think of why a developer would want to take a dependency on one and not the other but why not leave this option open, since there are countless different deployment requirements for different developers.

My feeling too is that these should be kept separate.

Q: Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios?
A: Yes, (unless I'm missing something) this completely negates the whole point of In-App deployment of the SDK. The goal should be xcopy deployment of apps - no installation of any component. The exception to this is where there needs to be some registration for say Identity, which should be done when app is executed (and needs corresponding Windows clean up task, for example if the app is deleted, moved etc).

If AppLocal requires redist+install the Main+Singleton MSIX packages then ditto the Framework package.
Does that change the AppLocal equation?

I share the concerns here. One of the fundamental questions of this review is if the current design of those packages and the dependencies that Windows App SDK components are taking on them means that we can't truly support AppLocal/Self-Contained/In-App deployment unless we revisit those designs.

What is the preferred terminology: AppLocal, Self-Contained, In-App?
In no order, I'd go with perhaps self-contained, xcopy, or portable.

How does Windows App SDK AppLocal relate to .NET Self-Contained deployments?
.. Should we align on terminology?
It shouldn't, in any way. Not all consumers of the WAS are participants of the .NET ecosystem (e.g. C++, Rust). And I don't see any connections.

.. Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property? If developers want to take a framework package dependency on .NET but an AppLocal dependency on the Windows App SDK or vice versa, we should keep these separate.
Separate, again for folks not using .NET. And all of this should work without msbuild (e.g. Rust).

.. Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios?
Problem? No. Silly and kind of undermines the entire point of an xcopy deployment? Yes. 😆 But hey it's better than nothing so please don't scrap anything.

Q: What is the preferred terminology: AppLocal, Self-Contained, In-App?
A: I prefer self-contained if it works like .NET self-contained
Q: Should we keep the msbuild property separate or piggyback on the existing .NET Self-Contained property?
A: I'd always use them together but can see good reasons for making them distinct options.
Q: Are the requirements to redist and install the Windows App SDK Main and Singleton MSIX packages a problem for AppLocal scenarios?
A: My enterprise customers generally dislike MSIX and like the convenience of xcopy deployment. Anything requiring a separate installation is challenging for them for various reasons.

I would avoid SelfContained, precisely because it also applies to the .NET deployment option.  What happens if/when we introduce a .NET runtime framework package, and .NET SelfContained becomes an option (vs framework-dependent)?  How will we disambiguate SelfContained-WindowsAppSDK from SelfContained-DotNet apps?  I would assume devs would want to mix and match these options.  So this seems like a recipe for confusion - I'd stick with AppLocal.
I assume "multiple instances" means "multiple versions".  Doesn't FrameworkPackage deployment also imply that multiple versions of binaries can be running simultaneously?
There are parallel discussions on how to address other shared dependencies, like the .NET 5 runtime, the C Runtime, and C#/WinRT projection assemblies.  As with "self-contained", these may overlap with the term "component binaries", so I'd just call these out as Windows App SDK binaries.
Can we define some of the new terminology, like WARMain?  We should also not use the abbreviation WAR, as we no longer use the term WindowsAppRuntime/WinAppRuntime.  The MSIXPackages spec needs to be updated.

We should also not use the abbreviation WAR, as we no longer use the term WindowsAppRuntime/WinAppRuntime

That is the correct term. The project is WindowsAppSDK but the runtime artifacts are WindowsAppRuntime. That includes the MSIX package identities and the DLLs (e.g. Microsoft.WindowsAppRuntime.dll). We haven't renamed these yet (I'm working on it).

Can we define some of the new terminology, like WARMain?

Like this? ;-)
We generally don't use the WAR... terms, except when we're repeatedly referencing multiple MSIX packages (where using the full names would degrade comprehension). specs/Deployment/MSIXPackageVersioning.md is the only place I'm aware of that we do.
And occasionally in informal conversation, for same reason. WinAppSDK Framework is a mouthful, plus "WinAppSDK Main" can get confusing as WinAppSDK Main, WinAppSDK Singleton and WinAppSDK DDLM are all MSIX main packages (as in, PackageType=Main).
WARmain is just the modern lingo for what used to be informally referred to as PRmain (ditto PRfwk->WARfwk and PRddlm->WARddlm).
P.S. I did find a few references to the PR... terms across the codebase when I did the mass ProjectReunion->WindowsAppSDK rename. Tried to not just rename but also use the formal terms e.g. PRfwk -> Windows App SDK Framework, or WinAppSDK Framework.

Doesn't FrameworkPackage deployment also imply that multiple versions of binaries can be running simultaneously?

Yes. Let's say (hypothetical example) Outlook uses the Foo framework package. I have Outlook running 24x7x365 on my machine, so it's running with foo v<IP_ADDRESS>. While it's running I install Foo framework v<IP_ADDRESS>. We install, say, Calculator and Foo v<IP_ADDRESS>. We add v<IP_ADDRESS> to the machine but don't disturb Outlook, who continues running using v<IP_ADDRESS>. I now launch Calculator and it's merrily running using Foo v<IP_ADDRESS>...while the Outlook process is running using v<IP_ADDRESS>. Someday when Outlook quits we'll update the resolved dependency to the newer Foo framework so next time Outlook runs it'll use v<IP_ADDRESS>.
So yes, framework packages support concurrent usage. Newer versions aren't immediately applied to everything, just everything non-disruptive and we coalesce to the newer version over time. Framework packages are very handy, hence the reason we aspire to do as much as possible via framework packages.
Alas, Framework packages can't do everything. Framework package's appxmanifest.xml can't declare Applications, PackagedCOM, BackgroundTasks, AppExtensions, StartupTasks and more. If you need these you need you need a Main package. The WinAppSDK Main+Singleton+DDLM packages exist for this reason - to help us do things we can't do via a framework package.
Inproc code / DLLs, data files and more work quite well via framework packages. It's usually the exe / process / out-of-process stuff that you start bumping into framework package restrictions. That's why specs/Deployment/MSIXPackages.md has comments like

For these reasons Windows App SDK developers are strongly encouraged to only rely on the Main package when necessary.

specs/Deployment/MSIXPackages.md goes into this subject in more detail.

To complement @DrusTheAxe explanation, a main package is required to lift system services out of the OS and into store updatable packages so the WinAppSDK can rev more quickly than the OS. The spec mentions PushNotifications as an example of such a singleton.
In v1.0 we have a chicken and egg challenge of getting these new main packages onto devices, and are working to solve that problem - easier done in newer versions of Windows, more challenging to get it downlevel. Until then, that means the only way to guarantee an app has all its dependencies, is for the app to register the main packages. In this scenario the application is running against an applocal copy of the framework, and thus the framework version it uses is not impacted by store updates to the shared framework. The main packages themselves will require the shared framework to be installed.
Do you feel this puts too much of a burden on xcopy/applocal deployments? Or do you think apps will avoid using such features so they can avoid registering the main packages (which would be an unsupported scenario)?

Until then, that means the only way to guarantee an app has all its dependencies, is for the app to register the main packages. In this scenario the application is running against an applocal copy of the framework, and thus the framework version it uses is not impacted by store updates to the shared framework.

Hm? I'm not aware of a difference between installs originating from the app vs. the user executing the runtimes installer. Why would these packages, once installed, be unservicable? Or are you referring to some sort of unsupported xcopy-everything deployment?

Until then, that means the only way to guarantee an app has all its dependencies, is for the app to register the main packages. In this scenario the application is running against an applocal copy of the framework, and thus the framework version it uses is not impacted by store updates to the shared framework.

Hm? I'm not aware of a difference between installs originating from the app vs. the user executing the runtimes installer. Why would these packages, once installed, be unservicable? Or are you referring to some sort of unsupported xcopy-everything deployment?

In addition to this, would there be a difference between per-user vs. per-machine installations as far as package registration is concerned? Multiple users per machine is not uncommon for my customers, but they only want to install once.

Until then, that means the only way to guarantee an app has all its dependencies, is for the app to register the main packages. In this scenario the application is running against an applocal copy of the framework, and thus the framework version it uses is not impacted by store updates to the shared framework.

Hm? I'm not aware of a difference between installs originating from the app vs. the user executing the runtimes installer. Why would these packages, once installed, be unservicable? Or are you referring to some sort of unsupported xcopy-everything deployment?

In context of an app choosing to use applocal - the main and the shared framework packages would be serviceable by the store. regardless of installation mechanism (app registers the msix packages directly or the app/user runs the runtimes installer). The applocal copy of the framework would not be serviced by the store, that would require the app to ship an update.

The applocal copy of the framework would not be serviced by the store, that would require the app to ship an update.

I wasn't aware this even worked. You're saying I can stuff all the files from those WAS packages into my app and xcopy deploy the resultant mess to another machine? And the app will actually launch?

The applocal copy of the framework would not be serviced by the store, that would require the app to ship an update.

I wasn't aware this even worked. You're saying I can stuff all the files from those WAS packages into my app and xcopy deploy the resultant folder to another machine? And the app will actually launch?

That's what this spec is proposing. I may be getting into implementation details here, but imagine:

In a packaged app with applocal - the framework package binaries would be copied similar to .net publish 'self contained' and tooling would write the winrt ACID registrations to the app's package manifest. The app would need to ensure the main+shared framework packages are installed for all apis to work correctly. The main package will still depend on the shared framework package.
In an unpackaged app with applocal - the framework package binaries would be copied similar to .net publish 'self contained' and tooling would write the winrt ACID registrations to the app's sxs/fusion manifest (app.exe.manifest). The app would need to ensure the main+shared framework packages are installed for all apis to work correctly. The main package will still depend on the shared framework package. This type of app would not use dynamic dependencies.

The applocal copy of the framework would not be serviced by the store, that would require the app to ship an update.

I wasn't aware this even worked. You're saying I can stuff all the files from those WAS packages into my app and xcopy deploy the resultant folder to another machine? And the app will actually launch?

That's what this spec is proposing. I may be getting into implementation details here, but imagine:

In a packaged app with applocal - the framework package binaries would be copied similar to .net publish 'self contained' and tooling would write the winrt ACID registrations from the shared framework package to the app's package manifest. The app would need to ensure the main+shared framework packages are installed for all apis to work correctly. The main package will still depend on the shared framework package.
In an unpackaged app with applocal - the framework package binaries would be copied similar to .net publish 'self contained' and tooling would write the winrt ACID registrations from the shared framework package to the app's sxs/fusion manifest (.exe.manifest). The app would need to ensure the main+shared framework packages are installed for all apis to work correctly. The main package will still depend on the shared framework package. This type of app would not use dynamic dependencies.

This unpackaged applocal scenario would be what my larger enterprise users would want. They are already familiar with installing our apps published as .NET self-contained and really do xcopy them to multiple PCs after testing them instead of using our installer as I understand it.

@AdamBraden what's the latest on this?
I'm stunned that the team is considering an unpackaged applocal model that still requires main/shared framework package to be installed. Surely there must be a way that we can just bundle all the dependencies for the app, in the app itself and have it just work. It seem crazy that we've got this engineering masterpiece, that simply fails the simplest deployment strategy of all - simple xcopy deployment of the app.

@AdamBraden what's the latest on this?
I'm stunned that the team is considering an unpackaged applocal model that still requires main/shared framework package to be installed. Surely there must be a way that we can just bundle all the dependencies for the app, in the app itself and have it just work. It seem crazy that we've got this engineering masterpiece, that simply fails the simplest deployment strategy of all - simple xcopy deployment of the app.

@nickrandolph - we are aligning with the .NET term 'self-contained' , and we’ll behave the same way with all dependencies carried with the app to support xcopy deployments.
However there will be a small set of features that depend on a singleton. If managing these additional dependencies will compromise your xcopy deployments, then we recommend leveraging inbox features or lighting up the functionality at runtime when the dependencies are already available.
For example, push notifications will be one of the features that requires a singleton, since push notifications depends on having a single socket connection shared across all apps in order to improve battery and perf… otherwise, there would be no point in us shipping push notifications if each app carried WNS themselves and had their own socket connection always running to WNS server. They might as well have their own socket connection to their own server at that point (what apps do today).
This is a point in time as we are on the journey for the Windows App SDK, and we are working to minimize scenarios when these dependencies are not available, but it may take a little while for us to get there especially on downlevel machines.

However there will be a small set of features that depend on a singleton. If managing these additional dependencies will compromise your xcopy deployments [...]

Isn't it more accurate to say that there is no xcopy deployment? That both packaged and unpackaged apps require the runtimes installed? You can't pick and choose with WAS at a granularity that suddenly makes xcopy work, so it doesn't really make sense to communicate that way.

WAS is just a decoupled component framework from windows which needs to be installed separately (because it's decoupled.)  the point of WAS is that (i)it can be developed independently without changing windows and (ii)support for some downlevel versions going 1809. that's all I understand.
IIUC, there were no such promise of XCOPY deployment to begin with. https://github.com/microsoft/WindowsAppSDK/issues/660#issuecomment-819260272. Unpackaged means that one uses anything other than MSIX

Unpackaged means that one uses anything other than MSIX

Correct - "unpackaged app" isn't synonymous with XCOPY-install, it just means "app not installed via MSIX".
This spec outlined thinking regarding 'app local' and the discussion is helping vet and refine that thinking. As 'oft said, community feedback is valued to help us better understand needs and desires, how we are/not best meeting those and helps us chart a path forward that balances the various requirements and constraints.
Where the conversation started is less important than where it goes, so thank you (and everyone else, on this thread and elsewhere) for participating in the discussion. It's a really huge and varied ecosystem so the more voices and viewpoints shared the stronger our solutions can be :-)

Supporting xcopy deployment is a primary goal here. Self-contained and xcopy deployment go hand in hand.
Notifications is one feature that requires some additional dependencies, and we'd recommend either avoiding features like that if they would compromise your self-contained/xcopy deployments, or light up the functionality only if the runtime is already available. We don't expect features requiring these additional dependencies to be the common case, and we actively discourage the approach unless the features wouldn't be meaningful without it.

However there will be a small set of features that depend on a singleton. If managing these additional dependencies will compromise your xcopy deployments [...]

Isn't it more accurate to say that there is no xcopy deployment? That both packaged and unpackaged apps require the runtimes installed? You can't pick and choose with WAS at a granularity that suddenly makes xcopy work, so it doesn't really make sense to communicate that way.

Are you referring to the fact that the App SDK is basically one umbrella reference vs. a la carte references to specific features? Our goal is that if you don't use a feature that requires the additional runtime dependencies, then you don't need to worry about those dependencies, regardless of your references, and we would document which features require those additional dependencies. That list should be small.

the roadmap lists LITERALLY every single WAS features to be made available for non-MSIX apps !
why would anyone want to go the trouble of MSIX at this point when every single features are being made available for non MSIX ?
make the only Clean Install-Uninstall advantage of MSIX part of OS and maybe we can forget about Packaged | Unpackaged thing ?!

Closing out as this feature has shipped and is publicly documented at https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/deploy-overview.


[NO MRG] Test pre-commit.ci

Testing out pre-commit.ci support following PR ( https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/568 )

Checklist

[ ] Used a static YAML file for the patch if possible (instructions).
[ ] Only wrote code directly into generate_patch_json.py if absolutely necessary.
[ ] Ran pre-commit run -a and ensured all files pass the linting checks.
[ ] Ran python show_diff.py and posted the output as part of the PR.
[ ] Modifications won't affect packages built in the future.

<!-- Put any other comments or information here --!>

pre-commit.ci autofix

From the CI service as expected
push (skipped)
push permission was denied -- perhaps the pr was made from an organization?

Closing. Will continue in PR: https://github.com/conda-forge/conda-forge-repodata-patches-feedstock/pull/574


base recurrent fix - treat

Updated the concentrator branch with the 'inference_input_size' fix #536 in MAIN.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.Willa Potosnak seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Better generators and scaffolding

Refactor empty project generation
Expose API for project generation
Provide framework for rails-like generators
Add restia CLI generator command
Add example scaffold with local generators

Probably easiest: generator == module
Implement scaffold projects as regular generators? 🤔

Mostly implemented with a6f949dbe82d83917c2f5f2990e043d67e43073b (easier than expected)


Spelling mistake in README.md

There is a spelling mistake in it features part:
The origin content is:
It features:

SQL editors for Hive, Impala, MySQL, Oracle, PostGresl, SparkSQL, Solr SQL, Phoenix...
Dynamic Search dashboards with Solr
Spark and Hadoop notebooks
Scheduling of jobs and workflows through an Oozie Editor and Dashboard

However,  PostGresl is not correct, the true name should be PostgreSQL that I found it on http://www.postgresql.org/

Thanks!


Fixed path for weex-vue-render

When you run npm run serve the webpage doesn't render anything because it can't find the weex-vue-render module. In this pull request I corrected the file path, so it does work.

Run into the same problem, too.

@vblinden  Thanks a lot.💐

why the weex does not fix this small bug,it made me confused for a long time

@joiman I am not a contributor and can't tag a release. @JackPu can you tag a new release, so that beginners don't have an error when they just start out?

@Tancy  Can you merge it and release a new version ?

Yes


compilation fail Tier 1 x86_64-apple-darwin ,error: linking with cc failed: exit status: 1

Problem
Most of the infos is stated in https://github.com/cross-rs/cross/issues/1144
The problem is faced when i try to build a build app from other repo using github actions that internally uses cargo.
Steps
git clone https://github.com/devdailytester/testgithubci
cross build --release -v --target=x86_64-apple-darwin
Possible Solution(s)
No response
Notes
i suspect cargo doesnt fully support thr cross compilation from ubuntu unix to macos?
If can confirm its the case then I will make my action compile natively with a macos setup if possible.
Version
No response

Copying from https://github.com/rust-lang/cargo/issues/10873#issuecomment-1186244653:

This isn't something that can be addressed through an issue on the Cargo repository, and is likely to be a very large task that would require a large investment. It would likely require putting together a working group, or some other coordinated group of people.

If you have access to GitHub Action, I'd recommend setting up native macOS to make life easier.
Going to close this as it is not a thing we can track here. Thank you!


Update Shop class

Codecov Report
Patch coverage has no change and project coverage change: -5.88 :warning:

Comparison is base (11b0ee0) 53.64% compared to head (4aa061b) 47.77%.

Additional details and impacted files
@@             Coverage Diff              @@
##             master      #42      +/-   ##
============================================
- Coverage     53.64%   47.77%   -5.88%
  Complexity      403      403
============================================
  Files            89       96       +7
  Lines          1700     1909     +209
  Branches        143      182      +39
============================================
  Hits            912      912
- Misses          755      964     +209
  Partials         33       33

Impacted Files
Coverage Δ

...va/seedu/address/model/entity/person/Customer.java
0.00% <0.00%> (ø)

.../java/seedu/address/model/entity/person/Staff.java
0.00% <0.00%> (ø)

.../seedu/address/model/entity/person/Technician.java
0.00% <ø> (ø)

...ddress/model/entity/person/UniqueCustomerList.java
0.00% <0.00%> (ø)

...ress/model/entity/person/UniqueTechnicianList.java
0.00% <0.00%> (ø)

...ain/java/seedu/address/model/entity/shop/Shop.java
0.00% <0.00%> (ø)

...seedu/address/model/entity/shop/garage/Garage.java
0.00% <ø> (ø)

...va/seedu/address/model/entity/shop/garage/Lot.java
0.00% <ø> (ø)

...main/java/seedu/address/model/service/Service.java
0.00% <0.00%> (ø)

.../java/seedu/address/model/service/ServiceList.java
0.00% <0.00%> (ø)

... and 6 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Support for standard in RTCPeerConnection.addIceCandidate

Similar to https://github.com/oney/react-native-webrtc/pull/524 it probably makes sense to support null | undefined | RTCIceCandidateInit dictionary in RTCPeerConnection.addIceCandidate as some libraries are not passing RTCIceCandidate but rather RTCIceCandidateInit structure as a parameter value
Expected behavior
pc.addIceCandidate(null) or pc.addIceCandidate({ candidate, sdpMid, sdpMLineIndex }) with correct values should result into resolved promise
Observed behavior
rejected promise due to undefined candidate or candidate.toJSON in https://github.com/oney/react-native-webrtc/blob/5ea877734facf0857febe673f6cddfc6b0c3f9ec/RTCPeerConnection.js#L189
Steps to reproduce the problem
pass null | undefined | object conforming to RTCIceCandidateInit structure (one without toJSON method)
Platform information
any

Plugin version:
1.69.0 and older

Also (this probably should be filed as a separate issue), at least in Android implementation  sdpMLineIndex can not be null while it's actually valid to have it as null along with sdpMid for end-of-candidates indication. This is due to the following call, which throws exception: https://github.com/oney/react-native-webrtc/blob/5ea877734facf0857febe673f6cddfc6b0c3f9ec/android/src/main/java/com/oney/WebRTCModule/WebRTCModule.java#L855

Sounds good.


C++ APIView does not appear to have a mechanism to show comments.

https://apiview.dev/Assemblies/Review/5b2efd771af642728e4796813564404b
C++ APIViews don't seem to have the ability to show comments. The comments appear to be in the cppast file, but they are not shown in the APIView:
|       |-CXXRecordDecl 0xa47c708 <line:32:3, line:62:3> line:32:9 referenced class AttestationType definition
|       | |-DefinitionData standard_layout has_user_declared_ctor can_const_default_init
|       | | |-DefaultConstructor
|       | | |-CopyConstructor simple non_trivial has_const_param needs_overload_resolution implicit_has_const_param
|       | | |-MoveConstructor exists simple non_trivial needs_overload_resolution
|       | | |-CopyAssignment simple non_trivial has_const_param needs_implicit implicit_has_const_param
|       | | |-MoveAssignment exists simple non_trivial needs_overload_resolution
|       | | -Destructor simple non_trivial needs_overload_resolution |       | |-public 'Azure::Core::_internal::ExtendableEnumeration<AttestationType>':'Azure::Core::_internal::ExtendableEnumeration<Azure::Security::Attestation::Models::AttestationType>' |       | |-FinalAttr 0xa47d378 <col:25> final |       | |-FullComment 0xb305e58 <line:28:5, line:31:3> |       | | |-ParagraphComment 0xb305d88 <line:28:5> |       | | | -TextComment 0xb305d68 col:5 Text=" "
|       | | |-BlockCommandComment 0xb305da0 <col:6, line:29:29> Name="brief"
|       | | | -ParagraphComment 0xb305df8 <line:28:12, line:29:29> |       | | |   |-TextComment 0xb305dc0 <line:28:12, col:91> Text=" The AttestationType type represent a Trusted Execution Environment supported by" |       | | |   -TextComment 0xb305dd8 <line:29:5, col:29> Text=" the attestation service."
|       | | -ParagraphComment 0xb305e30 <line:31:1, col:3> |       | |   -TextComment 0xb305e10 <col:1, col:3> Text="   "

@LarryOsterman is this still an issue?

No, closing.


Delete gitops workload cluster with controller

Issue #, if available:
Description of changes:
Testing (if applicable):
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


Twilio

Create a SaaS connector to Twilio's API.

Authentication: Basic auth
Requires pagination? yes

pageStructure:
  indexContainer: PAGE_DATA
  incrementalParam: Page
  nextPageLabel: PageToken
  pageDataFields:
    - name: next_page_uri

Needs pre/post-processing? no
Identity: email, number, verification_resource_sid, entity_identity

Requirements

We only have prod credentials, will need to create a new test account for connectors.


PS-44 Create single parcel endpoint

Created:

Get request, that return parcel by ID (later probably will be modified to get by trackingID)
Fictional repository (static)

Structured code
If there is no id in get method, then raises not found exception (404)


[Task]: SMR zurück erhalten

Task description
Guten Tag,
nach meinem Wallet Update sind meine via Staking erworbenen SMR alle verloren gegangen. Selbst häufiges suchen in der Wallet mit der Suchfunktion führt zu keinem Ergebnis. Auch der Versuch mit Stronghold Backup etwas zu erreichen ist gescheitert.
Bitte helfen Sie mir bei der Wiederherstellung.
Mit freundlichen Grüßen
Daniel Doerner

Thank you. I had the Shimmer App and followed the instructions. My SMR are still gone. Why is there no German support? For Amateurs the App is to complicated.

Thank you. I had the Shimmer App and followed the instructions. My SMR are still gone. Why is there no German support? For Amateurs the App is to complicated.

Github is not a support channel, if you need further support you can join our discord https://discord.iota.org/
About your rewards not showing up, it can be because you staked with addresses that have high indexes, which can take multiple searches to find, I suggest you keep pressing the search button until your rewards appear, please make sure you use the same mnemonic/stronghold/ledger you used to stake in the firefly iota app to be able to find your rewards 🙏🏼


Added WSL BART Calls for MATLAB

Can now work with BART inside WSL

Thank you for contributing to BART!


ci: add release for arm64, pg14, pg16

Have you tested this on your fork?

It can run successfully now.
To see https://github.com/silver-ymz/pgvecto.rs/actions/runs/6906504206/job/18791688511

https://github.com/all-contributors please add @silver-ymz for infra

@all-contributors please add @silver-ymz for infra


tmpop - Add block signatures to segment evidences

Expected behavior
The evidence of a Segment should be enough to allow a complete validation.
Actual behavior
The only missing piece are the signatures of the validator nodes on the block.

the pre-commits of a block, containing the validators public keys and signatures, are not currently available in the ABCI (only the LastCommitHash contained in the header passed to BeginBlock is). A discussion is taking place on tendermint's forum (https://cosmos.rocket.chat/channel/development?msg=pQByczFAAAQZsRtDY).

I was thinking that maybe we should not store anything like the block header and the block pre commit signatures since they are already store by Tendermint Core. We could only store the block height and enrich segments in tmstore with the header and the signatures when they are requested.
What do you think?

I thought the goal of an evidence was to make it possible to verify the validity of a segment independently from the tendermint network. However, without an access to the blockchain, there is no way of telling if the evidence was made up or not, so you have a good point. Technically, the block height is not even needed to recover the block in which a segment was included though, why do we need it for ?

What I meant was:
If we know the block height then anytime a segment is retrieved all proofs we're interested in to independently validate it was included in the blockchain can be added to it.

In the case where a segment is saved on two distinct tendermint blockchains, it is only possible to give a full evidence if the originalProof (originalHeader, merkleProof, signatures, signedTrustedTimestamp) is provided for both blockchains right ? If we chose to enrich the segment at query-time, this is only possible if a node(=actor) is part of both networks, which will not be the case most of the time. What do you think ?

Therefore we have to decide between :

"light evidence" option : when saving a segment, only the block height is stored ; proof data (original header and merkle proof + current header and merkle proof + validators signatures for both blocks) will be added to the evidence when querying this segment. This option will cause a loss of performance for segment queries and some savings in terms of storage. To implement this, we have to wait till this is merged and released.

"full evidence" option : corresponds to what is currently implemented, except that the validators signatures for the original header will be added when saving a segment. Current proof (signatures, header, merkle proof) will obviously still be added at query time. To implement this, we need to wait till evidence/voteInfo is passed to the ABCI through BeginBlock (currently on the roadmap, @ebuchman said it was coming soon

This will probably be addressed in stratumn/sdk#191

Tendermint recommends using their lite package that gets all the signature data and validates it.
We should investigate this (it requires updating our Tendermint version).


⚠ BeyondHD has degraded performance

In 4b099f2, BeyondHD ($BHD) experienced degraded performance:

HTTP code: 200
Response time: 2486 ms

Resolved: BeyondHD performance has improved in 9c9ec28.