text:
resource-locker-operator new version

New Submissions

[ ] Has you operator nested directory structure?
[ ] Have you selected the Project Community Operator Submissions in your PR on the right-hand menu bar?
[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?
[ ] Have you tested your Operator with all Custom Resource Definitions?
[ ] Have you tested your Operator in all supported installation modes?
[ ] Is your submission signed?

Updates to existing Operators

[x] Is your new CSV pointing to the previous version with the replaces property?
[x] Is your new CSV referenced in the appropriate channel defined in the package.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[x] Is your submission signed?

Your submission should not

[x] Modify more than one operator
[x] Modify an Operator you don't own
[x] Rename an operator - please remove and add with a different name instead
[x] Submit operators to both upstream-community-operators and community-operators at once
[x] Modify any files outside the above mentioned folders
[x] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[x] Description about the managed Application and where to find more information
[x] Features and capabilities of your Operator and how to use it
[x] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[x] Human readable name and 1-liner description about your Operator
[x] Valid category name1
[x] One of the pre-defined capability levels2
[x] Links to the maintainer, source code and documentation
[x] Example templates for all Custom Resource Definitions intended to be used
[x] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file a PR against this repo and explain your need
2 For more information see here

@mvalahtv should be fixed now.

/lgtm

@mvalahtv @aneeshkp one of you asked me to modify that file the other is asking me to not modify that file....which one is correct?

authors: aneeshkp raffaelespazzoli

repo: operator-framework/community-operators


text:
patching catalogsource pod image registry prefix using mutating webhook causing the pod to terminating and restart

Bug Report

What did you do?
trying to patch catalog source pod image registry prefix to point to different one than what's defined in catalog source spec image filed, also patching pod imagePullSecrets to add a pull secret that has access to registry prefix, both are done using mutation webhook at pod creating time
What did you expect to see?
catalog source pod is able to pull image from patched registry prefix and pod is able to start
What did you see instead? Under which circumstances?
though pod is patched with both registry prefix and imagePullSecrets, however, pod container is immediately killed soon after it's started, causing multiple copies of the pod flipping in an infinite loop of Terminating and ContainerCreating state:
  Normal  Created         <invalid>  kubelet            Created container registry-server
  Normal  Started         <invalid>  kubelet            Started container registry-server
  Normal  Killing         <invalid>  kubelet            Stopping container registry-server

NAME                             READY   STATUS              RESTARTS   AGE
nginx-operator-catalog-hbwhn   0/1     Terminating         0          1s
nginx-operator-catalog-hqckk   0/1     Terminating         0          2s
nginx-operator-catalog-mwfmg   0/1     Terminating         0          4s
nginx-operator-catalog-psn24   0/1     ContainerCreating   0          0s

please note that if registry prefix is coded in catalogsource spec image and only patch imagePullSecrets, it'd be working fine, we have a case to code generic registry prefix in catalogsource spec and override with environment specific one at runtime, and global pull prefix might not be available
Environment

operator-lifecycle-manager version:

OLM version: 0.19.0
git commit: 3a667ecc956dcaacf47eb748ec2f2882633fc150

Kubernetes version information:
v1.24.12+ceaf338
Kubernetes cluster kind:
openshift
Possible Solution

Additional context
catalog operator pod log:
time="2023-06-28T04:42:34Z" level=debug msg="syncing catsrc" id=HojpG source=nginx-operator-catalog
time="2023-06-28T04:42:34Z" level=debug msg="check registry server healthy: false" id=HojpG source=nginx-operator-catalog
time="2023-06-28T04:42:34Z" level=debug msg="ensuring registry server" id=HojpG source=nginx-operator-catalog
time="2023-06-28T04:42:35Z" level=debug msg="handling object deletion" name=nginx-operator-catalog-nqp44 namespace=default
time="2023-06-28T04:42:35Z" level=debug msg="handling object deletion" name=nginx-operator-catalog-wlhjw namespace=default
time="2023-06-28T04:42:36Z" level=debug msg="ensured registry server" id=HojpG source=nginx-operator-catalog
time="2023-06-28T04:42:36Z" level=debug msg="syncing catsrc" id=goLzt source=nginx-operator-catalog
time="2023-06-28T04:42:36Z" level=debug msg="check registry server healthy: false" id=goLzt source=nginx-operator-catalog
time="2023-06-28T04:42:36Z" level=debug msg="ensuring registry server" id=goLzt source=nginx-operator-catalog
time="2023-06-28T04:42:36Z" level=debug msg="syncing catalog source for annotation templates" catSrcName=nginx-operator-catalog catSrcNamespace=default id=zBVjZ
time="2023-06-28T04:42:36Z" level=debug msg="this catalog source is not participating in template replacement" catSrcName=nginx-operator-catalog catSrcNamespace=default id=zBVjZ
time="2023-06-28T04:42:36Z" level=debug msg="RemoveStatusConditions - request to remove status conditions did not result in any changes, so updates were not made" catSrcName=nginx-operator-catalog catSrcNamespace=default id=zBVjZ
time="2023-06-28T04:42:37Z" level=debug msg="handling object deletion" name=nginx-operator-catalog-km924 namespace=default
time="2023-06-28T04:42:37Z" level=debug msg="handling object deletion" name=nginx-operator-catalog-5bwb2 namespace=default
time="2023-06-28T04:42:37Z" level=debug msg="ensured registry server" id=goLzt source=nginx-operator-catalog
time="2023-06-28T04:42:37Z" level=error msg="UpdateStatus - error while setting CatalogSource status" error="Operation cannot be fulfilled on catalogsources.operators.coreos.com \"nginx-operator-catalog\": the object has been modified; please apply your changes to the latest version and try again" id=goLzt source=nginx-operator-catalog
E0628 04:42:37.232862       1 queueinformer_operator.go:290] sync {"update" "default/nginx-operator-catalog"} failed: Operation cannot be fulfilled on catalogsources.operators.coreos.com "nginx-operator-catalog": the object has been modified; please apply your changes to the latest version and try again

@shixuguang this is expected. The pods are owned by the CatalogSource CRs, so if you try to edit the pod, the catalog-operator reverts it back. So essentially you have the catalog-operator and the webhook fighting each other. The webhook goes and edits the pods, the catalog-operator reverts it back, and this cycle goes on infinitely.
It's the CatalogSource CR that needs to be patched.

@anik120 Why is CatalogSource managing pods directly instead of managing a deployment?
Many mutating webhooks modify pods. Its not reasonable to expect each one to understand CatalogSources and patch those instead.
Additionally, if server-side apply was used by the CatalogSource controller, I don't believe this issue would have happened.
This was just the result of production issues for us due to the pressure it was putting on kube-proxy.
I do think such behaviour is undesired and should be fixed, rather than requiring the rest of the Kubernetes ecosystem to work around olm's decision to manage pods directly (something that is generally discouraged).

source: gharchive/issue

license_type: permissive

license_source: bigquery


text:
.github/workflows: Separate out the e2e jobs into workflows

Update the .github/workflows/test-scripts.yml GH action workflow and
move all the jobs listed there into separate workflows. This allows us
to retest a single workflow at a time as a workaround to GH not allowing
you to retest individual jobs in a workflow.

Description of the change:
Motivation for the change:
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive

@exdx This is probably a good time to revisit how we're naming these workflow/jobs instead of that other PR I posted last week. I think removing the upstream-* prefix from anything is a step in the right direction - any opinion on naming conventions, besides that?

@exdx This is probably a good time to revisit how we're naming these workflow/jobs instead of that other PR I posted last week. I think removing the upstream-* prefix from anything is a step in the right direction - any opinion on naming conventions, besides that?

This looks great @timflannagan. The other thing I'd like to change is the duplicate name as I brought up in the prior PR, things like build/build and unit/unit -- could we have those under a test/* or ci/* action instead?

/hold cancel

/rerun-all

source: gharchive/pull-request

authors: exdx timflannagan


text:
.github/workflows: Remove the e2e-minikube GHA

Mirror the operator-registry setup and remove the e2e-minikube GHA
workflow. Running e2e tests on both kind and minikube clusters is likely
overkill with little value added with the latter given the setup time
compared to kind.
Signed-off-by: timflannagan timflannagan@gmail.com

Description of the change:
Motivation for the change:
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /doc
[ ] Commit messages sensible and descriptive

/retest

/retest

/rerun-all

/lgtm

/hold
I have concerns about removing this (it's a test of the local development scripts, which have different behaviors on minikube, not a test of the runtime components), discussing in kubernetes #olm-dev now.

/hold cancel

authors: benluddy estroz timflannagan


text:
acoustic don't ignore at anymore

TIny fix to use AT in acoustic (kwarg was ignored so far)

I mainly only replicated the TTI example setup.

Will try to make it nicer

No worries. Just add autotune to the signature as per my comment above, then we can merge this

An issue is left, something is buggy wit hautotuning with save=False

benchmark ignores AT for forward but standalone example doesn't
autotuning fails with save=True when not ignored as the sequntial is empty (my change)
autotuning runs the ful ltime axis with save=True once timestep count is removed

autotuning fails with save=True when not ignored as the sequntial is empty

I think I know why it's because of i.dim.is_Buffered

autotuning runs the ful ltime axis with save=True once timestep count is removed

Probably because we're attempting to replace t_size only instead of also time_size (or the other way around)

@mloubout I'll need this stuff next week, so I pushed a few improvements and rebased on master.
The only thing I don't understand is why you replaced kwargs with autotune=autotune in the acoustic example. I think we should match what we do in tti_example.
Once this is sorted out, and once both you and Travis are happy, we merge this. I recommend before next week.

I think we should match what we do in tti_example.

That is what's in it. Specially if we add dse/dle to the examples parseargs, the operators don't accept it as input due to devito/operator/arguments
Will finish this one today

Fixes and more tests added. As discussed offline with @mloubout , I'm gonna merge this if Travis gets green

Mering...

Merged.

authors: FabioLuporini mloubout

repo: opesci/devito

license: mit


text:
[network] auto-generate protos

Signed-off-by: Boris Glimcher Boris.Glimcher@emc.com

Why are you removing the v1?  Wouldn't this be the proper place for a common set of API definitions or is that now going to be the opinetcommon?  Shouldn't any of the defined api's that we have done in the network v1 be moved to the opinetcommon folder for now until we decide that they can be deleted, updated, depicated?

Why are you removing the v1? Wouldn't this be the proper place for a common set of API definitions or is that now going to be the opinetcommon?

Yes, https://github.com/opiproject/opi-api/tree/main/network/opinetcommon should be the new place for all common network APIs

Shouldn't any of the defined api's that we have done in the network v1 be moved to the opinetcommon folder for now until we decide that they can be deleted, updated, depicated?

I see only 1 proto file defined today https://github.com/opiproject/opi-api/blob/main/network/v1/oc_interfaces.proto
I can move to opinetcommon for example...

authors: glimchb sandersms

repo: opiproject/opi-api

license_source: github-api


text:
unbound: Add possibility to enter Access control and views

At the moment Access control conditions and views can only be added via „Custom options“. As „custom options“ will be removed please consider an alternative way for defining access controls and views, e.g
server:
#Access control for Internal IPv4/6
access-control-view: 192.168.100.0/24 lanview
access-control-view: xxxx:xxxx:xxxx:xxxx::/64 lanview
view:
name: "lanview"
local-zone: "xxxxxxxx" transparent
local-data: "xxxxxxxx A xxxxxxxxx"
Thanks

You can move this to plugins and I'll add it to unbound-plus

authors: BPtLNfxZWo mimugmail

repo: opnsense/core


text:
[RFE] Add acl url_regex to Proxy

UT1 blacklist provide an url file actually only domain is used.

The idea is good, but url_regex in squid seems to be to slow to match large sets of urls, that's why its not currently in there. It seems we need an external worker to facilitate those.

authors: AdSchellevis gitdevmod


text:
Services: Intrusion Detection: Administration - Alerts: reload grid after log drop

Hi!
tested https://github.com/opnsense/core/commit/92e5536ca039ed558b5027077ed2e71a04230598 and it works great, thanks!
sorry, I did not mention one more in pr  - the alerts grid is not updated after log drop.
Thanks!

@kulikov-a I missed that one in your commit, thanks for opening a new one!

@AdSchellevis thanks!)

authors: AdSchellevis kulikov-a


text:
net/frr: BGP Diagnostics Summary tab not working

When you click this tab, you get no information, even though you should. The back-end runs the following vtysh command via quagga.rb, which, when I run this, I get output:
# vtysh -c show ip bgp

I've done some investigation, and it seems that frr recently added an additional header line for 'Nexthop codes', which is throwing off the parsing in plugins/net/frr/src/opnsense/scripts/quagga/quagga.rb
I will be submitting a PR shortly to address the defect, as well as hopefully make future defects less likely.
A potentially superior fix for this would be to leverage the json option in vtysh so that parsing isn't really necessary. However, I also noticed that frr has merged changes to the output of the JSON for the next major version, link here, and is deprecating some of the existing keys. This makes the JSON option problematic, at least for the time being.

Isnt this already fixed by yourself?

Isnt this already fixed by yourself?

Yes, it is. I created this issue at the same time that I submitted the PR, so that there would be appropriate tracking of the issue and its solution. I'll close it

authors: ggoodrich-ipp mimugmail

repo: opnsense/plugins


text:
feat: add browser history

Summary of changes

add buttons to navigate back and forth through resource browser history
enable navigation via keyboard shortcuts
enable/disable path bar buttons and show appropriate tooltips instead of hiding them completely
add tooltip delay to icon buttons to make them feel less jumpy

Context and reason for change
Closes #2299.
How can the changes be tested
Use mouse and keyboard to navigate through the browser history. Pay special attention to edge cases such as being at the beginning at the beginning or end of the history stack.

Right now, undo could jump to a resource which is not shown in the resource browser. If that happens, it's very hard to find your place. Imo that doesn't need to be fixed in this PR.

Sorry, I'm not understanding this comment. What do you mean by "undo"? Do you mean "go back"? And how can I reproduce what you're saying here: in particular, how can it be that there is a resource that's not part of the resource browser? Do you mean part of the viewport (in case of long lists of resources)?

Right now, undo could jump to a resource which is not shown in the resource browser. If that happens, it's very hard to find your place. Imo that doesn't need to be fixed in this PR.

Sorry, I'm not understanding this comment. What do you mean by "undo"? Do you mean "go back"? And how can I reproduce what you're saying here: in particular, how can it be that there is a resource that's not part of the resource browser? Do you mean part of the viewport (in case of long lists of resources)?

@MarkusObendrauf I think you've discovered a very valid point and I think I created a fix now. Please try again. :)

There are a couple of strange things regarding collapsing folders:

If you select a resource in a folder, and then collapse that folder, the resource browser scrolls to the top of the screen.
It's quite difficult to find a resource contained in a collapsed folder. Imo, navigating in history or clicking a breadcrumb should expand the resource tree so that the current resource is shown.

Both issues should be fixed now. Please check again.

repo: opossum-tool/OpossumUI


text:
passing variable to windows_task resource

Hi everyone,
I'm hoping someone can help me.
I have a scheduled task that will run every 15 minutes and delete files that are older than 2 minutes.
This is the code I use:-
 pass_day = "Z:\\s3_temp\\#{Time.now.strftime("%Y-%m-%d")}"
    windows_task 'deletion-of-logs-every-fifteen-minutes' do
      user 'Administrator'
      cwd pass_day
      command "powershell.exe Get-ChildItem  #{passday} | Where-Object {$_.LastwriteTime -lt     (Get-Date).addMinutes(-2) } | Remove-Item -Recurse -Force"
      run_level :highest
      frequency :minute
      frequency_modifier 15
      force true
      action :create
end

However when this runs, it doesn't complete successfully (i.e. the files in Z:\s3_temp\2015-08-10) do not get deleted.
How would I do this to pass the variable pass_day into this resource as pass_day will change every day?
Many thanks

Does the task complete successful but the files aren't deleted? Or does the task error? If the task errors, what is the error?
I noticed that you don't have a password specified. I think you need that to use a non-system account.

Hi,
The task does not complete successfully (the status of it is not equal to 0) and obviously the files aren't deleted.
I'm trying to delete files that are locked by a process for a short period and then released. What I find interesting is that I'm able to delete these files on the command line, after they have been released, but can't from within a script using the windows_cookbook resource.
Because the file is publicly viewable (i.e. in a git repo), I would be unable to include the plaintext password as part of the resource, (although I realise that it could be encrypted).
Does the syntax look right to you?

What is the task error? In task scheduler, the "Last Run Result" should have an error. Have you inspected the task in the task scheduler after it was created to verify all the commands and triggers are correct?
I wouldn't expect you to post the actual password. Something like password 'mypassowordgoeshere' is enough to let us know that you are using a password in your resource.
The syntax looks correct except for the use of pass_day and passday. I assume you want an underscore in the second one.

@trekr5 It sounds more like a schedule task/powershell command issue, have you written a schedule task that works? Does the schedule task manage to call the powershell.exe? What does the correctly configured Schedule Task look like?
We tend to build everything manually first then automate that, however a backslash is a metacharacter for both Ruby and Powershell so we always end up doubling the number backslashes!

Its also worth hopping onto the node and looking at the scheduled task that was created. In particular look at the command text and make sure it is formed as you expected. From there, definitely follow @chrisgit 's guidance and run the command to troubleshoot where things are wrong.

I'm closing here since this is likely not a problem in the cookbook.

repo: opscode-cookbooks/windows


text:
🛑 API Server is down

In 6a50fa1, API Server (https://api.optbp.com/hangfire) was down:

HTTP code: 0
Response time: 0 ms

Resolved: API Server is back up in 89494d9.

repo: optbp-monitor/optbp-monitor

license: MIT


text:
(#11767) New workshop from DBA Essentials - install database 23ai

Hello,
We have developed a new workshop - Install Oracle Database 23ai on OCI Compute, WMS ID is #11767.
Oracle Database 23ai (23.6) GA was Oct 15, Tue. Therefore, to compliment the database release, we would like to publish our workshops from the DBA Essentials series for 23ai. Would be great if you approve this PR please so that we could proceed with publishing to production on priority. Remaining workshops from the series would follow suit and we intend to publish them all in the next 2 weeks.
Thanks a lot for your help and support.
~MG

@manish-garodia please resolve the branch out-of-date issue

Have updated the inde.html file with the latest. The note looks ok as we are using building-blocks in the workshop.

thank you!

authors: klazarz manish-garodia

repo: oracle-livelabs/database


text:
Repeating DataSourceDefinition annotations are not detected by Weld

In the helidon-integrations-cdi-datasource-hikaricp Maven project, the Hikari connection pool extension is set up to look for @DataSourceDefinition annotations.  This is a repeating annotation.  The extension properly considers this fact, but the @WithAnnotations qualifier does not contain the "container" annotation, @DataSourceDefinitions.  Even though this annotation does not appear in a user-visible way in most cases, if it is not added to this @WithAnnotations qualifier, the synthesized @DataSourceDefinitions annotation that is created at compile time by the JDK is never seen, and the relevant ProcessAnnotatedType event is not observed.
The net effect is if you have more than one @DataSourceDefinition annotation applied to a class, everything will behave as if you had none.
PR coming shortly.

This issue tangentially relates to #2502.

repo: oracle/helidon


text:
Make okafka available in the Mvn repo

Make okafka available in the Mvn repo

[x] generate jar
[x] generate documentation
[x] submit artifacts to repo mvn centrl

Published:
❯ mvn clean package -DskipTests
[INFO] Scanning for projects...
[INFO]
[INFO] -------------< org.oracle.okafka.samples:okafka-producer >--------------
[INFO] Building okafka-producer 1.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
Downloading from central: https://repo.maven.apache.org/maven2/com/oracle/database/messaging/okafka/0.8/okafka-0.8.pom
Downloaded from central: https://repo.maven.apache.org/maven2/com/oracle/database/messaging/okafka/0.8/okafka-0.8.pom (0 B at 0 B/s)
Downloading from central: https://repo.maven.apache.org/maven2/com/oracle/database/messaging/okafka/0.8/okafka-0.8.jar
Downloaded from central: https://repo.maven.apache.org/maven2/com/oracle/database/messaging/okafka/0.8/okafka-0.8.jar (0 B at 0 B/s)
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ okafka-producer ---
[INFO] Deleting /Users/pasimoes/Work/Oracle/Code/okafka-samples/okafka-producer/target
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ okafka-producer ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources

https://repo.maven.apache.org/maven2/com/oracle/database/messaging/okafka/0.8/okafka-0.8.pom

repo: oracle/microservices-datadriven


text:
How do we unpack a DimensionTuple?

Ask the question
I'm trying to unpack the prediction results after calling model.predict(data), I get a ArrayList of Prediction items.
Each Prediction item in my case is of type Regressor.DimensionTuple, there is a getOutput() method  and a getValues() on it but neither give me the prediction value (numeric). It seems there isn't an easy method/API to get this out.
When I call this xgbModel.predict(data).get(0).getOutput(), I get this (DIM-0,5.982707500457764)
When I call this xgbModel.predict(data).get(0).getOutput().getValues(), I get this [D@6b788c95, the getDimensionNamesString() works but not the one to get the value corresponding to it.
What am I not doing? This I believe is an important function. I have been looking at the docs at  https://tribuo.org/learn/4.0/javadoc/org/tribuo/regression/Regressor.DimensionTuple.html
Is your question about a specific Tribuo class?
Class Regressor.DimensionTuple,
Additional context
Using the prediciton results to do further analysis.

xgbModel.predict(data).get(0).getOutput().getValues() returns the array of regressed outputs from that prediction. As it's a single dimensional regression then there is only one element and so xgbModel.predict(data).get(0).getOutput().getValues()[0] is the regressed value.

xgbModel.predict(data).get(0).getOutput().getValues() returns the array of regressed outputs from that prediction. As it's a single dimensional regression then there is only one element and so xgbModel.predict(data).get(0).getOutput().getValues()[0] is the regressed value.

We could add a public DimensionTuple get(int idx) method to Regressor which would return the single dimension requested, and then you could call getValue() on that if you wanted, but it's about the same.

We could add a public DimensionTuple get(int idx) method to Regressor which would return the single dimension requested, and then you could call getValue() on that if you wanted, but it's about the same.

We could add a public DimensionTuple get(int idx) method to Regressor which would return the single dimension requested, and then you could call getValue() on that if you wanted, but it's about the same.

Yes that would be good to have, and a bit more intuitive as well.

We could add a public DimensionTuple get(int idx) method to Regressor which would return the single dimension requested, and then you could call getValue() on that if you wanted, but it's about the same.

Yes that would be good to have, and a bit more intuitive as well.

xgbModel.predict(data).get(0).getOutput().getValues() returns the array of regressed outputs from that prediction. As in your case it's a single dimensional regression then there is only one element and so xgbModel.predict(data).get(0).getOutput().getValues()[0] is the regressed value.

Thanks for this

xgbModel.predict(data).get(0).getOutput().getValues() returns the array of regressed outputs from that prediction. As in your case it's a single dimensional regression then there is only one element and so xgbModel.predict(data).get(0).getOutput().getValues()[0] is the regressed value.

Thanks for this

We could add a public DimensionTuple get(int idx) method to Regressor which would return the single dimension requested, and then you could call getValue() on that if you wanted, but it's about the same.

Yes that would be good to have, and a bit more intuitive as well.
Would also be good to show this in the notebooks, so it becomes obvious how to get the values out, its a bit of nested calls before we can get to the value(s). Maybe I'll do a pull request.

Well it's only the getValues() and then indexing the regressed value that's different from accessing any other predicted output. But I'll expand the javadoc a little and add the extra accessor.
The regression tutorial should have a note about how the multidimensional nature affects the regression objects, I thought that was in there but it's probably elsewhere in the docs.

We could add a public DimensionTuple get(int idx) method to Regressor which would return the single dimension requested, and then you could call getValue() on that if you wanted, but it's about the same.

Yes that would be good to have, and a bit more intuitive as well.
Would also be good to show this in the notebooks, so it becomes obvious how to get the values out, its a bit of nested calls before we can get to the value(s). Maybe I'll do a pull request.

Well it's only the getValues() and then indexing the regressed value that's different from accessing any other predicted output. But I'll expand the javadoc a little and add the extra accessor.
The regression tutorial should have a note about how the multidimensional nature affects the regression objects, I thought that was in there but it's probably elsewhere in the docs.

repo: oracle/tribuo


text:
Not running on iOS

@orangepreneur

@orangepreneur

Update your deployment target to 12 Sent from Mail for Windows From: RohitSent: 10 January 2022 16:07To: orangepreneur/payumoneySDKCc: SubscribedSubject: [orangepreneur/payumoneySDK] Not running on iOS (Issue #3) —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Yes. I have done that. Minimum Target is set to iOS 12.0
I am using PayUCheckout-Pro version 3.1.0

any solution for this?
@rohitrvayuz  @orangepreneur

I modified this myself to use it. I will check if I still have access to the code.
On 19 Feb 2023 at 11:43 +0530, kalpesh2421 @.***>, wrote:

any solution for this?
@rohitrvayuz @orangepreneur
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

authors: kalpesh2421 orangepreneur rohitrvayuz

repo: orangepreneur/payumoneySDK


text:
OCI Store resolver returns plain descriptor

When resolving a descriptor from the OCI store, the returned descriptor is stripped down to contain only the media type, digest and size: https://github.com/oras-project/oras-go/blob/96a37c2b359ac1305f70dc31b28c789688d77d0f/content/oci/oci.go#L185
Is there any particular reason to not have a complete descriptor returned ?

Returning the complete descriptor could be tricky in some scenarios.
I would like to take the chance to discuss this use case:
Suppose there are two descriptors pointing to the same manifest with different tags (v1.0 and latest) in the index.json:
{
    "schemaVersion": 2,
    "mediaType": "application/vnd.oci.image.index.v1+json",
    "manifests": [
      {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "v1.0",
          "foo":"bar"
        }
      },
      {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "latest",
          "foo":"bar"
        }
      }
    ]
  }

If we resolve the descriptor by its digest:
desc, err := oci.Resolve(ctx, "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f")

What should be the result of oci.Resolve()?
Should it be the descriptor tagged by v1.0?
     {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "v1.0",
          "foo":"bar"
        }
      },

Or the descriptor tagged by latest?
      {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "latest",
          "foo":"bar"
        }
      }

Or should we strip the annotation org.opencontainers.image.ref.name and keep others?
      {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "foo":"bar"
        }
      }

@Wwwsylvia it is my understanding that in the current OCI model, it is a legal and common case that a sha256 can resolve to 1 to N number of tags. Not supporting that would introduce backward compatibility backlash in my opinion which is undesirable. Am I missing something?

@gertd Yes a digest can be associated with multiple tags, and all the tags are saved in index.json.

a sha256 can resolve to 1 to N number of tags.

Do you mean we should return a list of descriptors for Resolve(dgst) ? Or am I understanding it wrong?

Not supporting that would introduce backward compatibility backlash

Could you elaborate a bit more on "backward compatibility"?

Maybe we can add a function ResolveN(), which returns multiple descriptors for a digest reference and returns one descriptor for a tag reference.
func (s *Store) ResolveN(ctx context.Context, reference string) ([]ocispec.Descriptor, error)

Using the above example, if we call
descs, err := oci.ResolveN(ctx, "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f")

The result would be
     {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "v1.0",
          "foo":"bar"
        }
      },
      {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "latest",
          "foo":"bar"
        }
    }

And if we call
descs, err := oci.ResolveN(ctx, "latest")

The result would be
     {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "org.opencontainers.image.ref.name": "latest",
          "foo":"bar"
        }
      }

For the original Resolve() function, how about returning a complete descriptor for a tag reference and returning a descriptor without org.opencontainers.image.ref.name for a digest reference? 🤔
Code:
desc, err := oci.Resolve(ctx, "latest")

Result:
    {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "foo":"bar",
          "org.opencontainers.image.ref.name": "latest",
        }
      }

Code:
desc, err := oci.Resolve(ctx, "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f")

Result:
    {
        "mediaType": "application/vnd.oci.image.manifest.v1+json",
        "size": 7143,
        "digest": "sha256:e692418e4cbaf90ca69d05a66403747baa33ee08806650b51fab815ad7fc331f",
        "annotations": {
          "foo":"bar",
        }
      }

@shizhMSFT What do you think?

Resolve() digest is ambiguous if the manifest has multiple tags along with annotations. In that case, we can have ResolveN() to reduce ambiguity.
My suggestion would be

If reference is a digest,

Resolve() returns a plain descriptor
ResolveN() return an array of descriptors with annotations

If reference is a tag,

Resolve() return a descriptor with annotations
ResolveN() works the same as Resolve() but return an array

This is a breaking change which introduces inconsistent behavior of resolver between remote and OCI store.

This is a breaking change which introduces inconsistent behavior of resolver between remote and OCI store.

@qweeah Could you elaborate a bit on this?

Well remote registry manifest resolver always returns a descriptor without annotation.
https://github.com/oras-project/oras-go/blob/e8225cb1e125bd4c13d6b586ae6d862050c3fae2/registry/remote/repository.go#L1372-L1380
With merging of https://github.com/oras-project/oras-go/commit/e8225cb1e125bd4c13d6b586ae6d862050c3fae2, resolve a tagged manifest via tag will always a descriptor with at least one org.opencontainers.image.ref.name annotation.
Noticed this because of the E2E failure in ORAS CLI:
I copied a tagged manifest from remote registry to local OCI layout via tag, resolving the manifest via tag and compare it to the resolved descriptor in registry. The content doesn't match so the E2E fails.

This might not be a critical change since oras-go doesn't make any promise to guarantee that the resolved descriptor from registry and OCI layout will be identical. But IMHO it's better to bring it to up for discussion, like whether it's a breaking change and shall we pick it out from upcoming V2 minor releases.

This might not be a critical change since oras-go doesn't make any promise to guarantee that the resolved descriptor from registry and OCI layout will be identical.

Yeah there is no a guarantee that OCI.Resolve() and Repository.Resolve() will return exactly the same result.
For OCI Target, the manifest descriptor is resolved from the records in index.json. It's intuitive that the resolved descriptor matches the record in index.json.
But there is no such index.json for remote repositories, and the descriptor is resolved from the HTTP response of the remote server.

But IMHO it's better to bring it to up for discussion, like whether it's a breaking change and shall we pick it out from upcoming V2 minor releases.

I personally don't think it's a breaking change for oras-go, as it's adding things (annotation, etc.) to the original result (plain descriptor), not changing or removing existing stuffs.
But it could be a breaking change from the ORAS CLI point of view since the output format changed. 🤔
IMHO we can update the ORAS E2E tests to accommodate this change.
@shizhMSFT Any thoughts?

In general, Target.Resolve() can return any extra stuffs other than the digest, size, media type. Therefore, we should use content.Equal() to compare the returned descriptors instead of reflect.DeepEqual().
If ORAS CLI E2E tests has more context on the Target instead of a generic Target, the E2E test can check the returned descriptor in deep accordingly.

Closed by #468

Resolve() digest is ambiguous if the manifest has multiple tags along with annotations. In that case, we can have ResolveN() to reduce ambiguity.
My suggestion would be

If reference is a digest,

Resolve() returns a plain descriptor
ResolveN() return an array of descriptors with annotations

If reference is a tag,

Resolve() return a descriptor with annotations
ResolveN() works the same as Resolve() but return an array

The ResolveN function has not been implemented yet. Do we need to raise another issue to track this feature request?

authors: Wwwsylvia carabasdaniel gertd qweeah shizhMSFT

repo: oras-project/oras-go


text:
Sort languages returned by DictionaryService

Sort languages alphanumeric to group regional languages like en_US and en_GB together.

Hi,
we want to use your tool in a project with over 60 regional websites. To have a good overview over the regional differences of a language like en_US and en_UK, we think it would be best to display the languages alphanumeric sorted and not by there content repository order.
Kind regards,
Benjamin

Hi @bdhoine,
add the change log entry. Hope the wording is OK, otherwise feel free to change it.
For the build pipeline: SonaCube looks OK. I can only see that it is waiting for approval. If I miss something, just point me to it via link :)

repo: orbinson/aem-dictionary-translator


text:
Restarted orbitdb is not informed in update listener about all new added documents

When I started a node after the first node has already created some documents only the last created documents is seen in the update listener. However the underlying data seems to be synced, since the count when checking with all is identical.
I have created a project to replicate this:
https://github.com/koh-osug/orbitddb-issue
2 documents are created, but only 1 is later reported in the update listener.

The remote peer only needs to be aware of the latest record to be able to verify and build a replica of the source db's entries. Therefore, only the latest addition is available via 'update'. For example:
await db1.add('a')
await db1.add('b')

// state of the oplog is 'a' <- 'b' where <- 'b' follows 'a'.

await db2.open(db1.address)

db2.on('update', (entry) => {
  // 'update' only gives 'b' because 'b' follows 'a'. db2 does not need to be notified of the update 'a'; 'b' is enough to determine and replicate the correct oplog entries.
})

await db1.add('c') // this will fire db2's update event listener again because db1's oplog has been appended to and the (entry) will be 'c'.

I'll provide a link to https://github.com/orbitdb/orbitdb/blob/main/docs/OPLOG.md which may provide clarity.

Thank you. This clarifies it. Is there any chance to get the full delta of changes? I have a business process which has to post process only new documents on each node.

Yes, the gt iterator param is one option.
If items are coming in from one peer you could loop over the database using iterator, processing each item until you reach the most recently "processed" document.
If items are being sync-ed from various peers you may need to keep a record of the documents already processed and use it to determine whether a document requires processing.
However, the best method will be determined by your technical requirements.
Also, remember, if you are working at the oplog level you are working with operations. You may want to consider working with the data at the database level.

If items are coming in from one peer you could loop over the database using iterator

This means using log.iterator({ amount: 1 }) before connecting to any different peer's DB is not giving the latest hash of the database? I would use this otherwise if it works as latest element while syncing with all other databases.

Also, remember, if you are working at the oplog level you are working with operations. You may want to consider working with the data at the database level.

But on database level I do not have something like log.iterator({ amount: 1 }) to get the last document and I have also no option to get any newer documents then specific hash, right?

You have the iterator available at the db level, yes. The params available to you will depend on the data store being used. I would recommend looking at https://api.orbitdb.org/ for more information about the functions available.

My logic now is getting the log heads and then iterating over all log entries after this. This seems to be functional I can get all new changes:
const db2 = await orbitdb2.open('subscription-data', {type: 'documents'})
let db2a = await orbitdb2.open(db1.address, {sync: false})
const heads = await db2a.log.heads()
await db2a.close()
db2a = await orbitdb2.open(db1.address)

db2a.events.on('update', async (entry) => {
  let filter = {}
  if (heads.length > 0) {
    filter = {gt: heads[0].hash }
  }
  for await (const record of db2a.log.iterator(filter)) {
    console.log("new entry", record)
  }
})

But the documentation of log.heads() returns an array. I'm wondering why multiple heads are possible and what I'm missing here? Also i open the database with sync: false to get the original state, close it and open it again. Somehow this feels inefficient.

But the documentation of log.heads() returns an array.
You can have multiple heads because peers can add records at the same (logical) time.

I'm not sure why you are working at the log level. Why not process records from the document store then mark them as processed?

The first issue I see is that I do not have write access to the synced database replica, I assume your approach would be to overwrite the document with the same document and set a marker attribute to the JSON structure. I.e. write access is necessary, right? My understanding here is that the database I open with orbitdb.open is the same instance as the remote one just a local copy and that changes to this copy would also be reflected in the original database of the owning peer.
Another issue I see that I will miss deletions. How can I see a DELETE operation? I cannot iterate over all documents I assume and do a full database comparison to find out which document have been deleted. My business process needs to know this, hence I has hoping to get all updates, also deletions with the update listener.
Also if I do this this generic marker would be seen also by other peers and then these peers would think that they have already processed it on their end, which is not the case. I could also add a peer specific marker, but this would mean to have 100 specific marker attributes in the document for supporting 100 peers. And all peers need write access.
Also, what I see in the code it that the query function is using the iterator also and I think I cannot afford a complete database scan, if I have 10000 documents it looks like the iterator looks into all 10000 documents then. If something like in SQL a specific query would be possible with a WHERE clause, then I could consider this. Am I wrong here with my assumptions?

What you're describing seems more like a software architecture problem rather than a bug or issue with OrbitDB. If you're looking for help with integration of OrbitDB with your software systems, you may get better traction on the OrbitDB Lobby where other developers may have run into similar implementation issues.

authors: haydenyoung koh-osug

repo: orbitdb/orbitdb


text:
Revert Orbiter to use Fetch mechanism instead of submodules

Reasons

Submodules are extremely messy - unlike plug-and-play CMake dependency management
There is already a mix of submodules and plain source commits indicating that contributors do not understand how to work with submodules

Change
Use Fetch_MakeAvailable instead of .gitmodules to avoid unnecessary complexity. Lua modules are out of scope for now

I plead guilty for adding plain source external dependencies, because adding submodules in pull requests seems a mess to synchronize between different repositories, especially when you do modifications to the original code.
If there's a simple way to do it then I'd be happy to hear it.

I plead guilty for adding plain source external dependencies, because adding submodules in pull requests seems a mess to synchronize between different repositories, especially when you do modifications to the original code.
If there's a simple way to do it then I'd be happy to hear it.

What is the use case for the changes in original code? Can it be covered by 'glue' code instead?

The ldoc module is generating CSS that looks terrible in htmlhelp, I patched some hard coded CSS values to work around it. There's probably a cleaner way to do it but I was running out of steam doing the documentation work and forgot to investigate it further.

That's not the best way to handle it generally - as it will make updating the modified library a sisyphean task later. It seems like time to fix that exceeds the time I have currently though, so I have limited the scope of the PR to elimination of submodules. Ready for review

A couple of remarks :

I don't know if the Lua github is the official one but it's not listing the latest 5.1.5 release. I tried to use

FetchContent_Declare(
  lua
  URL https://www.lua.org/ftp/lua-5.1.5.tar.gz
  URL_HASH SHA256=2640fc56a795f29d28ef15e13c34a47e223960b0240e8cb0a82d9b0738695333
)

but as expected, like every other thing cmake related, I cannot make it work.

If I comment the #if(ORBITER_MAKE_DOC) to generate the Lua doc, the build fails :

>------ Build All started: Project: openorbiter, Configuration: x64-Debug ------
  [1/5] Generating out/index.html
  FAILED: Src/Module/LuaScript/LuaInterpreter/out/index.html
  cmd.exe /C "cd /D C:\github\openorbiter\out\build\x64-Debug\Src\Module\LuaScript\LuaInterpreter && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/Interpreter.cpp C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/Interpreter.h C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/config.ld C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/intro.md C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/lua_vessel_mtd.cpp C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/types.lua C:/github/openorbiter/out/build/x64-Debug/Src/Module/LuaScript/LuaInterpreter && C:\github\openorbiter\out\build\x64-Debug\Utils\lua.exe /ldoc.lua -v --multimodule . && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Src/Module/LuaScript/LuaInterpreter/interpreter.hhp C:/github/openorbiter/out/build/x64-Debug/Src/Module/LuaScript/LuaInterpreter/out"
  C:\github\openorbiter\out\build\x64-Debug\Utils\lua.exe: cannot open /ldoc.lua: No such file or directory
  [2/5] cmd.exe /C "cd /D C:\github\openorbiter\out\build\x64-Debug\Extern && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Extern/ldoc/ C:/github/openorbiter/out/build/x64-Debug/packages/ldoc && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Extern/Penlight/lua/ C:/github/openorbiter/out/build/x64-Debug/"
  [3/5] cmd.exe /C "cd /D C:\github\openorbiter\out\build\x64-Debug\Sound\XRSound && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E make_directory C:/github/openorbiter/out/build/x64-Debug/Doc && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E make_directory C:/github/openorbiter/out/build/x64-Debug/XRSound && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E make_directory C:/github/openorbiter/out/build/x64-Debug/Orbitersdk/XRSound/ && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Sound/XRSound/assets/XRSound/XRSound-Atlantis.cfg C:/github/openorbiter/Sound/XRSound/assets/XRSound/XRSound-DG-S.cfg C:/github/openorbiter/Sound/XRSound/assets/XRSound/XRSound-DeltaGlider.cfg C:/github/openorbiter/Sound/XRSound/assets/XRSound/XRSound-ShuttleA.cfg C:/github/openorbiter/Sound/XRSound/assets/XRSound/XRSound.cfg C:/github/openorbiter/out/build/x64-Debug/XRSound/ && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Sound/XRSound/assets/XRSound/ReadMe.txt C:/github/openorbiter/out/build/x64-Debug/XRSound/ && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy "C:/github/openorbiter/Sound/XRSound/assets/Doc/XRSound User Manual.pdf" C:/github/openorbiter/out/build/x64-Debug/Doc/ && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Sound/XRSound/src/XRSound.h C:/github/openorbiter/out/build/x64-Debug/Orbitersdk/XRSound/ && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Extern/irrKlang/x64/bin/winx64-visualStudio/ikpMP3.dll C:/github/openorbiter/out/build/x64-Debug && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Extern/irrKlang/x64/bin/winx64-visualStudio/ikpFlac.dll C:/github/openorbiter/out/build/x64-Debug && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy C:/github/openorbiter/Extern/irrKlang/x64/bin/winx64-visualStudio/irrKlang.dll C:/github/openorbiter/out/build/x64-Debug && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Sound/XRSound/assets/XRSound/Default C:/github/openorbiter/out/build/x64-Debug/XRSound/Default"
  [4/5] cmd.exe /C "cd /D C:\github\openorbiter\out\build\x64-Debug && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/BinAssets/ C:/github/openorbiter/out/build/x64-Debug && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Scenarios/ C:/github/openorbiter/out/build/x64-Debug/Scenarios && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Textures/ C:/github/openorbiter/out/build/x64-Debug/Textures && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Meshes/ C:/github/openorbiter/out/build/x64-Debug/Meshes && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Script/ C:/github/openorbiter/out/build/x64-Debug/Script && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Config/ C:/github/openorbiter/out/build/x64-Debug/Config && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/GravityModels/ C:/github/openorbiter/out/build/x64-Debug/GravityModels && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E copy_directory C:/github/openorbiter/Flights/ C:/github/openorbiter/out/build/x64-Debug/Flights && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E make_directory C:/github/openorbiter/out/build/x64-Debug/Orbitersdk/lib/Lua"
  ninja: build stopped: subcommand failed.

Build All failed.

I don't know if the Lua github is the official one but it's not listing the latest 5.1.5 release. I tried to use

Yes, the GitHub repo doesn't have 5.1.5 for some reason. Do we need that version specifically? Can we live with 5.1.1?

If I comment the #if(ORBITER_MAKE_DOC) to generate the Lua doc, the build fails :

Sounds like we need documents build enabled in CI... I'll take a look

Can we live with 5.1.1?
Yes it should be good enough for the time being

Regarding the documentation, it's not producing a pdf but still using htmlhelp to generate a .chm file.

Prereq to continue working on this: #480

Build errors fixed - ready for review again

This PR is ready for merge

authors: DarkWanderer TheGondos

repo: orbitersim/orbiter


text:
Whitelist domains to external requests

I propose that instead of overloading Ord with external features, such as tracking Runes balance or Sats balance (https://github.com/ordinals/ord/issues/3875), we consider whitelisting popular domains like mempool or blockchain.info. This would allow us to make API requests to these services directly within Ordinals.
Additionally, we should develop a way for Ord to communicate more effectively with marketplaces and galleries that those whitelisted addresses ARE whitelisted so they can whitelist on their iframe too.

This would make it impossible to run a self-contained index, as well as break whenever those externals sites went down, or changed their API, which is likely to happen because they have much less stringent backwards compatibility guarantees compared to ord.

authors: casey kevinfaveri

repo: ordinals/ord


text:
Cannot bind multiple queues

When I try to use netfilter to bind two queue with different queue num, and I add two callbacks methods to bind with the two number.
nfqueue.bind(1, self.in_modify)
nfqueue.bind(2, self.out_modify)
However, the two queues are all bind to the second callback method.
https://github.com/kti/python-netfilterqueue/blob/master/netfilterqueue.pyx#L178
In this line, it's obvious that the pointer user_callback are overwrite when bind another queue. I think here should use a map to support different callbacks for each queue num.

It doesn't look like the NetfilterQueue class is intended to bind() to more than one queue at a time. I am working on a project that requires multiple callbacks and I made it work by creating an instance of the NetfilterQueue class for each queue I wanted to bind to.

Hi there!
I wrote this wrapper back in the day so I could better integrate it with asyncio, please check it out if you are interested!
https://github.com/jllorente/helpers_n_wrappers/blob/master/nfqueue3.py

Hi there!
I wrote this wrapper back in the day so I could better integrate it with asyncio, please check it out if you are interested!
https://github.com/jllorente/helpers_n_wrappers/blob/master/nfqueue3.py

The bug where bind() of multiple queues will appear to succeed, and leak the queues, has been fixed; it now fails with a clear error. You can manage multiple queues by using multiple NetfilterQueue objects and the async support (wait for get_fd() to be readable, call run(False), rinse, repeat).

authors: fripSide jllorente oremanj strictlymike

repo: oremanj/python-netfilterqueue


text:
🛑 Website is down

In 2cc9a27, Website (https://www.orfeo-toolbox.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Website is back up in 8a585ca after 26 minutes.

repo: orfeotoolbox/status-page


text:
🛑 TTS (Oribi Speak) is down

In a31b08f, TTS (Oribi Speak) ($TTS_ENDPOINT/speak) was down:

HTTP code: 502
Response time: 960 ms

Resolved: TTS (Oribi Speak) is back up in 5769a2d after 10 minutes.

repo: oribisoftware/upptime


text:
java.lang.NegativeArraySizeException thrown on vertices that were in orientdb recently

OrientDB Version, operating system, or hardware.
v2.2
Operating System
Linux
Expected behavior and actual behavior
What is the likely cause of a java.lang.NegativeArraySizeException when querying a vertex in the following manner:
select * from #14:838
I am querying a few vertices directly and all of sudden I am getting this exception.  I suspect some of my data might be corrupted but wanted to see if you could provide some guidance here.
Just a few days prior, these vertices were available.  I also realized that this exception is being thrown for a batch of vertices with sequential @RIDs.  Its about 100+ vertices.
Any guidance?

Hi @krl22785
How can I reproduce this issue? Do you have a database or a test case that I can use?
(server logs - if any - will help as well)
Thanks
Luigi

Hey @luigidellaquila
I am not sure how to help you reproduce it.  Each time I try to query a batch of elements that are in a range, I get this exception.  When I look at the logs, I see this:
2016-09-06 14:58:21:816 SEVER Internal server error:
java.lang.NegativeArraySizeException [ONetworkProtocolHttpDb]
2016-09-06 15:29:28:051 SEVER Internal server error:
java.lang.NegativeArraySizeException [ONetworkProtocolHttpDb]
2016-09-06 18:30:08:314 SEVER Internal server error:
java.lang.NegativeArraySizeException [ONetworkProtocolHttpDb]
2016-09-06 18:30:30:526 SEVER Internal server error:

Hi @krl22785
Do you think it's possible to privately share your db? The query you are reporting is quite common, so the problem should be in the data
Thanks
Luigi

I don't think I can share but this is what I have in my logs.  After a hard reboot, the logs threw this message.  This is data we already had in our database.  Should I reconsider restarting the database again?
It appears each time I query for the records that had an "Error on retrieving..." message, it throws this java.lang.NegativeArraySizeException.
Any guidance?
$ANSI{green {db=DATABASE}} Error on fetching record during browsing. The record has been skipped
com.orientechnologies.orient.core.exception.ODatabaseException: Error on retrieving record #14:14809 (cluster: classA)
$ANSI{green {db=DATABASE}} Error on fetching record during browsing. The record has been skipped
com.orientechnologies.orient.core.exception.ODatabaseException: Error on retrieving record #14:14810 (cluster: classA)
$ANSI{green {db=DATABASE}} Error on fetching record during browsing. The record has been skipped
com.orientechnologies.orient.core.exception.ODatabaseException: Error on retrieving record #14:14811 (cluster: classA)

@krl22785 what concrete version of 2.2 do you use could you specify ?

@luigidellaquila  we are using orientdb 2.2.4

@krl22785 that is what you should not to do in any case, 2.2.4 contains critical issue which may damage data. Please upgrade to latest one.

@laa @luigidellaquila is that for both the community and enterprise versions?

@krl22785 did you upgrade and resolved this problem?

@lvca We tried upgrading and migrating an export of the data from before this error occurred but were unable to because of #6759. Do you think they could be related? i.e. some silent corruption already took place before, and only shows up during the import?

@lvca Incremental restore in 2.2.4 also does not work on our database backup: #6774. Not sure if all these import/export and backup/restore problems are related to data corruption?

authors: krl22785 laa luigidellaquila lvca yeoedward

repo: orientechnologies/orientdb


text:
Dead database after ungraceful shutdown or 3.0.14: OEmptyWALRecord

OrientDB Version: 3.0.14
Java Version: 1.8
OS: Ubuntu 18.04
Hi,
We're getting an exception on our database after server shut down abruptly:
2019-07-02 08:00:01:914 INFO  Looking for last checkpoint... [OLocalPaginatedStorage]Exception during storage data restore
com.orientechnologies.orient.core.exception.OStorageException: Unknown checkpoint record type com.orientechnologies.orient.core.storage.impl.local.paginated.wal.cas.OEmptyWALRecord
        at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.restoreFromWAL(OAbstractPaginatedStorage.java:5297)
        at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.recoverIfNeeded(OAbstractPaginatedStorage.java:4504)
        at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.open(OAbstractPaginatedStorage.java:374)
        at com.orientechnologies.orient.core.db.OrientDBEmbedded.openNoAuthenticate(OrientDBEmbedded.java:210)
        at com.orientechnologies.orient.core.db.OrientDBEmbedded.openNoAuthenticate(OrientDBEmbedded.java:60)
        at com.orientechnologies.orient.server.OServer.openDatabase(OServer.java:936)
        at com.orientechnologies.orient.server.OServer.openDatabase(OServer.java:913)
        at com.orientechnologies.orient.server.OConnectionBinaryExecutor.executeDatabaseOpen(OConnectionBinaryExecutor.java:1144)
        at com.orientechnologies.orient.client.remote.message.OOpenRequest.execute(OOpenRequest.java:150)
        at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.sessionRequest(ONetworkProtocolBinary.java:304)
        at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.execute(ONetworkProtocolBinary.java:206)
        at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:69)
Exception `737183F2` in storage `plocal:/ns0/orientdb/orientdb-3.0.14/databases/prod`: 3.0.14 - Veloce (build ac128c5a9ba4c6dc9d25a32b92962d8863774423, branch 3.0.x)
com.orientechnologies.orient.core.exception.OStorageException: Unknown checkpoint record type com.orientechnologies.orient.core.storage.impl.local.paginated.wal.cas.OEmptyWALRecord
        at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.restoreFromWAL(OAbstractPaginatedStorage.java:5297)
        at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.recoverIfNeeded(OAbstractPaginatedStorage.java:4504)
        at com.orientechnologies.orient.core.storage.impl.local.OAbstractPaginatedStorage.open(OAbstractPaginatedStorage.java:374)
        at com.orientechnologies.orient.core.db.OrientDBEmbedded.openNoAuthenticate(OrientDBEmbedded.java:210)
        at com.orientechnologies.orient.core.db.OrientDBEmbedded.openNoAuthenticate(OrientDBEmbedded.java:60)
        at com.orientechnologies.orient.server.OServer.openDatabase(OServer.java:936)
        at com.orientechnologies.orient.server.OServer.openDatabase(OServer.java:913)
        at com.orientechnologies.orient.server.OConnectionBinaryExecutor.executeDatabaseOpen(OConnectionBinaryExecutor.java:1144)
        at com.orientechnologies.orient.client.remote.message.OOpenRequest.execute(OOpenRequest.java:150)
        at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.sessionRequest(ONetworkProtocolBinary.java:304)
        at com.orientechnologies.orient.server.network.protocol.binary.ONetworkProtocolBinary.execute(ONetworkProtocolBinary.java:206)
        at com.orientechnologies.common.thread.OSoftThread.run(OSoftThread.java:69)

Hi, that means that you created a database under the version bigger and use under the version lower than it was created. Please use lates 3.0.21 and that issue will be fixed.

@laa ,
Pretty sure that's not the case. It's was a copy of db from 3.0.12 and we upped the version to 3.0.14.

Hi, @andreyvk record detection based on instanceof operator of Java. That means that you either have an older version of mix of libraries on classpath. I am quite sure that this error is absent in distribution because this functionality was tested many times both in production and during the running of test cases.

Hi, @laa it was a fresh instance of ubuntu 18.04 and only a single DB was installed there. Normally I wouldnt mix any libraries on purpose.
Btw, it's not possible to move to 3.0.21 because of the PhpOrient driver, which doesnt behave well once you up to the latest version + I cant move to the REST protocol, because it's not feasible with the workaround available (see #8762). It's pretty much a dead end.

Hi, @andreyvk could you crash database and send it to me so I will reproduce the issue on your version?

Please do not restore it of course or an exception will dissappear.

Hi @andreyvk any updates on that? Will you send a broken database?

Hi @andreyvk any updates on that? Will you send a broken database?

Closed, because of no answer.

authors: andreyvk laa


text:
Request for Comprehensive Documentation Section for Origin UI

Comprehensive Documentation Section for Origin UI
To enhance the user experience with Origin UI, we've introduced a dedicated Getting Started guide, designed to streamline the setup and configuration process for seamless integration. This documentation is crafted to provide clear, concise instructions, ensuring users can quickly set up the components without the need for extensive configuration details. By offering a smooth onboarding experience, this guide empowers users to jump into building with ease and focus on their projects rather than setup complexities.
For this documentation, we’ve used a utils.md file on GitHub as the main source of guidance. This choice was intentional, prioritizing simplicity and efficiency for two key reasons:

One-Time Configuration: The utils.md file provides a one-time setup guide, covering essential steps required to get started with Origin UI. This approach eliminates the need for prolonged documentation, offering users everything they need to configure the project quickly.

Encouraging Open Source Exploration: By linking directly to GitHub, users are not only guided through setup but are also introduced to the open-source repository. This enables them to explore the progress of Origin UI, contribute feedback, and support the project through positive interactions, such as stars and constructive suggestions.

Incorporating this dedicated installation guide into the Origin UI experience allows users to benefit from a straightforward, streamlined building process while fostering a deeper engagement with the open-source community.

Hello @pasqualevitiello I would like to present my contribution among all the other contribution , I would like to request you review my pull request and approve changes and if there is anything to change or update , please let me know
Thank you

I see a lot of overlapping content between utils.md and README.md - let's keep everything in the README to avoid repetition.

repo: origin-space/originui


text:
jpype JVM doesnt load SunJCE security providers

trying to authorize via kerberos using sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType encryption type and experiencing the errror "Caused by: java.security.NoSuchAlgorithmException: Cannot find any provider supporting AES/CBC/NoPadding".
when i check the loaded security providers, several security providers are present except for SunJCE. i can authorize via kerberos fine when running in java so it is not an environment issue.
any ideas on a fix or workaround?

Do you know if these providers are implemented using a "custom"/non-default classloader? I'm asking because jpype does not support custom class loaders.
From the introduction found here https://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#Introduction, it seems like one should not explicitly specify the provider.

yeah, im not specifying the provider explicitly. kerberos is configured to use aes 256 which is provided by SunJCE. and no, it just uses the extensions class loader.

Do you have to use extensions class loader yourself or is it used internally within the library?

its used internally w/in the library

the security providers that are loaded properly are using a bootstrap class loader. any ideas on how to properly load security providers that use an extensions class loader?

On 03/21/2017 03:06 PM, jbraun11 wrote:

the security providers that are loaded properly are using a bootstrap class loader. any ideas on how to properly load security providers that use an extensions
class loader?

Outside of Java - no idea - sorry. Isn't there a public interface in JCE which wraps around the loading?

the issue is caused by configuration settings for my jvm. not an issue w/ jpype

I encountered the same issue here, may I ask how to configure jvm settings for this? @jbraun11

repo: originell/jpype


text:
Add AudioContext::with_capacity and strictly deny new allocations

The golden audio processing standard is that the render thread should be 100% allocation free.
This can be achieved by allocating up front and (optionally) deny any new allocations.
What I think we need is a
AudioContextCapacity {
    max_nodes: usize,
    max_audio_quanta_in_flight: usize,
    max_control_messages: usize
}

max_nodes should be used as capacity of the Graph fields

nodes (a HashMap currently)
ordered, marked, marked_temp, in_cycle (Vec)

max_audio_quanta_in_flight should be used as the capacity of the AllocInner.pool Vec.
~The meaning of "audio quanta in flight" is a bit hard to describe, technically it is the sum of all output port counts * channel counts of the leaf nodes of the audio graph.~
~For example, if your graph is entirely linear (e.g. buffersource -> biquad -> gain -> speakers) and emits on 2 channels, a max of 2 AudioRenderQuantumChannel should suffice.~
~If you graph forms a perfectly balanced binary tree with 10 leaves having 2 outputs with 2 channels each, theoretically it could have 40 AudioRenderQuantumChannel concurrently in flight~
I realize this is not true because output buffers are not freed after each individual processor runs, todo
max_control_messages is the Control-Render communication channel capacity.
We could add a cfg(debug) assertion that no new allocations are allowed to be made with the alloc_counter crate (or equivalent). This will probably directly show some allocator calls we need to address:

Graph.add_node allocates Vecs for the input and output containers (this can be fixed with allocation in the control thread and an unsafe transfer to the render thread
Node.outgoing_edges is a smallvec now with stack-capacity of 2 items. Todo figure out a plan here
When a node is decommissioned, some containers are deallocated. Idea - ship them to control thread?

Interesting indeed
Another possibility, in the reverse sens in some way, would be to be able to modify the initial size of the pools without clipping them (e.g. make alloc: Alloc::with_capacity(64) configurable (I find that 64 to be really low actually)). So you can optimize your app in some extent by grabbing more memory at startup and minimize further allocation, but not destroy everything if you just miscalculated something.
In any case, I would wait for the use-case that require that sort of optimisations (not sure there are dozens out there), but very good to keep in mind indeed.
Another related thing, maybe more straightforward and spec compliant, would be to have some double buffering strategy (every browser have that implemented in my knowledge), with some disable config flag when you have hard real-time constraints.

Good points. Maybe AudioContextCapacityHint is a better term, to make clear it's not a limit we enforce. Only in some cfg(debug) tests we can deny allocs. Also this is definitely not something we should bring in before v1 release.
Regarding double buffering - that would be an admission of weakness in my opinion!
In Firefox no buffering is performed:

Firefox doesn't buffer audio (ever), so baseLatency is zero. The graph processing is directly serviced from the real-time audio callback the OS calls.

From https://github.com/WebAudio/web-audio-api/issues/2467#issuecomment-1009012693

Regarding double buffering - that would be an admission of weakness in my opinion!

Haha, that's a point of view indeed :), baseLatency will be quite straightforward to implement then!

In Firefox no buffering is performed:

Good point, didn't remember that

authors: b-ma orottier

repo: orottier/web-audio-api-rs


text:
chore: suppress react-intl warnings

This PR supresses the warnings from react-intl about pre-compiling the messages. See also https://github.com/formatjs/formatjs/pull/3506

Related Issue or Design Document

Checklist

[ ] I have read the contributing guidelines and signed the CLA.
[ ] I have referenced an issue containing the design document if my change introduces a new feature.
[ ] I have read the security policy.
[ ] I confirm that this pull request does not address a security vulnerability.
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact security@ory.sh) from the maintainers to push the changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have added the necessary documentation within the code base (if appropriate).

Further comments

I tried, but that assumes that we extracted the message, and that format is different from ours. I couldn't get the CLI to compile our messages. If you know how, feel free. But we should get rid of this message.

repo: ory/elements


text:
Add GUI option to disable settings flow

It is possible to disable the settings flow in the identity service configuration, but not in the UI.
Would be a good addition in base settings
context: https://ory-community.slack.com/archives/C02MR4DEEGH/p1669392879249409

Tracked via: https://github.com/ory-corp/cloud/issues?q=is%3Aissue+is%3Aopen+label%3A"needs+triage"

yes :(
probably best to copy the full message when creating the issue.
I only found this: https://archive.ory.sh/t/5167192/is-it-possible-to-disable-settings-profile-flow-in-ory-cloud#b107b509-c8a1-40e7-a3db-c755edfa19cd
I think the use case was to prevent the user from changing their profile information.

Maybe we could also introduce a “reject” Action / built in hook that you can just configure to run pre settings flow (or anywhere else deemed useful).
Not sure which way is better.

authors: aeneasr kmherrmann vinckr

repo: ory/network


text:
Request to support dialog.open API method

There's a brand new API method, described in https://api.slack.com/dialogs, which would be really handy to have supported by slacker.

I'm looking for the same .... Any info @os ? :/

bump +1

@janikarh Added in #141. Thanks!

authors: jahirfiquitiva janikarh os shollingsworth

repo: os/slacker


text:
org.osbuild.systemd: Support masking generators

This adds a new key masked_generators, similar to masked_services, which masks systemd generators from running at boot, by creating symlinks to /dev/null in /etc/systemd/systemd-generators, as described in:
https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html#Description
This will be useful for the automotive project, as it allows disabling of unsupported things like sysv or rc.local legacy support, while improving boot performance.

The PR extended the current test to also test this feature.

Sorry again, I should have been more clear. I was thinking about a small unit test, I attached what I had in mind. It maybe slightly over the top as the extended stage test checks that the expected mask file is created. The (small in this case) values this new unit test style tests are adding is a) run faster b) more precise, i.e. we can check the link target is correct.
Anyway, sorry for my nitpicks, this looks fine.
0001-stages-systemd-add-unit-test-for-the-new-masked_gene.patch.txt

Added the comment and your unit test.

repo: osbuild/osbuild


text:
Add type_as attribute to specta

We were looking into using specta in our project, but ran into the issue of needing an escape hatch for certain types that can't (easily) implement Type.  This solution is similar to ts_rs's #[ts(type = "..")] attribute.
#[specta(type_as = <Ident>)] on a field overrides its type in the generated type definition with the type of the identifier.
Example:
use specta::{ts::ts_export, Type};

pub enum MyEnum {
    A,
    B,
    C,
}

#[derive(Type)]
pub struct MyCustomType {
    #[specta(type_as=String)]
    pub nested: MyEnum,
}

fn main() {
    println!("{}", ts_export::<MyCustomType>().unwrap(),);
}

Any feedback is super appreciated!

Also would you mind explaining why you need type overrides, and why you picked Specta over ts-rs? Just curious haha

Also would you mind explaining why you need type overrides, and why you picked Specta over ts-rs? Just curious haha

Oh, sorry I didn't have the time to address your comments, thanks for the corrections.
Our main problem was that the messages in our tauri app included types from 3rd party crates that we normally just serialize to string, but we can't have them implement Type.
The reason we would like to use specta is its ability to generate all referenced type definitions recursively. With ts-rs we have a huge list of types that need to be printed, and it needs to be updated manually. Whereas with specta, it would just be a single call, since we already have all relevant types in an enum anyway.

repo: oscartbeaumont/rspc


text:
Refactor processing of OSIAM's home directory

OSIAM will now load the configuration only from the YAML file in its
home directory.
This is done by running the initialization as early as possible via an
ApplicationListener.
Initialization will take place when the environment is ready to use, but
before external configuration will be loaded by the
ConfigFileApplicationListener.
At this early stage of application startup, logging has not yet been set
up.
The first time logging is available, is when the
ApplicationPreparedEvent is received.
To not lose the messages, they will be logged then.
To log whether the home directory was actually initialized, the flag
hasInitializedHome has been introduced.
Also introduce a PropertySource, that will hold a checked and munged
value of the user-supplied home directory.
This is because it could be empty or a relative path, which does not
work with the upcoming support of a file-based H2 database.

Two missing 'be' in the PR's description, also 'has not yet been set up'

Thanks for your comments. I fixed the commit message.

I'm not completely sure if you intended it to work, if not please remove it from the PR, but java -jar .osiam.war initHome doesn't work for me. It exits with "java.lang.IllegalArgumentException: Could not resolve placeholder 'osiam.home' in string value "file:${osiam.home}/config/osiam.yaml"

@wallner you need to set osiam.home like $  java -jar target/osiam.war initHome --osiam.home=/Users/david/.osiam

@dacrome Then it would work, yes. However I'd expect it to create the directory in my home directory if I ommited --osiam.home=... at least that would be the principle of least surprise.

Can you fix the weird line breaks for the commit message as well, please?

Sorry for that inconvenience @wallner. Shame on me, I did not test this use case :( I fixed it. To fix it I had to empty the class org.osiam.cli.InitHome. See the comment in the class for an explanation.
The line breaks are at the recommended line width of 72 characters. Yes, they're weird sometimes, I must admit. I really don't want to start a discussion about rules for commit message formatting, do you?

Oh, I see what you mean. Fixed it.

Thank you. It works lie a charm now and was no inconvenience at all, that's what code reviews are for. Please add a CHANGELOG entry for this change and then it's good for a merge.

There will be no changelog entry for this, because it's a refactoring of something that does not even exist in any released OSIAM version. And apparently it's not even completely finished yet. So what am I supposed to write in the Changelog? We also still have #51, which deals with all this stuff.

Ok fair enough. I'm happy to merge then.

authors: dacrome tkrille wallner

repo: osiam/osiam


text:
version upgrades

[x] Current node version: 18.15.0
[x] Current npm version: 9.5.0

/server

[x] whole project
[ ] tests

/web

[x] mui
[x] mui jss to styled
[x] mui pickers
[x] react router
[x] Buffer usage in AuthActions.jsx
[x] Re-enabling StrictMode
[x] tests
[x] #166 may be unnecessary after version upgrades.

Regressions

onClick events cannot be triggered when StrictMode is enabled. This might be related to using "react-router-dom":"^5.2.0" with "react": "^18.2.0".

// in web/index.jsx

import { createRoot } from 'react-dom/client';
import { StrictMode } from 'react';
import './index.css';
import App from './App';

const root = createRoot(document.getElementById('root'));

root.render(<StrictMode><App /></StrictMode>);

We cannot use the Buffer object to decode/encode base64 string. (Check the usage in AuthActions.jsx)

Do a search by using one of the date pickers. Re-open the search options. It will give the error below:

ERROR
Invalid time value
RangeError: Invalid time value
    at format (http://localhost:3000/static/js/bundle.js:54221:11)
    at DateFnsUtils.formatByString (http://localhost:3000/static/js/bundle.js:9039:74)
    at DateFnsUtils.format (http://localhost:3000/static/js/bundle.js:9036:20)
    at openDatePickerDialogue (http://localhost:3000/static/js/bundle.js:45214:125)
    at useDesktopPicker (http://localhost:3000/static/js/bundle.js:41955:23)
    at DesktopDatePicker (http://localhost:3000/static/js/bundle.js:37846:90)
    at renderWithHooks (http://localhost:3000/static/js/bundle.js:113704:22)
    at updateForwardRef (http://localhost:3000/static/js/bundle.js:116275:24)
    at beginWork (http://localhost:3000/static/js/bundle.js:118322:20)
    at HTMLUnknownElement.callCallback (http://localhost:3000/static/js/bundle.js:103296:18)

References

https://mui.com/material-ui/migration/migration-v4/
https://mui.com/material-ui/migration/migrating-from-jss/
https://mui.com/material-ui/guides/pickers-migration/
https://reactrouter.com/en/main/upgrading/v5
https://gist.github.com/mjackson/d54b40a094277b7afdd6b81f51a0393f

https://github.com/remix-run/react-router/blob/dev/examples/auth/src/App.tsx

StrictMode issue is related to the mount/unmount check in Login and Register components. I just removed the checks but we can track the opened issue for further information.
This is exactly the same usage as on our components:
https://github.com/facebook/react/issues/24670#issuecomment-1360495936

Remove buffer usage in AuthActions.jsx file. Since it is redundant.

Previously, the topics were empty and we did not test them properly. Still the 'should create form' test case sometimes passed. Fixed this in 5cd58eda20503c284f2ef3f6fad10affdfd24e60

authors: osmannkartall yusufakdas

repo: osmannkartall/knowzone


text:
Enable use of user-provided thread::Pool instance

Add Pool::num_threads accessor.
Advantages:

Allows to use Pool configured with user-preferred number of threads.
If libosmium used in a shared library, this helps to prevent potential deadlock during Pool shutdown at (after) shared library unloading (see #213 for details).

Note, Reader has been left using the default Pool instance to avoid interface clutter - the pool is 1) used just by PBFParser and 2) it is optional there.

Compiled with GCC 7.1.0 and passed all tests on Ubuntu Linux (complete test suite)
Compiled with VS2017 and run using custom sample reader/writer (XML, PBF) app

Codecov Report

Merging #214 into master will increase coverage by 0.07%.
The diff coverage is 89.77%.

@@            Coverage Diff             @@
##           master     #214      +/-   ##
==========================================
+ Coverage      85%   85.08%   +0.07%
==========================================
  Files         257      257
  Lines       17436    17495      +59
==========================================
+ Hits        14822    14885      +63
+ Misses       2614     2610       -4

Flag
Coverage Δ

#data_tests
79.23% <ø> (ø)
:arrow_up:

#examples
36.42% <42.3%> (ø)
:arrow_up:

#unit_tests
88.21% <100%> (+0.07%)
:arrow_up:

Impacted Files
Coverage Δ

include/osmium/io/detail/debug_output_format.hpp
0.32% <0%> (ø)
:arrow_up:

include/osmium/io/detail/pbf_output_format.hpp
0.41% <0%> (ø)
:arrow_up:

include/osmium/io/detail/xml_output_format.hpp
39.47% <100%> (ø)
:arrow_up:

test/t/io/test_writer_with_mock_encoder.cpp
97.29% <100%> (ø)
:arrow_up:

include/osmium/io/detail/pbf_input_format.hpp
90% <100%> (ø)
:arrow_up:

include/osmium/thread/pool.hpp
94.11% <100%> (+0.5%)
:arrow_up:

test/t/thread/test_pool.cpp
100% <100%> (ø)
:arrow_up:

include/osmium/io/detail/output_format.hpp
84.44% <100%> (ø)
:arrow_up:

include/osmium/io/detail/opl_output_format.hpp
55.55% <100%> (ø)
:arrow_up:

include/osmium/io/writer.hpp
91.76% <100%> (+0.3%)
:arrow_up:

... and 2 more

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 f1e0bd8...735c941. Read the comment docs.

I think to be consistent, we should also do the same for Reader. But first get it right for the Writer.

I think to be consistent, we should also do the same for Reader.

Yes.

But first get it right for the Writer.

I like this approach.

@joto I think I've completed the first major round of review. If you could have a look at the updates and see what else needs improving.

Second round of review requests addressed.

https://travis-ci.org/osmcode/libosmium/jobs/253639146
 57/115 Test  #57: io_test_writer_with_mock_encoder .........***Exception: SegFault  0.04 sec

Hmm, only one Xcode builds is failing. I don't have access to OSX to investigate if this is actually related to this PR.

The test failure on OSX is probably something else. The master branch also shows the same problem.
I have looked at the Writer constructor in more detail now and I think it is mostly fine the way you wrote it. Just initialize m_output(nullptr) so we have the complete list of members. And we don't need m_pool, just do a  if (!options.pool) { options.pool = &thread::Pool::default_instance() } and use options.pool then when creating the output.

Now that the writer side is clear, lets look at the reader side, too. This should be even easier, because of the struct parser_arguments which can easily be extended with a Pool member which will then be available in all the right places. Can you add this to your pull request?

@joto https://github.com/osmcode/libosmium/pull/214#issuecomment-315464056

Just initialize m_output(nullptr) so we have the complete list of members (...)

Done.

@joto https://github.com/osmcode/libosmium/pull/214#issuecomment-315465792
First stab at Pool-enabled Reader is in.
Since only PBFParser-based reader actually uses the pool, if there was a .pbf test data added, the Reader test case with user-provided Pool could be switched to use .pbf.

Thanks @mloskot for the great work. I have merged the pull request now. If needed, we can do further refinement later.

@joto I'm glad we could help. Thank you for your assistance.

authors: codecov-io joto mloskot

repo: osmcode/libosmium


text:
Future import assertions syntax for importing JSON files

see https://github.com/osmlab/name-suggestion-index/issues/6014 for details, but basically:
Node is now (since v16.14+) requiring "assert" syntax when importing JSON as a module.
import fileJSON from 'file.json'  assert {type: 'json'};

So this is an issue to:

[x] add this syntax anywhere we import a JSON file
[x] drop support for older versions of node in package.json and the CI action
[x] remove eslint from the test command for now 😢

Just did this today - reminder that everyone working on this project probably now needs to upgrade their node.
nvm install 16.14
nvm alias default 16.14

repo: osmlab/osm-community-index

license: ISC


text:
adds osmo fees, low, medium, high as on website.

Adds osmosis gas prices for low, medium and high as on the website.

thanks @blavejr
I updated the implementation, see the read me for the updates! thanks again :)

@pyramation no problem man, I'll be in the discord for anything else I can help with.

authors: blavejr pyramation

repo: osmosis-labs/osmojs


text:
feat: IBC GAMM

Description
As part of the juno challenge, an ibc module was made to query the spot price of a pool asset.
Demo on testnet (JUNO <> OSMO)
osmosis UI - https://osmosis-ibc.web.app/
juno - https://dapps.juno.giansalex.dev/osmo/
@JakeHartnell @dimiandre
Can confirm if its inclusion is possible?

For contributor use:

[x] Targeted PR against correct branch (see CONTRIBUTING.md)
[x] Updated relevant documentation (docs/) or specification (x/<module>/spec/)
[ ] Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
[x] Re-reviewed Files changed in the Github PR explorer

This approach of doing a request/response via an IBC application protocol is at odds with what the cosmos dev consensus is around IBC queries
See the discussion here
https://github.com/cosmos/ibc/discussions/605

I had not seen that, it will be very useful, i will wait for the specification to be completed.
I close this for now.

authors: giansalex zmanian

repo: osmosis-labs/osmosis


text:
Function to get router IP and this device IP

Can we add a function to get the router/default gateway
IP and this device IP?.

network_info_plus package is not compatible with dart native but our package is. Apart from that is there any way we can retrieve this information?

I know in Linux how to get IP but we need to support android and ios as well.
So let's keep this up in case anybody wants to take it.

This can also be achieved by adding network_info_plus wherever needed

I think we should strive to have support for Android and iOS as well even if under the hood is used other packages.
This way users can call one function for platforms.
I would expect from Network tools package to have this functionality included

then it will become our responsibility to change method signature or api signature whenever these packages gets updated and also updating dependencies as those packages updates will make our job tough


text:
Cant get position fix

Hello , I have transmitting the gps signal using hack rf and ANT 500 since a while in indoor environment but i cant get the position fix.
hackrf_transfer -t gpssim.bin -f 1575420000 -s 2600000 -a 1 -x 0
and I have tried different transmission range like 5 dB,10,15,20 and distances . But even also i cant get the position fix.
Please help me with this problem. .
I Will be grateful

Hello, I posted #240 that might help you.

@komalkumar6655 .. how did you resolve

repo: osqzss/gps-sdr-sim