text:
Translations update from Hosted Weblate

Translations update from Hosted Weblate for OpenWrt/LuCI/modules/luci-base.
It also includes following components:

OpenWrt/LuCI/applications/openwisp

OpenWrt/LuCI/applications/coovachilli

OpenWrt/LuCI/modules/luci-mod-battstatus

OpenWrt/LuCI/applications/olsr-viz

OpenWrt/LuCI/applications/minidlna

OpenWrt/LuCI/applications/cshark

OpenWrt/LuCI/applications/squid

OpenWrt/LuCI/applications/eoip

OpenWrt/LuCI/applications/bcp38

OpenWrt/LuCI/applications/rp-pppoe-server

OpenWrt/LuCI/applications/fwknopd

OpenWrt/LuCI/applications/dcwapd

OpenWrt/LuCI/applications/dump1090

OpenWrt/LuCI/applications/advanced-reboot

OpenWrt/LuCI/applications/dynapoint

OpenWrt/LuCI/applications/xinetd

OpenWrt/LuCI/applications/polipo

OpenWrt/LuCI/applications/mosquitto

OpenWrt/LuCI/applications/omcproxy

OpenWrt/LuCI/applications/opkg

OpenWrt/LuCI/applications/tinyproxy

OpenWrt/LuCI/applications/samba4

OpenWrt/LuCI/applications/transmission

OpenWrt/LuCI/applications/nut

OpenWrt/LuCI/applications/ddns

OpenWrt/LuCI/applications/mwan3

OpenWrt/LuCI/applications/ocserv

OpenWrt/LuCI/applications/privoxy

OpenWrt/LuCI/applications/vpn-policy-routing

OpenWrt/LuCI/applications/p910nd

OpenWrt/LuCI/applications/vnstat

OpenWrt/LuCI/applications/ntpc

OpenWrt/LuCI/applications/dnscrypt-proxy

OpenWrt/LuCI/applications/nextdns

OpenWrt/LuCI/applications/mjpg-streamer

OpenWrt/LuCI/applications/wireguard

OpenWrt/LuCI/applications/splash

OpenWrt/LuCI/applications/udpxy

OpenWrt/LuCI/applications/ksmbd

OpenWrt/LuCI/applications/ser2net

OpenWrt/LuCI/applications/nlbwmon

OpenWrt/LuCI/applications/vnstat2

OpenWrt/LuCI/applications/openvpn

OpenWrt/LuCI/applications/simple-adblock

OpenWrt/LuCI/applications/ttyd

OpenWrt/LuCI/applications/commands

OpenWrt/LuCI/applications/frps

OpenWrt/LuCI/applications/bmx7

OpenWrt/LuCI/applications/aria2

OpenWrt/LuCI/applications/uhttpd

OpenWrt/LuCI/applications/unbound

OpenWrt/LuCI/applications/adblock

OpenWrt/LuCI/applications/dockerman

OpenWrt/LuCI/applications/pagekitec

OpenWrt/LuCI/applications/radicale2

OpenWrt/LuCI/applications/watchcat

OpenWrt/LuCI/applications/travelmate

OpenWrt/LuCI/applications/acme

OpenWrt/LuCI/applications/olsr

OpenWrt/LuCI/applications/https-dns-proxy

OpenWrt/LuCI/applications/frpc

OpenWrt/LuCI/applications/wifischedule

OpenWrt/LuCI/applications/lxc

OpenWrt/LuCI/applications/yggdrasil

OpenWrt/LuCI/applications/acl

OpenWrt/LuCI/applications/firewall

OpenWrt/LuCI/modules/luci-mod-dashboard

OpenWrt/LuCI/applications/upnp

OpenWrt/LuCI/applications/sqm

OpenWrt/LuCI/applications/olsr-services

OpenWrt/LuCI/applications/hd-idle

OpenWrt/LuCI/applications/statistics

OpenWrt/LuCI/applications/ahcp

OpenWrt/LuCI/applications/clamav

OpenWrt/LuCI/applications/ltqtapi

OpenWrt/LuCI/applications/nft-qos

OpenWrt/LuCI/applications/shairplay

OpenWrt/LuCI/applications/attendedsysupgrade

OpenWrt/LuCI/applications/banip

OpenWrt/LuCI/applications/vpnbypass

OpenWrt/LuCI/applications/smartdns

OpenWrt/LuCI/applications/example

OpenWrt/LuCI/applications/wol

OpenWrt/LuCI/applications/radicale

OpenWrt/LuCI/applications/shadowsocks-libev

OpenWrt/LuCI/applications/qos

Current translation status:

CI/CD fails because of privoxy. So this has nothing todo with i18n
Installing templates to /home/build/openwrt/build_dir/target-x86_64_musl/privoxy-3.0.33-stable/ipkg-install/etc/privoxy/templates
id: 'privoxy': no such user
******************************************************************
 WARNING! WARNING! installing config files as root!
 It is strongly recommended to run privoxy as a non-root user,
 and to install the config files as that user and/or group!
 Please read INSTALL, and create a privoxy user and group!
*******************************************************************

authors: feckert weblate


text:
Separate GPU test jobs into general and Ampere-specific

This will be followed by switching the generic runners to be T4
machines. I think we need to roll things out this way with the extra
job also running on A100.
Part of https://github.com/openxla/iree/issues/14169

aaaand we're having capacity issues with a100s. Yet more reason to switch

source: gharchive/pull-request

repo: openxla/iree

license_type: permissive

license_source: github-api


text:
openxpkid cannot start: No next::method 'new' found for SQL::Abstract::More at /usr/lib/x86_64-linux-gnu/perl/5.36/mro.pm line 30

Hello,
I've just upgraded OpenXPKI from previous 3.x release. I've started with Debian upgrade from 10 -> 11 -> 12. So openxpki sources are made from official documentation.
But openxpkid cannot start. in stderr.log I receive such error message:
Exception during server initialization: I18N_OPENXPKI_SERVER_INIT_TASK_INIT_FAILURE; ERROR => No next::method 'new' found for SQL::Abstract::More at /usr/lib/x86_64-linux-gnu/perl/5.36/mro.pm line 30.
, task => dbi (I18N_OPENXPKI_SERVER_INIT_TASK_INIT_FAILURE; ERROR => No next::method 'new' found for SQL::Abstract::More at /usr/lib/x86_64-linux-gnu/perl/5.36/mro.pm line 30.
, task => dbi) at /usr/share/perl5/OpenXPKI/Server.pm line 784.
according to apt-file:
libperl5.36: /usr/lib/x86_64-linux-gnu/perl/5.36.0/mro.pm
So it seems that debian is up-to-date.
I've made a mistake somewhere? I need to install sth more?

Sorry - I did not read carefully that;s not good place for support. I'm closing this issue.

source: gharchive/issue

repo: openxpki/openxpki

license_source: bigquery


text:
Fixes Cannot read property 'openChildren' of undefined

Before, the trace detail code would crash, trying to lookup an unknown
parent. This change tolerates missing parents and backfills tests around
the logic.
Fixes #1085

Tests are great! :-D

authors: adriancole eirslett

repo: openzipkin/zipkin


text:
Add more despeckle filter

This PR adds more despekling filter methods to DSWX-S1.
To capture more narrow water bodies, new algorithms such as Bregman, guided_filter, etc. were implemented.

@seongsujeong I just revised the PR. Please have a look one more time. Thanks for your comments.

repo: opera-adt/DSWX-SAR


text:
Bug 1779313: Enable multiple namespaces sync if catsrc is updated in global ns

Currently, if CatalogSource is updated and connection is Ready,
only the namespace where CatalogSource resides gets resynced. Now, a list
of namespaces that contain Subscriptions that use updated CatalogSource
will get resynced instead.
Signed-off-by: Vu Dinh vdinh@redhat.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 /docs
[ ] Commit messages sensible and descriptive

/retest

@dinhxuanvu
error: endpoint "https://registry.svc.ci.openshift.org" does not support v2 API

/retest

@dinhxuanvu could you open a BZ for this?

@njhale This PR is to address the issue on the existing bug that we were talking about during standup early on this week. I haven't tagged the bug on the title yet.

/retest

/retest

/bugzilla refresh

/retest

/retest

/retest

/retest

/retest

This looks good but the test is failing - holding off for now

/retest

/retest

/retest

/hold
I think a 4.4 bug needs to be made for this.

/retest

/hold cancel

/lgtm

/cherry-pick release-4.3

/cherry-pick release-4.2

authors: awgreene dinhxuanvu ecordell jpeeler njhale


text:
Update AMQ logo to new brand standard

Red Hat brand created a new logo for AMQ.
Before:

After:

cc: @alecmerdler, @SamiSousa

@alecmerdler, any idea why this hasn't merged?

@rhamilto sorry about the notifications, we're working through some CI changes. We'll merge this as soon as we get them sorted

authors: ecordell rhamilto


text:
upgrade controller-runtime to support LabelSelector in fakeClient List func

Feature Request
Is your feature request related to a problem? Please describe.
Currently the sdk is using controller-runtime v0.1.10, which does not support LabelSelector filter in fakeClient List func, only support Namespace filter
https://github.com/operator-framework/operator-sdk/blob/3cf985d4cbc5cebf14430079d3c72176f9866ed5/Gopkg.toml#L33-L35
https://github.com/kubernetes-sigs/controller-runtime/blob/12d98582e72927b6cd0123e2b4e819f9341ce62c/pkg/client/fake/client.go#L91-L114
func (c *fakeClient) List(ctx context.Context, opts *client.ListOptions, list runtime.Object) error {
	gvk, err := getGVKFromList(list, c.scheme)
	if err != nil {
		// The old fake client required GVK info in Raw.TypeMeta, so check there
		// before giving up
		if opts.Raw == nil || opts.Raw.TypeMeta.APIVersion == "" || opts.Raw.TypeMeta.Kind == "" {
			return err
		}
		gvk = opts.Raw.TypeMeta.GroupVersionKind()
	}

	gvr, _ := meta.UnsafeGuessKindToResource(gvk)
	**o, err := c.tracker.List(gvr, gvk, opts.Namespace)**
	if err != nil {
		return err
	}
	j, err := json.Marshal(o)
	if err != nil {
		return err
	}
	decoder := scheme.Codecs.UniversalDecoder()
	_, _, err = decoder.Decode(j, nil, list)
	return err
}

Describe the solution you'd like
here I request to upgrade to at least v0.1.11 to support the LabelSelector in fakeClient List
https://github.com/kubernetes-sigs/controller-runtime/blob/477bf4f046c31c351b46fa00262bc814ac0bbca1/pkg/client/fake/client.go#L93-L123
func (c *fakeClient) List(ctx context.Context, opts *client.ListOptions, list runtime.Object) error {
	gvk, err := getGVKFromList(list, c.scheme)
	if err != nil {
		// The old fake client required GVK info in Raw.TypeMeta, so check there
		// before giving up
		if opts.Raw == nil || opts.Raw.TypeMeta.APIVersion == "" || opts.Raw.TypeMeta.Kind == "" {
			return err
		}
		gvk = opts.Raw.TypeMeta.GroupVersionKind()
	}

	gvr, _ := meta.UnsafeGuessKindToResource(gvk)
	o, err := c.tracker.List(gvr, gvk, opts.Namespace)
	if err != nil {
		return err
	}
	j, err := json.Marshal(o)
	if err != nil {
		return err
	}
	decoder := scheme.Codecs.UniversalDecoder()
	_, _, err = decoder.Decode(j, nil, list)
	if err != nil {
		return err
	}

	**if opts.LabelSelector != nil {
		return filterListItems(list, opts.LabelSelector)
	}**
	return nil
}

I am willing to help submitting a PR for this upgrade if required, thanks

@andy2046 We are already in the middle of upgrading to controller-runtime v0.2.0 in PR https://github.com/operator-framework/operator-sdk/pull/1512 We are blocked until controller-runtime releases a stable v0.2.0 release.

here I request to upgrade to at least v0.1.11 to support the LabelSelector in fakeClient List

I guess depending on when the v0.2.0 release will happen, bumping to v0.1.11 would be good to do. cc @estroz @camilamacedo86 @joelanford What do you think?

@LiliC 0.1.12 was actually released last week, so if we are going to bump to a 0.1.x version, we should shoot for that.
If it's just a matter of bumping that version (and the Kubernetes version) in our deps, and none of the function signatures we use in our scaffolds change, then we can probably go ahead and do this since 0.2.0 isn't released yet.

authors: LiliC andy2046 joelanford

repo: operator-framework/operator-sdk


text:
the version choices of operator-sdk

hello everyone，
I want to extend kubernetes with operator-sdk，but I don't know which operator-sdk version  should I choose.
So I read the doc from github, and it tells me I should go to  this page to find the answer. Then this page tells me to client-go’s compatibility matrix to find the answer.
Now, I have find out that client-go-release-9.0 is compatible with my kubernetes cluster whose version is v1.12.5 . But I still don't know which operator-sdk version should I choose.
Can someone tell me what should I do ?
Thanks!!!!!!!!!!

Does anyone know how to resolve this problem?

Not sure what exactly your ask. Do you want to install operator-sdk and use our command line tool? Could you please specify what exactly you are trying?

Hi @THMAIL,
In general, the version of K8s dependencies which are used to build Operator-SDK is the version to which it is strictly compatible. For example, in Operator-SDK 1.23.0, specifies the k8s dependencies in its go.mod file as 0.24.2. This means SDK 1.23.0 is strictly compatible with k8s 1.24 (Since for each v1.x.y Kubernetes release, the major version of client-go (first digit) would remain 0).
Now let's understand the backwards compatibility matrix with the upstream K8s cluster versions. Here, we use client-go as the mediator. To elaborate, we can follow the steps below:

For the specific version of operator-sdk that you are using, find the corresponding client-go version.
For example, let's take Operator-SDK 1.9.0. It specifies the client-go version 0.20.2 (https://github.com/operator-framework/operator-sdk/blob/v1.9.0/go.mod#L39).
For the client-go version which we have found using step (2), we use the compatibility matrix here, to fetch the corresponding k8s cluster version https://github.com/kubernetes/client-go#compatibility-matrix. Note that client-go version 0.20.2, corresponds to k8s version 1.20.2. Based on the last row of matrix we can infer that:

We have exactly the same features / API objects in both client-go and the Kubernetes 1.20. So k8s 1.20 clusters will work perfectly.
Some APIs which have been removed or added, due to which client-go 1.20 may not exactly work with k8s 1.15 to 1.19 clusters.

Hope this answers your question.

@THMAIL Thanks for bringing this up. We can add documentation that explicitly states the K8s version that is supported by SDK. To automate this with an K8s update, we can pick the version from Makefile and add this as a part of release script. @everettraven will be working on this issue.


text:
add contributing guide

added CONTRIBUTING.md file and updated README contributing section to reference it.
Signed-off-by: Bryce Palmer bpalmer@redhat.com

Pull Request Test Coverage Report for Build 3275402648

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+3.3%) to 70.962%

Totals

Change from base Build 3268290322:
3.3%

Covered Lines:
391

Relevant Lines:
551

💛  - Coveralls

authors: coveralls everettraven

repo: operator-framework/oria-operator


text:
When a bundle fails to unpack, the reason should be surfaced in bundleDeployment

Goal: Re-visit the UX around the HasValidBundle and Installed types, and the printer columns.
The BundleDeployment controllers first try to unpack the desired bundle source before applying those unpacked source manifests. In the case that the desired bundle fails to unpack, the provisioner implementations surface a HasValidBundle status conditions type. When querying for BundleDeployment status locally, the "INSTALL STATE" printer column UX is empty which doesn't properly relay the current state.

I think I'm slightly more interested in the underlying status conditions vs. the printer column UX, at least for now. What does the YAML output of that underlying fail BundleDeployment resource look like?

They are:
apiVersion: v1
items:
- apiVersion: core.rukpak.io/v1alpha1
  kind: BundleDeployment
  metadata:
    creationTimestamp: "2022-07-08T13:42:46Z"
    generation: 1
    name: fail
    resourceVersion: "1132"
    uid: 552541ff-a32b-402a-9b0d-ae4ee7f70c83
  spec:
    provisionerClassName: core.rukpak.io/plain
    template:
      metadata: {}
      spec:
        provisionerClassName: core.rukpak.io/plain
        source:
          local:
            configMap:
              name: failc7knd
              namespace: default
          type: local
  status:
    activeBundle: fail-6b974bf987
    conditions:
    - lastTransitionTime: "2022-07-08T13:42:46Z"
      message: Failed to unpack the fail-6b974bf987 Bundle
      reason: UnpackFailed
      status: "False"
      type: HasValidBundle
- apiVersion: core.rukpak.io/v1alpha1
  kind: BundleDeployment
  metadata:
    creationTimestamp: "2022-07-08T13:43:40Z"
    generation: 1
    name: valid
    resourceVersion: "1259"
    uid: 8669d3f0-f01f-455f-b10f-bd07c4addeeb
  spec:
    provisionerClassName: core.rukpak.io/plain
    template:
      metadata: {}
      spec:
        provisionerClassName: core.rukpak.io/plain
        source:
          local:
            configMap:
              name: validhnmdv
              namespace: default
          type: local
  status:
    activeBundle: valid-8594776745
    conditions:
    - lastTransitionTime: "2022-07-08T13:43:40Z"
      message: Successfully unpacked the valid-8594776745 Bundle
      reason: UnpackSuccessful
      status: "True"
      type: HasValidBundle
    - lastTransitionTime: "2022-07-08T13:43:45Z"
      message: instantiated bundle valid-8594776745 successfully
      reason: InstallationSucceeded
      status: "True"
      type: Installed
kind: List
metadata:
  resourceVersion: ""

Given the plain provisioner knows which bundle needs to exist at any point in time, and we already check for whether that "active" bundle is reporting an unpacked phase yet, I think we can extend that logic to ensure we're propagating a more reasonable condition message and/or reason:
...
  status:
    activeBundle: fail-6b974bf987
    conditions:
    - lastTransitionTime: "2022-07-08T13:42:46Z"
      message: Failed to unpack the fail-6b974bf987 Bundle
      reason: UnpackFailed
      status: "False"
      type: HasValidBundle

Here, the "Failed to unpack the .... Bundle" would require me to GET that bundle's metadata.Name, and inspect it further for why it failed. I was suggesting that we should be propagating that information back to the BundleDeployment status instead to reduce the number of manual steps for invalid bundles. Thoughts?

Here is the status in the bundle.
  status:
    conditions:
    - lastTransitionTime: "2022-07-08T13:42:46Z"
      message: 'get objects from bundle manifests: read ".gitignore": error unmarshaling
        JSON: while decoding JSON: json: cannot unmarshal string into Go value of
        type map[string]interface {}'
      reason: UnpackFailed
      status: "False"
      type: Unpacked

There are some options:

append the bundle condition message to the bundledeplpyment condition message.
add the BundleConditions in the BundleDeploymentStatus and copy the bundle conditions into it
add a new bundledeplpyment condition type BundleConditionUnpacked and put the bundle unpack condition into the bundledeployment condition.

We still need to have the bundle name somewhere in the BundleDeploymentStatus.  We may need to rename the activeBundle to just bundle and have another field bundleStatus to hold the status of the bundle.

We still need to have the bundle name somewhere in the BundleDeploymentStatus

Hmm. Do we have an existing issue for this? I'd guess I need to see explicit use cases for why we'd need an explicit status field for the "active" bundle's metadata. What we can do in the short term is wrap that "Failed to unpack the fail-6b974bf987 Bundle: ..." with the underlying Bundle's message to still encode that "active" Bundle identifier in the status $somewhere.

OK.  We can reformat the HasValidBundle condition message to include the bundle Unpacked condition message and the bundle name when unpack failed.
Is it enough for this issue?  Do we need the print column change, too?

authors: akihikokuroda timflannagan

repo: operator-framework/rukpak


text:
Support logical deletion of objects when deleting BundleInstances

The order in which objects composing operators or other applications on-cluster are removed matters for the successful removal of the application from the cluster. The default behavior is to mark all objects for deletion and remove them when the parent resource, in this case the BundleInstance, is deleted. However a more fine grained removal policy may be desirable, which may be achievable entirely by finalizers or potentially by other resources.
See https://github.com/operator-framework/operator-lifecycle-manager/issues/2235 for an example of an issue that can arise when deleting objects all at once: if the roles are removed before the deployment the operator loses the ability to cleanup after itself.
The goal is to support an ordered removal of objects related to the installation such that the cluster can be in the same state as it was prior to the installation when the operator is uninstalled.

Moving to 0.3 milestone -- this is something we definitely want to support sooner rather than later, to ensure a clean teardown of operators and other applications.

Moving to a design ticket to architect this feature out.

Move to backlog for now.


text:
IPsec VTI - Potential lockout risk if policies isn't unchecked and configuration is applied

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

[x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.
When creating a VTI IPsec tunnel, there can be a fatal user error that will install a 0.0.0.0/0 ::/0 ipsec kernel policy. It happens when "policies" in a connection "children" isn't deactivated and then applying the configuration.
Afterwards, the firewall won't respond to any network traffic and you have to go into the local terminal to stop the strongswan service. Even a reboot won't help in that case, since strongswan will automatically load all configuration after boot.
Describe the solution you like
There could be an additional popup window or a warning when a "reqid" is explicitly set in the children. A user would probably only set a static reqid if they have created a VTI interface beforehand and plan on using a routed IPsec tunnel. The popup could warn them about the potential lockout if policies isn't unchecked and the configuration is applied.
Describe alternatives you considered
Changing the default of "policies" to "0". Then a user would have to explicitly enable policies when they want to use them. It would reduce the risk of a total lockout. But it would probably cause confusion for users who just want to create a simple policy based tunnel.

Isn't this also the case with legacy implementation?

I think we forgot to require a policy in this case, which makes it a bit too easy to trip over it.

@Monviech I'm not sure I do understand the issue correctly, while reading https://docs.strongswan.org/docs/5.9/swanctl/swanctlConf.html I would expect if we keep local_ts and remote_ts  empty the tunnel endpoint addresses are used (which should be more or less safe).

@AdSchellevis
I was meaning this as reference, the warning here:
https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn-route.html#children
I have managed to lock myself out one time yesterday in my test setup and had to stop the strongswan daemon.
Right now, I tried my best to replicate it with all kinds of different wrong inputs and I can't replicate it anymore. If I try my hardest and can't break it I guess there is no issue and it was only a fluke.

Unfortunately adding a warning requires javascript on the frontend part, I'm not against it, but it's not high on my priority list. Preventing an exact match from happening with a validation is easier, but still leaves options to kill your setup (overlaps of any kind are problematic)

Thanks for your time, I will close this as I can't replicate it anymore.

authors: AdSchellevis Monviech mimugmail

repo: opnsense/core


text:
tasks not being run automatically

Tasks can only be ran manually. scheduled tasks don't work, nothing shows in logs

everything is setup to how it is in your screenshot, I've also created another task that runs every minute as a test, neither work.
what do you mean by having enough page hits though?

Had to set it up as a cronjob for it to work, thanks!

repo: opt-natter/discord-mybb-sync

license: mit


text:
Add JPype support

This PR adds JPype support, which allows it to be used with regular Python. It is approximately 3 times slower than the GraalVM version, which is 10 time slower than Java.

Any issues in JPype that I need to address?   Rough spots, unexpected behaviors, needed improvements?

@Thrameos Thanks for your work on maintaining JPype! Some issues I encountered:

Ambiguous overloads when there both a varargs and a specific # of args:
If I remove the brackets around the joiners from one of the constraints like so:

    return constraintFactory \
            .fromUniquePair(LessonClass,
            # ... in the same timeslot ...
                Joiners.equal(lambda lesson: lesson.timeslot),
            # ... in the same room ...
                Joiners.equal(lambda lesson: lesson.room)) \
            .penalize("Room conflict", HardSoftScore.ONE_HARD)

I get the following
TypeError: Ambiguous overloads found for org.optaplanner.core.impl.score.stream.InnerConstraintFactory.fromUniquePair(java.lang.Class,org.optaplanner.core.impl.score.stream.bi.SingleBiJoiner,org.optaplanner.core.impl.score.stream.bi.SingleBiJoiner) between:
	public default org.optaplanner.core.api.score.stream.bi.BiConstraintStream org.optaplanner.core.api.score.stream.ConstraintFactory.fromUniquePair(java.lang.Class,org.optaplanner.core.api.score.stream.bi.BiJoiner,org.optaplanner.core.api.score.stream.bi.BiJoiner)
	public default org.optaplanner.core.api.score.stream.bi.BiConstraintStream org.optaplanner.core.api.score.stream.ConstraintFactory.fromUniquePair(java.lang.Class,org.optaplanner.core.api.score.stream.bi.BiJoiner[])

I work around this by putting square brackets around the Joiners, which remove the ambiguity (but is more painful to write).
This is caused by the following interface: https://github.com/kiegroup/optaplanner/blob/28762e3b9c8ffc6c5637b222bfe9d4674c69db37/optaplanner-core/src/main/java/org/optaplanner/core/api/score/stream/ConstraintFactory.java#L139-L185 ; the reason for the overloads with specific # of arguments is: "This method causes Unchecked generics array creation for varargs parameter warnings, but we can't fix it with a {@link SafeVarargs} annotation because it's an interface method. Therefore, there are overloaded methods with up to 4 {@link BiJoiner} parameters." In Java + GraalVM, if there are two methods that can be used, the more specific statically known method is used unless an arg was cast to a less specific type (that is, the three args version would be preferred over the varargs version).

Would be nice to have an opaque pointer to pass between OptaPlanner and Python. I get around this by using the id of the Python object, which is the C pointer to its memory address (Python does ctypes.cast(objectId, ctypes.py_object).value to get back its actual value, and passes id(pythonObject) to Java). Due to this, I also need to keep a set of references to clones so I do not segfault (as the Python Garbage Collector will collect the clone since it is blissfully unaware that Java still has references to it).

Overriding __getattr__ in @JImplementationFor can easily cause infinite recursion, since it is called to resolve Java methods. I get around this by passing the Object back to Java in order to call it methods.

Ability to use Java annotations as decorators and a method to get said Java annotations on a Python Object. OptaPlanner uses annotations to discover what are the planning variables, sources for the planning variables etc. Although I don't expect to be able to pass a Python class/method directly to Java, being able to read Java Annotations without redefining them as decorators would simpify the code. (Currently, I generate the bytecode for the Java wrapper of Python classes, which also has the annotations OptaPlanner needs in order to read the model).

It is annoying Python lists do not automatically cast to Java Lists. And that if those lists has lists, you also need to map those lists to Java Lists; etc. Same for Python dict to Java Map.

As for the specific overloads, that is established by Java code in org.jpype.    It is possible to adjust those rules.   If two methods match and neither has the other in the override list then the error is issues.   In order to make the more specific one with two arguments be listed as more specific the code in jpype/native/java/org/jpype/manager/MethodResolution.java.   I have tried to keep the rules matching Java whereever possible.
Though I agree that is appears to be a miss in this case as the following code compiles in Java.
public class Foo
{
  static void foo(Object... o)
  {
  }

  static void foo(Object o, Object o2)
  {
  }

  static void bar()
  {
    Object o = null, o2 = null;
    foo(o, o2);
  }
}

As for an opaque pointer, there is a trick using JProxy that allows you to use a generic empty interface like Serializable to hold a Python object in Java and retrieve.  It has the significant downside that if that object is a container which is holding Java objects you will produce an irresolvable reference loop.   Though the same thing will happen with your solution so either way reference loops will be encountered.   Java lacks any hooks to allow a foreign reference counting system to be handled.  I have tried messing with the Java Remote protocols to see if I can get Python and Java to play nice, but thus far have not come up with anything workable.
The JProxy can be combined with a weak-ref to allow for cycle free activity, but you have to hold the Python reference so that it doesn't go away.
For details on how to hold Python objects as opaque objects see the section "Proxying Python objects" in the users guide.

With regard to __getattr__, yes that is likely a bad method to overload.  Python has differences between __getattribute__ and __getattr__ that I was not well aware of at the time.   It may be possible to improve the pattern in JPype to make it a bit more safe.  If you can construct a small test problem the demonstrates the issue I can see if there is a resolution.

With regard to annotations, I have access to a lot of those sort of features using reflection, so it is possible that we can recognize something that should operate as annotation and make automatically create a Python decorator.   I suppose it would be best if you gave an example of the preferred syntax that I can work from.   I cant guarantee that I can get it to work, but I certainly can get it to try.

With regard to Python lists and maps.   Those features are working in the epype version of jpype in which Java can call Python code.   You can create a customizer within Java and it will automatically write bytecode using ASM to make a Java version of any Python class.   I customized all the Python containers to map automatically into the corresponding Java container types.   It was an effort I worked on about 6 months back which I am taking a break from because I have not gotten a critical mass of developers to help with.   It was easy to add a foreign call interface from Python to Java and I successful demonstrated it.  However, to be viable I need test cases for every Python call exercised from within Java.    If I can find enough people that are willing to put in the time to develop that test bench it can be releases.   As of now it remains a toy demonstration.   I am pleased with the syntax and as it makes python.lang a first class type tree in Java and lets you mix and match Python and Java code pretty easily (like calling matplotlib from Java), but it was outside the scope of my job responsibilities so I could not support the time without other developers assistance.
There are some rough edges.   For example currently Python strings are copied to Java strings when passed, but when the wrapper layer is introduced the instead become CPythonString which derives from CharSequence types.  I can still define automatic converters so that Python types convert rather get passed as native Python types but that causes ambiguities thus it does lead to potential code breakage.   So it can't really be released until JPype 2.0.   Same thing happens with int, float, and Number as Python natives map the Number not specific types.   This means code like placing a native Python type in a HashMap<String, Integer> with obj['foo']= 1 ends up with Number rather than Integer because reflection does not expose the type so all I see is "Object" and the base mapped item will be CPythonInt type.   All of it is entirely doable, just more effort that I can afford right now.
My other hesitancy is that just like allowing opaque Python objects into Java (which is doable with the JProxy), this would make it way easier to write reference looped codes.   And I have not found any documentation in Java that would make it possible to resolve this well.   I need much greater levels of support from OpenJDK to make that possible at which point I would likely be recreating Graalvm.

With regard to speed,  I have cut the overhead by several orders of magnitude already, but my hotspots may not match your usage.  Every time you go over the JNI boundary there is a marshalling cost so cutting trips is important.    If you have a large number of similar items or such passing through adding a cache so that I don't have to go back through JNI to get the same result can speed things up.
For example, we use caching on the method resolution which is the largest overhead in the system.   Every time a method is called we have to pay the cost of seeing which overload in Java is required and how to convert each of the arguments.  I added a cache so that if the same argument types come through the same resolution method is called (bypassing the overload resolution process.)   This does prevent resolving overloads for things like "list of strings" vs "list of ints" as the type system only sees Python list and not the contents.  And if you do something like alternating between two overloads "foo(String); foo(int); foo(String); foo(int)" it will not get the benefits of the cache which forces the resolution.   I have planned to expose methods more directly so that you can pull out a specific overload and use it repeatedly which bypasses the resolution process entirely, but having found a compelling use case.
Specific paths such as marshalling large numbers of primitives, converting many items on lists for list comprehensions and the overload resolution for tight loops have been dealt with already at user request.   My benchmarking indicates that JPype is the fastest interface of its type with its security ( you can go faster, but you would have to skip safety checks leading to segfaults) in all the places that I checked.   But if you can identify another path which is resulting in a bottle neck, I would be happy to see about optimizing it.    For example sometimes having more arguments pass from Java to Python can save a few round trips through JNI, but unless I see that it is a bottle neck at a specific location I won't cut the trips as the complexity of the interface grows with arguments.

@Thrameos Thanks for your responses. Using the JProxy(java.io.Serializable) trick improved performance a bit (~1/2 speed of GraalVM). There is a lot of calls between Java and Python with a Constraint Streams which I can't do anything about unless I reimplement OptaPlanner in Python (which I do not want to do). Using a EasyConstraintProvider might actually be faster than Constraint Streams for this situlation (since it only one transfer per score calculation versus several ; no benchmarking done yet). The speeds are pretty good considering the transfer between Java/Python (I'm not expecting it to match GraalVM speeds; that is pretty close to impossible). However, even the speed that the GraalVM implementation runs at is too slow for most use cases. The only way I see to increase the speed to the point of it being usable is to make the user pass strings which are compiled into Java functions and don't go back into Python once the Solver starts. However, then the user cannot use NumPy, their own functions, etc. and don't get IDE support.

(another note on __getattr__ on a JImplementationFor: returning a python Object will yield a TypeError: Return value is not compatible with required type. I can't use a JProxy here since the same code is also called within Python code, which doesn't know how to get attributes from the JProxy (thus I needed to create PythonRef)); additionally the same object must map to the same PythonRef for constraints to work.

Sounds like the issue with speed is trying to use Python code to implement a functional interface which is being called in a tight loop within the optimizer.   That is certainly an issue as the cost of Java calling Python code requires a lot of marshalling (look up the function, do the type equivalence of each argument, execute the Python code, then marshal the return type).   There may be some potential improvements on that path but admittedly it will always be pretty heavy.   There may be some potential caching there but I really don't see more than 20% savings unless I missed something really drastic.
My approach if I was doing this particular problem using the  epypj branch would be to use the fact that all Python methods can be executed from within Java to convert the Python byte code into a equivalent Java bytecode which calls through jpyffi.   Depending on the code complexity and the amount of optimizations that can be performed it may be possible to get close to native Java speed.   If the bytecode contains unrecognized codes that can't be translated then it just falls back to the old slower path of marshalling to Python.   Unfortunately I only made some initial stabs at that  because the Python bytecode is way less stable than Java so I wasn't sure I wanted to try that for long term support.   But in theory the JImplements could check each each method to see if the Python byte codes can be optimized to Java bytecodes and place a stub that repoints to Java in place of the Python version.   The byte code translator can be written in Java (faster) or Python (more flexible) and use the ASM.   But as it stands until JPype includes jpyffi (Java to Python foreign function interface) we are pretty limited in how to address this.
The unpleasant alternative is to use a Factory that allows the user to create Java code from within Python by assembling commands to make a Functional interface object of some kind.   That defeats the point of writing in Python syntax and unworkable if the classes to be implemented are not lambdas.   Alternatively using the Java compiler to implement short sections of code loaded in the classpath is workable, but undesirable from the user prospective.   Calling the Java compiler from within Python to produce a class is slow and only works if a full copy of the JDK is available.

@Thrameos Thanks for the tips and comments. If I was determined enough to try to make it usable, I do think the python bytecode -> java bytecode is a good approach (I already do a fair bit of Java bytecode writing). However, it is a lot of work (Python has over 100 bytecode instructions). I'm merging this PR; if I have any further problems/suggestions, I will post them to the JPype repo.

authors: Christopher-Chianelli Thrameos

repo: optapy/optapy


text:
Workshops 141 and 142 updates

Workshops 141 and 142 updates:

Added folder and files for green button hosted version of Workshop 141 "Load and Analyze your Data with Autonomous Database"

Initial updates for Workshop 142 "Manage and Monitor Autonomous Database"

The new adb-data-safe.md file is for the new lab "Secure Your Data Using Oracle Data Safe" in Workshop 142 "Manage and Monitor Autonomous Database"

The new adb-data-safe.md file is for the new lab "Secure Your Data Using Oracle Data Safe" in Workshop 142 "Manage and Monitor Autonomous Database"

repo: oracle-livelabs/adb


text:
Java TZUpdater Sprint - WMS 11461

WMS 11461
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[x] All filenames are lower case (including folders, images, files, etc.)
[x] Filenames are descriptive
[x] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[N] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[x] Image references in markdown contain an alternate text

I have updated the filenames per your request. I do not know why the extensions were capitalized since they were lower-case on my machine, but since I changed the filenames the issue seems to be resolved.

repo: oracle-livelabs/sprints


text:
"illegal option -- p" when creating EE database image

Hi!
WIth the actual commit i get the error when running following command:
sudo ./buildDockerImage.sh -v 12.1.0.2 -e -i -p XXXXXXX
./buildDockerImage.sh: illegal option -- p
This option seems to be remove when the database instance part moved from the image to the container but
https://github.com/oracle/docker-images/blob/master/OracleDatabase/README.md
has to be updated to reflect this change.
Kind regards
Torsten Kleiber

Thank you, the update was missed in the README.

authors: gvenzl tkleiber

repo: oracle/docker-images


text:
Failling to load Source from URL on MS-Windows

Hi,
there appears to be an issue with opening file:/ URL Sources on MS-Windows:
org.graalvm.polyglot.PolyglotException: java.nio.file.InvalidPathException: Illegal char <:> at index 2: /d:/dev/java/issue-polyglot/target/classes/empty.mjs
    at sun.nio.fs.WindowsPathParser.normalize (WindowsPathParser.java:182)
    at sun.nio.fs.WindowsPathParser.parse (WindowsPathParser.java:153)
    at sun.nio.fs.WindowsPathParser.parse (WindowsPathParser.java:77)
    at sun.nio.fs.WindowsPath.parse (WindowsPath.java:92)
    at sun.nio.fs.WindowsFileSystem.getPath (WindowsFileSystem.java:229)
    at java.nio.file.Path.of (Path.java:147)
    at java.nio.file.Paths.get (Paths.java:69)
    at com.oracle.truffle.polyglot.FileSystems$NIOFileSystem.parsePath (FileSystems.java:759)
    at com.oracle.truffle.api.TruffleLanguage$Env.getPublicTruffleFile (TruffleLanguage.java:2777)
    at com.oracle.truffle.js.runtime.objects.DefaultESModuleLoader.getCanonicalPath (DefaultESModuleLoader.java:203)
    at com.oracle.truffle.js.runtime.objects.DefaultESModuleLoader.loadModule (DefaultESModuleLoader.java:191)
    at com.oracle.truffle.js.parser.GraalJSEvaluator$ModuleScriptRoot.evalModule (GraalJSEvaluator.java:282)
    at com.oracle.truffle.js.parser.GraalJSEvaluator$ModuleScriptRoot.execute (GraalJSEvaluator.java:277)
    at org.graalvm.polyglot.Context.eval (Context.java:379)
    at io.App.main (App.java:44)

The same works fine on Linux.
How to reproduce with Maven.

Create an empty io.App project with maven with the gralljs dependency in pom.xml:

 <dependencies>
    <!-- https://mvnrepository.com/artifact/org.graalvm.js/js -->
    <dependency>
      <groupId>org.graalvm.js</groupId>
      <artifactId>js</artifactId>
      <version>21.3.0</version>
    </dependency>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
  </dependencies>

Create an empty module js file at src/main/resources/empty.mjs
Create the main App at src/main/java/io/App.java  to import the empty.mjs file

package io;
import org.graalvm.polyglot.*;
import java.net.URL;

public class App
{
    public static void main( String[] args )
    {
        Context ctx =
	    Context.newBuilder("js")
            .allowAllAccess(true)
	    .build()
            ;

        try {
            App obj = new App();
            URL resource = obj.getClass().getResource("/empty.mjs");
            System.out.println(":res " + resource);
            ctx.eval( Source.newBuilder("js", resource)
                      .build());
        }
        catch(java.io.IOException ex)
            {
                System.err.println(":exception :io " + ex);
            }
    }
}

Create the jar with mvn package
Run main with  mvn exec:java -Dexec.mainClass="io.App".

You should get the above error on MS-Windows, but it finishes with success on Linux.
The issue appear to be with getCanonicalPath trying to .getPath() from the URL source,
public abstract String getPath()

The fully qualified name of the source. In case this source originates from a File or TruffleFile, then the path is the normalized, canonical path. If canonicalizePath(false) is used when building the source then TruffleFile.getPath() is used instead. If the source originates from an URL, then it's the path component of the URL.

which returns the path component of the URL. Though the path component of a file:/ on MS-Windows starts with a leading / instead of a drive letter, and thus the error, e.g. /d:/dev/java/issue-polyglot/target instead of d:/dev/java/issue-polyglot/target as per from error trace above.
Not sure what the right solution is for this, but using com.oracle.truffle.api.source.Source.getPath() does not seem to be compatible across all platforms.
Thanks

@ikappaki thanks for reporting this -- a fix was merged here. Let us know if you still have issues on windows.

authors: eleinadani ikappaki

repo: oracle/graaljs


text:
How to obtain or calculate the code coverage of a JS function executed once

@eleinadani @wirthi  would like to ask, I execute a piece of JS code, such as the following example:
public class ExecutionListenerTest1 {
    public static void main(String[] args) {
        try (Context context = Context.create("js")) {
            String js="async function main(params) {\n" +
                    "    if(params.test){\n" +
                    "        var a = 1;\n" +
                    "        a++;\n" +
                    "        return a;\n" +
                    "    }else{\n" +
                    "        var b = 10;\n" +
                    "        b++;\n" +
                    "        return b; \n" +
                    "    }\n" +
                    "}";
            context.eval("js", js);
            Param param=new Param();
            param.test=true;
            context.getBindings("js").getMember("main").execute(param);

            param=new Param();
            param.test=false;
            context.getBindings("js").getMember("main").execute(param);
        }
    }

    public static class Param{
        public boolean test;
    }
}

The specific implementation of the JS function will execute different branch codes according to the value of the input parameter. I want to get how many lines of code are covered by the execution of the JS function this time, or the percentage of the total function implementation (code coverage), this Is there a way to get the value now?

Hi @ruanzhi
We don't store comprehensive coverage information in the engine. Of course, as part of our AST interpreter some information might be available here and there (e.g. we profile branches, but typically in a binary fashion, not as a count; we count how often call sites are executed for inlining decisions, etc.).
The way to solve that problem is using an Instrument. See https://www.graalvm.org/graalvm-as-a-platform/implement-instrument/ That page even provides a CoverageExample.
Best,
Christian

authors: ruanzhi wirthi


text:
Cannot import static variables from abstract class

Environment

os: MacOS 11
GraalJS version: 22.1.0.1
jvm version: openjdk 18

Bug reimplementation

Create an abstract class called ABCD, and create a static variable in it. I'm going to name this variable TEST

package org.example;

public abstract class ABCD {

    public static final int TEST = 1;

}

Create a class called Test and extends ABCD

package org.example;

public class Test extends ABCD {
}

Then, Create Context and run

package org.example;

import org.graalvm.polyglot.Context;
import org.graalvm.polyglot.HostAccess;
import org.graalvm.polyglot.PolyglotAccess;

public class Main {
    public static void main(String[] args) {
        Context context = getContext();
        context.eval("js", "console.log(org.example.Test.TEST)");
    }

    public static Context getContext() {
        return Context.newBuilder("js")
                .allowHostAccess(HostAccess.ALL)
                .allowPolyglotAccess(PolyglotAccess.ALL)
                .allowExperimentalOptions(true)
                .allowIO(true)
                .option("js.foreign-object-prototype", "true")
                .option("js.syntax-extensions", "true")
                .option("js.nashorn-compat", "true")
                .option("js.ecmascript-version", "staging")
                .allowCreateThread(true)
                .allowHostClassLoading(true)
                .allowHostClassLookup(a -> true).build();
    }
}

expected result

1

actual result

undefined

Your test-case does not work because your are trying to access a static field through a class that does not define it. While this is a valid syntax in Java, we do not support this bad practice in our Java interoperability support. Note that there is no problem with the fact that you are using an abstract class. Your test-case works if you change console.log(org.example.Test.TEST) to console.log(org.example.ABCD.TEST).

I understand for now. Let's close this issue for now. However, if possible, I will actively support the amendment!


text:
Add support for shared archetype resources

Add support shared archetype resources.
This can be used to include shared files such as Dockerfile or mvnw.

Given that we have created a net new V2 engine, we won't implement this feature.

repo: oracle/helidon-build-tools


text:
Profile based configuration support for microprofile-config.properties

I am not be able to find any detailed documentation on profile based microprofile-config.properties support with Helidon. My requirement is to have different profile support based on my deployment stages like dev, test and prod.
Do we have any support for various deployment configuration passed during runtime? Either starting the server or set during boot? (-Dfile=xxx)
Can you give me some pointer? Might be a gap in the documentation

Duplicate of #1416

Duplicate of https://github.com/oracle/helidon/issues/3093
Support for configuration profiles in Helidon MP has been merged.
This will work according to MP specification (part of MP Config 2.0).

support for profile specific files (microprofile-config-dev.properties)
support for profile specific properties (%dev-app.greeting=Hello Dev)

Closing this issue as support is merged and will be part of 2.3.1

repo: oracle/helidon


text:
Investigate asciidoclet

Investigate writing javadoc in asciidoc using https://github.com/asciidoctor/asciidoclet
This may allow authoring complex content in javadoc (e.g. table). It might be very useful as we ramp-up the javadoc documentation.

See https://github.com/oracle/helidon/pull/173


text:
The MP Metric absolute=true annotation field is not removing package prefix for class level metrics

Environment Details

Helidon Version: 1.2.0
Helidon MP
JDK version: 1.8.0_211
OS: MacOS 10.13.6

Problem Description
The MP Metric absolute field set to true, is but the metric name still has the path prefix for class level metrics.  Here is the Microprofile spec file:///Users/pmackin/Downloads/metrics_spec-1.1%20(1).html#_fields
Steps to reproduce
Create a class level @Counted annotation as shown in the sample class below.  Add this class to the Quickstart MP to test this.
Build and run the application then issue the following:
curl http://localhost:8080/cards/birthday
curl http://localhost:8080/cards/holiday
curl http://localhost:8080/metrics/application
Here is a sample of the output, notice the member level metrics do not have the package prefix.
{
"birthday-cards": 1,
"holiday-cards": 1,
"io.helidon.examples.quickstart.mp.all-cards.GreetingCards": 2
}
package io.helidon.examples.quickstart.mp;
import java.util.Collections;
import javax.enterprise.context.RequestScoped;
import javax.json.Json;
import javax.json.JsonBuilderFactory;
import javax.json.JsonObject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.core.MediaType;
import org.eclipse.microprofile.metrics.annotation.Counted;
@Path("/cards")
@RequestScoped
@Counted(name = "all-cards", monotonic = true, absolute = true) // <1>
public class GreetingCards {
private static final JsonBuilderFactory JSON = Json.createBuilderFactory(Collections.emptyMap());
@Path("/birthday")
@GET
@Produces(MediaType.APPLICATION_JSON)
@Counted(name = "birthday-cards", monotonic = true, absolute = true)
public JsonObject birthday() throws InterruptedException {
return createResponse("Here are some birthday cards ...");
}
@Path("/holiday")
@GET
@Produces(MediaType.APPLICATION_JSON)
@Counted(name = "holiday-cards", monotonic = true, absolute = true)
public JsonObject holiday() throws InterruptedException {  // <2>
return createResponse("Here are some holiday cards ...");
}
private JsonObject createResponse(String msg) {
return JSON.createObjectBuilder().add("message", msg).build();
}
}

Seems like a bug in MetricUtil::getMetricName.

authors: pfmackin spericas


text:
Update doc for Tags of WebLogic Server Single Node on VM in oracle doc

Currently, the following offers support Tags:

WebLogic Server Single Node on VM
WebLogic on VM
WebLogic Cluster on VMs

Documentation Update
This issue is to update the documentation for the following resource:
Deploy Oracle WebLogic Server Without Administration Server on a Single Node
URL: Oracle WebLogic Server Single Node on Microsoft Azure IaaS

UI Change
The Tags section will now appear as follows:

Documentation Changes
Change 1:
Location: Modify the content table in the document as shown below.

Expected Result:
To deploy Oracle WebLogic Server without an Administration Server on a single node, provide the required information in the following resource blades:

Basics
Tags
Review + Create

Change 2:
Location: After the table and before "After you specify the required details, click Next: Review + Create."
Add the following content about the Tags blade:
Tags
Use the Tags blade to provide tags for resources and resource groups. Tags are name/value pairs that allow you to categorize resources and consolidate billing by applying the same tag to multiple resources and resource groups. Learn more about tags
Table 2-2 Fields in the Tags Blade

Name
Value
Resource

Tag name (name/value pair)
Tag value (name/value pair)
Resources available for tagging in this offer

I have reviewed and approve the proposed changes to the documentation.

I have reviewed and approve the proposed changes to the documentation.

authors: edburns galiacheng

repo: oracle/weblogic-azure


text:
TokenIter/Caravan should be a mutable reference

I think this is the case.

https://github.com/orangutanrider/waymark_relations/pull/50


text:
Feature/my-feature-branch

Merge request

I think this is accidently created in this project or not?

closing the PR. It does not contain any content for the project.

authors: Rendanic bindhumurugesan

repo: oravirt/ansible-oracle


text:
Runtime Error

On a fresh install today I am unable to get past the login screen (when I hit Enter to login the app crashes and throws npm errors)
Debian 3.16.0-4-amd64
ipfs 0.4.5-dev (built from go-ipfs master, ipfs daemon --enable-pubsub-experiment works fine when run from command line)
npm@3.10.9
node@v7.2.0 (also tried v6.9.2 and v6.0.0)
Here's my npm debug log: npm-debug.txt I thought maybe the errors were due to using node v7, so I downgraded to node v6.9.2 but got the same errors:  npm-debug_v6.9.2.txt It appears to be failing on the call to npm run electron
Probably unrelated, but I also received the following warnings during npm install:
npm WARN deprecated lodash.contains@2.4.3: This package is discontinued. Use lodash.includes@^4.0.0.
npm WARN deprecated node-uuid@1.4.7: use uuid module instead
npm WARN prefer global coffee-script@1.10.0 should be installed with -g

I can reproduce this:
[ERROR] orbit-electron: TypeError: IpfsDaemon is not a constructor

links to this:
https://github.com/haadcode/orbit/blob/master/index.js#L130
@haadcode, has the IpfsDaemon interface changed ? Will try to fix it but diving into IpfsDaemon object asap
Thanks for the report @rsynnest

Thanks for reporting this @rsynnest. Not sure what's going on here, the logs don't tell much. Could you run it with LOG=debug npm run electron and drop the output here?

[ERROR] orbit-electron: TypeError: IpfsDaemon is not a constructor

@theobat This sounds like dependency conflict. The interface for IpfsDaemon was indeed changed, see https://github.com/haadcode/ipfs-daemon. So what I take from this report is that there's an old version of ipfs-daemon there and it's trying to use that.

My mistake, I thought that the logfile would be more verbose than stdout. I've pasted stdout logs below (after running LOG=debug npm run electron).
The core issue seems to be:
Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: Assertion `map->l_init_called' failed!

So, looks like an error in dynamic linking? I'm running glibc 2.19-18+deb8u6 , not sure if this is an issue in ipfs or what. Full stdout error logs below:
> orbit@3.2.0 electron /home/rsynnest/src/orbit
> LOG=debug IPFS_FD_MAX=4096 $(npm bin)/electron .

2016-12-07T17:48:09.107Z [DEBUG] orbit-electron: Run index.js in 'debug' mode
2016-12-07T17:48:09.924Z [DEBUG] orbit-electron: Received 'disconnected' event from renderer process
2016-12-07T17:48:23.466Z [DEBUG] orbit-electron: Received 'ipfs-daemon-start' event from renderer process
2016-12-07T17:48:23.470Z [DEBUG] ipfs-daemon: Initializing IPFS daemon
2016-12-07T17:48:23.470Z [DEBUG] ipfs-daemon: Using IPFS repo at '/home/rsynnest/.config/orbit'
2016-12-07T17:48:24.065Z [DEBUG] ipfs-daemon: Starting IPFS daemon
Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: Assertion `map->l_init_called' failed!

npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/home/rsynnest/.nvm/versions/node/v7.2.1/bin/node" "/home/rsynnest/.nvm/versions/node/v7.2.1/bin/npm" "run" "electron"
npm ERR! node v7.2.1
npm ERR! npm  v3.10.10
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! orbit@3.2.0 electron: `LOG=debug IPFS_FD_MAX=4096 $(npm bin)/electron .`
npm ERR! spawn ENOENT
npm ERR!
npm ERR! Failed at the orbit@3.2.0 electron script 'LOG=debug IPFS_FD_MAX=4096 $(npm bin)/electron .'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the orbit package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     LOG=debug IPFS_FD_MAX=4096 $(npm bin)/electron .
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs orbit
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls orbit
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/rsynnest/src/orbit/npm-debug.log

Thank you @rsynnest, this helps a lot! :)
That said, I have no idea what this is about. Seems like it happens when starting the IPFS daemon. I see you're using node 7, could you give it a try with 6 and see if it occurs with that too?

Inconsistency detected by ld.so: dl-close.c: 762: _dl_close: Assertion `map->l_init_called' failed!

@whyrusleeping does that tell you anything? @dignifiedquire could this be related to compiling crypto on Linux?

@haadcode I tried node 6 before since that's what's explicitly listed in the README. Both node 6.0.0 and node 6.9.2 give the exact same errors as pasted above. I'm also able to reproduce this on another machine that is also running Debian.

ok. thanks for trying that. will need to investigate.

Small update:
I am able to install and run Orbit on Arch Linux. I installed everything using the exact same methods (installed go-ipfs from source). Here are some version numbers for various tools that might affect build:
Arch
go 1.7.4
gcc 6.2.1
glibc 2.24
ipfs 0.4.5-pre1
Debian
go 1.7.4
gcc 4.9.2
glibc 2.19
ipfs v0.4.5-dev
Regarding the ipfs version, I'm unsure if this is just a different name for the same version or if there is some minor version difference even though I installed from the same source. Even if I install using ipfs-update install v0.4.5-pre1 on Debian, the resulting ipfs version is still listed as v0.4.5-dev.

Ok, so I installed gcc-6 on Debian Jessie using the Debian Stretch repositories, and then reinstalled Orbit (a simple npm install). Orbit now runs without erroring out. I'm not sure if the rebuild is necessary. But either way it seems users will need a minimum (and non-standard) gcc as part of the Orbit build process. I haven't dived too far into the npm dependency rabbit hole, but my best guess is the ipfs-daemon package is the one that needs gcc since that appears to be what was calling runtime libraries and failing when built using gcc 4.9.
Newer gcc versions will be standard on most modern distros soon, and Orbit/IPFS are ahead of the curve so shooting for future release makes sense.
Standard gcc versions listed below.
Debian Jessie: gcc 4.9
RHEL7: gcc 4.8
Ubuntu 16.04 LTS: gcc 5.3+
Debian Stretch: gcc 6.2.1
OSX (listed because it seems lots of people use it): Uses Clang not gcc. Unsure of the Clang equivalent to gcc 6.
Steps to reproduce: try installing orbit on Debian Jessie (which comes with gcc 4.9.2 by default)
Fix: Install gcc-6 (lower version may work, I suspect gcc 5.3+ will work but haven't tested)
Recommended action: add a minimum gcc version dependency to documentation ?

Thank you @rsynnest for the excellent work on figuring this out! We should absolutely add it to the README. Would you like to PR it?
I suspect this is related to ipfs that ipfs-daemon pulls in, and most likely the new crypto and its build process. @dignifiedquire @diasdavid  we should try to reproduce this with js-ipfs or js-ipfs-api and see if it's the same result, and if so, we should make the same notes in the READMEs regarding the required gcc version.

This was fixed by adding the gcc versions to the readme in orbit-web: https://github.com/orbitdb/orbit-electron/pull/2.

authors: haadcode rsynnest theobat

repo: orbitdb/orbit

license: MIT


text:
Adding GM Ordinals Collection

[
{
"id": "09f0eab6bd8a9ffa0ad241821cc5b6f17675b361aac24d7fe25a96ec1a45690ai0"
},
{
"id": "0f922f4d25a27eae22c58bb3aac1683363f40a9a15a6120ed2754cb459984634i0"
},
{
"id": "e7a8dd9a61c9080d22ddd59396a546882a3b8006d5206a40f2cb0472e33ad2afi0"
},
{
"id": "6d08bcb3721ef8d4e47d856425976a11b3aa0cad2937edcfed85f27ec4032915i0"
},
{
"id": "286978273f40bc130ac5d1892d1093d44ccb8470cd85fcfe898cf9225b7dcb52i0"
},
{
"id": "9865838cc32e191173b9efa3983f376fc61399a2a05b36c9b6a49579e039b943i0"
},
{
"id": "ecceffb4230236c9b297882226e2530fe50d39081622560c17f7576edde34bdei0"
},
{
"id": "a92edf60a0c79d37faeb4050cd84518c836f0d319a5c3e95fdd0a4ef001c357ci0"
},
{
"id": "6bf79d28b44b0b47172262d74f05ff04b37795babb9dbe586cf85505d20732d8i0"
},
{
"id": "e9de8bf1a7c323041d35dd1bb25f6fc355684dfc454233c62ad0cf0e44aaa279i0"
},
{
"id": "93919179bc655cf21b3c99258295d4adb3a436f56c573fe4695ce25787d7b1c1i0"
},
{
"id": "d034ffed901dbd5bdce940f72909698aaccfa68685e4d0ad90e7bf771252b40di0"
},
{
"id": "1f36d98579c1912348791029817bf921123f4b46b52e6732d0f26152f5f9f70ai0"
},
{
"id": "15c87916071efa4038f56e10e0833b6fd9e4b5548dd4c8983fb746b101239282i0"
},
{
"id": "23b53e8971a1002ec4864020d2a07bf12999e9914e34f679f6aa712a8d51669di0"
},
{
"id": "f9af3f82142689e7516579bfec1bc79d672d57aee6dbefbe57e68e3567b1870ai0"
},
{
"id": "d8bee3775db3f191b590d5001e22746a8292ef0507a235e11784eb21ded7fe54i0"
},
{
"id": "0ce6130b461f515139d5076a3a5353612afb69527cfc031d71f0784a878ca565i0"
},
{
"id": "80ff523d894a79cfd944bd90b96d860e2904390d85d84b25eea89ac1e5b9f7f1i0"
},
{
"id": "7685ddaa9befe89aa5e4170a4bca59f645b36fa9c55f6803422b6879be78fcaei0"
},
{
"id": "d38f2cd2b6a16e017cd11e34c85f395a4670b28454756e231c466b455fe29b81i0"
},
{
"id": "ba74274db8edfb51fc3825ff5207ca06424ac980cad65e7eab9c8d3ce45c41f7i0"
},
{
"id": "dec7a6b8a9e68e4f64eabd7d7137aea5ad435b8f9e14ce56b2a3968c3e86aaf4i0"
},
{
"id": "db279dd629e299703ea7f8e5ac3786fd39ca998bb0640f09cd23e19264b67467i0"
},
{
"id": "7839ac5a8b0a691c3567f87415224d7573117fce7bd1ad800e0db3a66a4991ddi0"
}
]

pr is faulty. close pull request.

authors: chrisconfirm curatedordinals

repo: ordinals-wallet/ordinals-collections


text:
add supply and inscription # range to collection overview

For each collection It would be useful to be able to see the range of inscription numbers, and the total supply on the overview page.
See https://ordinalswallet.com/collections for an example of this

that would require getting details  of all inscriptions in a collection right?

authors: crypticmeta the-fiat-collection

repo: orenyomtov/openordex


text:
🛑 Forge is down

In 17b8d95, Forge (https://gitlab.orfeo-toolbox.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Forge is back up in aec7bfd after 13 minutes.

repo: orfeotoolbox/status-page


text:
Online Composition - Fragments and Compose not working with some System name

Hi all,
Just to say that the fragments and compose are not working if the SAP system name is not "correct".
When I was trying the Online composition, I was not able to use the fragments at all, just because my system was named "BI1 - 7.3". The error was quite straightforward here: the name contains not authorized characters.
Maybe it could be a good idea to find a way to override this limitation and, maybe, rename internally the system to a usable one by the fragments.

I noticed also that hypens weren't supported for XSYSTEM.  I had to rename my SAP GUI connection entry and remove the '-' for mine to work.

Had to do the same thing.

I will check this issue.

please check with V2, I have escaped some unallowed characters from system description.

authors: KarolKalisz entmike franckblais


text:
bug

https://github.com/orgua/shepherd-datalib/blob/a97da1b4062cd991894fd2a819e0e997b03ae88b/src/shepherd_data/reader.py#L80
data should be real cal_dict with [component][channel][parameter] -> currently outer component-layer missing
OR data should be derived from embedded config (cal should be in it?!?)

fixed in v2023.5.6
cal is now model-based

repo: orgua/shepherd-datalib


text:
HIGH SEVERITY..I was able to retrieve an edge using graph.getVertex(edgeId)! (2.1.3)

Possibly related/causing my other issues (#5068, #5033, #5048)
		OrientGraph graph = factory.getTx();
		Vertex v = graph.getVertex("#26:0");
		Edge e = graph.getEdge("#26:0");
		System.out.println(v+" "+e);

v(ContainsPrimitive)[#26:0] e[#26:0][#21:102-ContainsPrimitive->#30:1]

I stumbled upon that because it was giving a NullPointer exception trying to access properties that were not there.. The code was supposed to be retrieving a vertex but I debugged it and it was an edge printed as a vertex!
@lvca , @laa This happens with any edges that I tried from two classes! I would appreciate it if you could investigate it as soon as possible - you already have my copy of db in the email. I almost switched to a different product and still thinking of it..
I checked with every single backup (about 20 of them) from the first one 4 months ago till the last one and all of them are behaving exactly the same way!  I really don't know why my database became so messed up...so early on!

I checked in the code and there is this check:
if (!doc.getSchemaClass().isSubClassOf(OrientEdgeType.CLASS_NAME))
  throw new IllegalArgumentException("Class '" + doc.getClassName() + "' is not an edge class");

Trying to create a new test case for it.

@lvca Thanks for the quick response.. What I would expect in my case is
Class ContainsPrimitive is not a vertex class. Also what I don't understand is how this edge got into my  code as edge.. I wonder if there is a bug that instead of the DIRECTION.OUT vertex it returns the edge as a vertex too at least for my db

@lvca I recreated my database from scratch and the same thing happens!
 v(ContainsEntity)[#21:0] e[#21:0][#18:0-ContainsEntity->#13:5]

@zifnab87 How can I reproduce it? Do you have a script to generate it?

Yeah I am able anytime.. give me some time I will send it :)

@lvca
CREATE DATABASE remote:localhost/test2 root admin plocal
CONNECT remote:localhost/test2 admin admin
CREATE CLASS Date extends V
CREATE CLASS Number extends V
CREATE CLASS Has extends E
CREATE VERTEX Date // #11:0
CREATE VERTEX Number //#12:0
CREATE EDGE Has FROM #11:0 TO #12:0 /[Has#13:0{out:#11:0,in:#12:0} v1]
OrientGraphFactory factory = new OrientGraphFactory("remote:localhost/test2");
OrientGraph graph = factory.getTx();
Vertex v = graph.getVertex("#13:0");
Edge e = graph.getEdge("#13:0");
System.out.println(v+" "+e);
Oct 10, 2015 4:56:10 PM com.orientechnologies.common.log.OLogManager log
INFO: OrientDB auto-config DISKCACHE=7,419MB (heap=2,706MB os=12,173MB disk=36,272MB)
v(Has)[#13:0] e[#13:0][#11:0-Has->#12:0]

This test pass:

  @Test
  public void edgesCannotBeVertices() {
    OrientGraphNoTx gNoTx = new OrientGraphNoTx(URL, "admin", "admin");
    try {
      OrientVertex v = gNoTx.addVertex(null);
      OrientVertex loadedV = gNoTx.getVertex(v.getIdentity());
      try {
        OrientEdge e = gNoTx.getEdge(v.getIdentity());
        Assert.fail();
      } catch (IllegalArgumentException e) {
        // OK
      }
    } finally {
      gNoTx.shutdown();
    }

    OrientGraph g = new OrientGraph(URL, "admin", "admin");
    try {
      OrientVertex v = g.addVertex(null);
      OrientVertex loadedV = g.getVertex(v.getIdentity());
      try {
        OrientEdge e = g.getEdge(v.getIdentity());
        Assert.fail();
      } catch (IllegalArgumentException e) {
        // OK
      }
    } finally {
      g.shutdown();
    }
  }

So at this point could be the remote connection, let me check it...

Tested against remote, 2.1.x and develop branch and in all the cases a IllegalArgumentException is thrown. @zifnab87 please could you provide an executable test case that shows the problem?

ok I will send it

Tried with specific vertex class and same result: everything works as expected:

  @Test
  public void edgesCannotBeVertices() {
    OrientGraphNoTx gNoTx = new OrientGraphNoTx(URL, "admin", "admin");
    try {
      gNoTx.createVertexType("TestV");
      gNoTx.createEdgeType("TestE");

      OrientVertex v = gNoTx.addVertex("class:TestV");
      OrientVertex loadedV = gNoTx.getVertex(v.getIdentity());
      try {
        OrientEdge e = gNoTx.getEdge(v.getIdentity().toString());
        Assert.fail();
      } catch (IllegalArgumentException e) {
        // OK
      }
    } finally {
      gNoTx.shutdown();
    }

    OrientGraph g = new OrientGraph(URL, "admin", "admin");
    try {
      OrientVertex v = g.addVertex("class:TestV");
      OrientVertex loadedV = g.getVertex(v.getIdentity().toString());
      try {
        OrientEdge e = g.getEdge(v.getIdentity());
        Assert.fail();
      } catch (IllegalArgumentException e) {
        // OK
      }
    } finally {
      g.shutdown();
    }
  }

@lvca I think you are checking the inverse thing as I said in this comment earlier (https://github.com/orientechnologies/orientdb/issues/5089#issuecomment-147082204)
I am requesting an edge through getVertex..

Got it, I think this is possible because we use Vertex as generic schema-less type, so I guess there is no check if the vertex is an edge. I can check on it, but my question is: why are you retrieving an edge as vertex? I mean, wha's the purpose and why it's so critical? Could you just retrieve it as edge with getEdge()?

Well I didn't do it on purpose @lvca It happened in my code after a complicated insert.. In my models I keep a reference of a vertex about to be updated or just inserted.. For some reason after a specific (tested) use case that I add a big hierarchy of objects, I find an edge in the place of a vertex. This throws an exception because I try to use this vertex to find vertex properties that of course are not on the edge.. This is the bug that led me to find the bug we are discussing. That's why I am very frustrated. This is a case I have many integration tests and yet it manages to fail when some of the nodes are newly inserted..

@lvca this is definitely a bug I don't understand why cannot replicate was added.. I have moved away from OrientDB to TitanDB since December unfortunately.

@zifnab87 You were right, added check.

repo: orientechnologies/orientdb


text:
Fix number of letters

"ZALGO" is 5 letters not 6

It's ZALGO! - 6 characters. 😉

It is ZALGO! with an exclamation mark. But I agree it is needlessly hard to notice. I removed the exclamation mark

authors: adambowles orling wopian

repo: orling/grapheme-splitter


text:
Questions about the paper

The multiplication mentioned in the paper in "For class prediction, the learned objectness probability multiplies the classification probabilities to produce the final class predictions" is reflected in the code, but I'm sorry I couldn't find it

I have another question, which is what basis do you use to determine unknown targets? Is it determined by a threshold?@orrzohar

Will 100 confident predictions contain a lot of background?@orrzohar

Will 100 confident predictions contain a lot of background?@orrzohar

I may have misunderstood your meaning. When you choose top k (k=100), will there be 100 predicted results because it contains 100 known+unknown, but I don't see 100 predicted results in your visualization results? How do you determine which is the background, which is unknown, and which is known?

Hi @Rzx520,
The background should be suppressed as the obj_prob for background should be quite low, and therefore when selecting the top-k predictions the predictions would favor known/uknown objects.
Indeed the model makes 100 predictions per image, but I did not use all 100 for the figures. For a description of how I created figure 3, please see issue https://github.com/orrzohar/PROB/issues/11.
If you are interested in using PROB in a more realistic inference scenario, I would threshold (the known and unknown objects separately) to get more reasonable results, perhaps with NMS as well.
Let me know if you have any additional questions,
Orr

I would also like to know how you determined that this is background and whether there is a specifi obi_prob value is used to determine whether a value below this value is the background?@orrzohar

I don't quite understand the sentence 'cycled through the GT (both known and unknown) objects, and if a model had a prediction of the same class/IoU>0.5, I added that bbox on the image'. Can you explain it in detail?Do unknown objects also have GT? How was the GT of an unknown object obtained?@orrzohar

hi @Rzx520,
obj_prob is the objectness and is low for background and high for objects:

There is no hard threshold on the obj values. There is an implicit one. PROB can make 100*(num_classes+1) predictions per image. When selecting the top-100, the confidence of the 101st prediction can be thought of as a threshold. However, I prefer to conceptualize it that you down weight predictions that are likely background and that way don't predict background as a known/unknown object.
Re GT Unknown annotations - yes, there are! That is how U-Recall is calculated. I visualized it in this way because of the way mAP is calculated, where you first sort the predictions based on confidence and then see if they have a high enough IoU to a GT object. For more on how mAP is calculated, please see this.. So, in order for the qualitative and quantitative results to match up well, they should be created in a simular fashion.
The `unknown' object annotations are those same objects that are hidden from the model at Task t. For example, in M-OWODB, COCO is separated into 4 subsets, where in each task, an additional 20 classes are introduced. So in T1, you have 20 known classes in training and 60 unknown objects during evaluation. In T2, you have 40 classes in the ft dataset, 40 unknown objects in evaluation, and so forth.
Does this make more sense now?
Orr

Thank you very much for your reply. If I understand correctly, your unknown GT is in the COCO dataset, except for the trained class (n), the other (80-n) are its unknown GT, right?@orrzohar

Can I understand it this way? It is equivalent to a generalization task, which involves learning the objectness of known class objects to achieve the ability to detect object(known+unknown), and then detect unknown and known objects.
I have another question, why did you choose 100 predictions as the prediction result (known+unknown), so it won't lead to too much detection waste? After all, it's rare to detect 100 objects (known+unknown), is it just because DETR gives 100 predictions?Thanks@orrzohar

1 | distributed init (rank 2): env://
2 /home/ubuntu/anaconda3/envs/prob/lib/python3.10/site-packages/torchvision/models/_utils.py:208: UserWarning: The parameter 'pretrained' is deprecated since 0.13 and will be removed in 0.15, please use 'weights' instead.
3   warnings.warn(
4 /home/ubuntu/anaconda3/envs/prob/lib/python3.10/site-packages/torchvision/models/_utils.py:223: UserWarning: Arguments other than a weight enum or None for 'weights' are deprecated since 0.13 and will be removed in 0.15. The current behavior is equivalent to passing weights=None.
5   warnings.warn(msg)
6 /home/ubuntu/Desktop/X/ProjectCode/PROB-main/models/position_encoding.py:49: UserWarning: floordiv is deprecated, and its behavior will change in a future version of pytorch. It currently rounds toward 0 (like the 'trunc' function NOT 'floor'). This results in incorrect rounding for negative values. To keep the current behavior, use torch.div(a, b, rounding_mode='trunc'), or for actual floor division, use torch.div(a, b, rounding_mode='floor').
7   dim_t = self.temperature ** (2 * (dim_t // 2) / self.num_pos_feats)
8 /home/ubuntu/anaconda3/envs/prob/lib/python3.10/site-packages/torch/functional.py:478: UserWarning: torch.meshgrid: in an upcoming release, it will be required to pass the indexing argument. (Triggered internally at  ../aten/src/ATen/native/TensorShape.cpp:2894.)
9   return _VF.meshgrid(tensors, **kwargs)  # type: ignore[attr-defined]
10 /home/ubuntu/Desktop/X/ProjectCode/PROB-main/models/prob_deformable_detr.py:537: UserWarning: floordiv is deprecated, and its behavior will change in a future version of pytorch. It currently rounds toward 0 (like the 'trunc' function NOT 'floor'). This results in incorrect rounding for negative values. To keep the current behavior, use torch.div(a, b, rounding_mode='trunc'), or for actual floor division, use torch.div(a, b, rounding_mode='floor').
11   topk_boxes = topk_indexes // out_logits.shape[2]
After training one epoch, training the second epoch reported an error. As mentioned above, do you know how to solve it?@orrzphar

'AuntimeError: Timed out initializn process group in store based barrier on rank: 2,for key: store based barier key:l. (world size-3. worker counte,timeot=0:30:00)'
After training one epoch, training the second epoch reported an error. As mentioned above, do you know how to solve it?@orrzohar

Hi @Rzx520,

Yes you are exactly right! The remaining classes constitute the ‘unknown’ objects (this is the case for ALL the OWOD works - as this is the only way to determine what predictions even contain objects in them)
A. That is definitely a way to think about it — we want to learn from the base classes a general notion of ‘objectness’ to be able to detect novel objects.
B. I chose 100 predictions to remain consistent stistent with prior OWOD work — If I were to increase the number of predictions per image, I could artificially increase U-Recall without actually improving the model predictions, just by making more predictions. As OW-DETR and prior works all used 100 predictions/image, selecting 100 predictions per image was a way of mitigating this.
C. Actually, D-DETR can make more then 100 predictions per image — it can make 100*number_of_classes predictions per image (because it can predict the same bbox having different classes).
Re the Runtime error - The error message you provided suggests that there was a timeout error while initializing the process group in a distributed training setup. This error occurred on rank 2 with a specific key related to a store-based barrier. PROB does not train in 30min, so I would increase the runtime timeout threshold first

repo: orrzohar/PROB


text:
sync the new code

sync the new code

sync the new code

repo: orsline/mappers-go


text:
v2的_check.php在header之后可能被继续执行

如果使用的不是浏览器而是自己的爬虫之类的东西，访问到admin下的一些文件的时候，虽然执行了header函数，但是后面的代码仍然可能被执行到。

安全相关，编辑了下issue。

authors: ZacharyJia orvice

repo: orvice/ss-panel


text:
Show count of voted/unvoted proposals to content selectors

To make it easier to track one's progress, the content selector widget should show how many proposals have been voted on and how many are remaining.

Doing content voting for the first time this year, and I came to mention something very much like this!
I would expect it to be [count of user's votes] / [total proposals].

authors: aeschright rahaeli

repo: osbridge/openconferenceware


text:
otk: add mtls into resolve ostree command

SSIA
this allows resolution of pulp hosted repos

Sure amended a test.

Removed the boolean, rebased, fixed tests.

repo: osbuild/images


text:
Remount containers-store bind mount as rw

We encountered a nasty bug where the mount binary in centos:9 and fedora:39 behaves differently due do differing util-linux versions. With the mount API in Fedora, the bind mount will bind mount a read-only file sytem as rw, in Centos this isn't the case. Remounting the bind mount is a pretty dirty fix to get us up and running with containers-storage in bootc-image-builder.

Has anyone filed a bug report with Fedora? That's a pretty significant change in behavior.

Has anyone filed a bug report with Fedora? That's a pretty significant change in behavior.

I'm on it.

We encountered a nasty bug where the mount binary in centos and fedora behaves differently.

Very minor point and I think everyone knows this, but keeping in sync in terminology is important...it's not about fedora versus centos (presumably), it's about fedora-X versus centos-Y...because at some point centos-10 will come around, and then centos-10 will likely have inherited the behavior here (from util-linux).
(This comment brought to you by having multiple times to have to unwind some conditionals in code that were writing "if rhel" when they really meant "if rhel 8"...etc)

We encountered a nasty bug where the mount binary in centos and fedora behaves differently.

Very minor point and I think everyone knows this, but keeping in sync in terminology is important...it's not about fedora versus centos (presumably), it's about fedora-X versus centos-Y...because at some point centos-10 will come around, and then centos-10 will likely have inherited the behavior here (from util-linux).
(This comment brought to you by having multiple times to have to unwind some conditionals in code that were writing "if rhel" when they really meant "if rhel 8"...etc)
Or TL;DR, please write e.g.

We encountered a nasty bug where the mount binary in centos:stream9 and fedora:39 behaves differently.

I've expanded the PR text to mention the centos and fedora versions and that the difference in behaviour is due to util-linux versions.

authors: bcl cgwalters kingsleyzissou ondrejbudai supakeen

repo: osbuild/osbuild


text:
examples: fix up

The examples merged in #52 were broken (and I merged them knowing this) so now let's work to make the implementation support them.
Relevant bugs:

#62
#63

Going to close this PR and resubmit due to shenanigans going on on GitHub/my local checkout.

repo: osbuild/otk


text:
BufferView

BufferView vs withUnsafePyramidOfDoom(_:)

I have solved this issue in my upcoming rework. I'm in the process of removing all pointer methods. There's two uses of fromUnsafeWords(_:) that's giving me trouble, but that's it.

The rework is Numberick, and it is pointer-free (± withContiguousStorageIfAvailable).

repo: oscbyspro/AwesomeNumbersKit


text:
Merge initial boilerplate from main to dev

Setup dependencies, Webpack.config,Tsconfig, and boilerplate render for app.

Great boilerplate

Webpack build looks fine.

We did a great job with setting up the boilerplate and tsconfig file.

authors: TylerPohn manjunathap85 mikemasatsugu rammarimuthu

repo: oslabs-beta/EmberQL


text:
Track name is not updated in GPX export xml

For example, create a track which initially has the name of Sat Apr 20 2024, update the name to Test, the name in the GPX file remains Sat Apr 20 2024:
<metadata>
  <name>Sat Apr 20 2024</name>
</metadata>

I have a fix working locally, which I'll submit a PR with. This is my first time working with OsmAnd though so the fix may not be correct, hence why I created this issue separately.

To do: when you create a track or edit in Plan Route you want to change name once you save, the tag is updated

authors: FozzieHi vshcherb

repo: osmandapp/web


text:
Upload a trace

Can we have the gpx endpoint of OSM API to upload a trace ?

Sure, would you like to work on this ? :grin:

I may give it a try.
An evolution seems to be needed in osm-auth dependency too: https://github.com/osmlab/osm-auth/issues/35

Depends on how you will authenticate, if you use basic auth instead, osm-request has its own Ajax call so we may not have this issue.

authors: PanierAvide nlehuby

repo: osmlab/osm-request


text:
Segfault with volume rendering

The attached program (a reduced test case) creates a shared_structured_volume volume of 64^3 voxels, containing random floats. I get a segfault with this backtrace:
(gdb) bt
#0  0x00007f8f2459cdb1 in GridAccelerator_stepRay___un_3C_s_5B_unGridAccelerator_5D__3E_CvyfREFs_5B_vyRay_5D_avx2 () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#1  0x00007f8f2436871f in SciVisRenderer_computeVolumeInterval___un_3C_s_5B__c_unSciVisRenderer_5D__3E_un_3C_s_5B_unVolume_5D__3E_REFs_5B_vyRay_5D_vyfvyfvyfvybREFCvyfREFs_5B__c_vyvec3i_5D_unfavx2 ()
   from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#2  0x00007f8f243900e7 in SciVisRenderer_intersect___un_3C_s_5B_unSciVisRenderer_5D__3E_REFs_5B_vyRay_5D_REFCvyfREFs_5B__c_vyvec3i_5D_REFs_5B_vyvec4f_5D_REFvyfavx2 ()
   from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#3  0x00007f8f2439100e in SciVisRenderer_renderSample___un_3C_s_5B_unRenderer_5D__3E_un_3C_unv_3E_REFs_5B_vyScreenSample_5D_avx2 () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#4  0x00007f8f24314ad8 in Renderer_default_renderTile___UM_un_3C_s_5B_unRenderer_5D__3E_un_3C_unv_3E_REFs_5B_unTile_5D_uniavx2 () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#5  0x00007f8f2430b8b4 in Renderer_renderTile () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#6  0x00007f8f2421f0f5 in tbb::interface9::internal::start_for<tbb::blocked_range<unsigned long>, tbb::internal::parallel_for_body<ospray::LocalTiledLoadBalancer::renderFrame(ospray::Renderer*, ospray::FrameBuffer*, unsigned int)::{lambda(int)#1}::operator()(int) const::{lambda(unsigned long)#1}, unsigned long>, tbb::auto_partitioner const>::execute() () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#7  0x00007f8f24db00cc in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all (this=0x0, parent=..., child=0x7f8f18820180) at ../../src/tbb/custom_scheduler.h:495
#8  0x00007f8f24dadb9a in tbb::internal::generic_scheduler::local_spawn_root_and_wait (this=0x0, first=..., next=@0x7f8f18820180: 0x42665629425b348d) at ../../src/tbb/scheduler.cpp:676
#9  0x00007f8f2421fdbc in void tbb::interface9::internal::dynamic_grainsize_mode<tbb::interface9::internal::adaptive_mode<tbb::interface9::internal::auto_partition_type> >::work_balance<tbb::interface9::internal::start_for<tbb::blocked_range<int>, tbb::internal::parallel_for_body<ospray::LocalTiledLoadBalancer::renderFrame(ospray::Renderer*, ospray::FrameBuffer*, unsigned int)::{lambda(int)#1}, int>, tbb::auto_partitioner const>, tbb::blocked_range<int> >(tbb::interface9::internal::start_for<tbb::blocked_range<int>, tbb::internal::parallel_for_body<ospray::LocalTiledLoadBalancer::renderFrame(ospray::Renderer*, ospray::FrameBuffer*, unsigned int)::{lambda(int)#1}, int>, tbb::auto_partitioner const>&, tbb::blocked_range<int>&) () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#10 0x00007f8f2421f43d in tbb::interface9::internal::start_for<tbb::blocked_range<int>, tbb::internal::parallel_for_body<ospray::LocalTiledLoadBalancer::renderFrame(ospray::Renderer*, ospray::FrameBuffer*, unsigned int)::{lambda(int)#1}, int>, tbb::auto_partitioner const>::execute() () from /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_module_ispc.so
#11 0x00007f8f24db00cc in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all (this=0x0, parent=..., child=0x7f8f18820180) at ../../src/tbb/custom_scheduler.h:495
#12 0x00007f8f24daa915 in tbb::internal::arena::process (this=0x0, s=...) at ../../src/tbb/arena.cpp:160
#13 0x00007f8f24da87ff in tbb::internal::market::process (this=0x0, j=...) at ../../src/tbb/market.cpp:677
#14 0x00007f8f24da43c6 in tbb::internal::rml::private_worker::run (this=0x0) at ../../src/tbb/private_server.cpp:275
#15 0x00007f8f24da4356 in tbb::internal::rml::private_worker::thread_routine (arg=0x0) at ../../src/tbb/private_server.cpp:228
#16 0x00007f8f2491d08c in start_thread () from /usr/lib/libpthread.so.0
#17 0x00007f8f252d8e7f in clone () from /usr/lib/libc.so.6

This is with 1.5.0 64-bit linux binaries from ospray.org. TBB seems to get picked up by the shared linker from Embree 2.17.0 (also from ospray.org), not sure if that matters in this case:
paulm@cmstorm 20:37:/data/examples/ospray/hexahedral_volume$ ldd ./sgrid
	linux-vdso.so.1 (0x00007ffda818f000)
	libospray.so.0 => /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray.so.0 (0x00007fdaf7086000)
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fdaf6940000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007fdaf65f4000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fdaf63dd000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007fdaf6026000)
	libospray_common.so.0 => /home/paulm/software/ospray-1.5.0.x86_64.linux/lib/libospray_common.so.0 (0x00007fdaf6f9d000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fdaf5e22000)
	libtbb.so.2 => /home/paulm/software/embree-2.17.0.x86_64.linux/lib/libtbb.so.2 (0x00007fdaf5bcb000)
	libtbbmalloc.so.2 => /home/paulm/software/embree-2.17.0.x86_64.linux/lib/libtbbmalloc.so.2 (0x00007fdaf5977000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fdaf5759000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fdaf6ed1000)
	librt.so.1 => /usr/lib/librt.so.1 (0x00007fdaf5551000)

sgrid.cpp.gz

This is based on ospTutorial, but I might be doing something dumb somewhere w.r.t. setting up the volume that causes this issue

Found my error: forgot to commit the transfer function

repo: ospray/ospray


text:
feat: docker backend

Do help test this out if you are interested. This builds and runs all of rmf in a container, the dockerfiles could also be useful for official docker support in the corresponding rmf components.

Mine is failing at the npm run build:docker command

@matiasbavera most of the errors are compiler warnings so they should be fine. I fixed the undefined symbol error so that should work now.

@ChawinTan
you need to install docker-compose

Hmmm it is now giving me
.FileNotFoundError: [Errno 2] No such file or directory: './docker/rmf/docker-compose.yml

Just ran the command with sudo in front and it is working well now :)

I promise that I'll review this one, once https://github.com/osrf/romi-dashboard/pull/79 is merged =) (It will drastically decrease the number of files to verify).

I think something weird it's happening with the CI.

It has been stuck there for hours.

I think something weird it's happening with the CI.

It has been stuck there for hours.

I think it's because I changed the CI workflows and it's waiting for the non-existent checks. The Test workflow is now moved to Pull Requests / Unit Test (pull_request).

authors: ChawinTan koonpeng matiasbavera

repo: osrf/romi-dashboard


text:
Test all the tutorials

Use this ticket to organize who is testing each tutorial.

Following this testing plan.

I am working on task 1 for both the scoring plugin and tutorial verification

authors: M1chaelM caguero j-herman

repo: osrf/vrx


text:
Feather caching

CSV caching to pyarrow.feather
CSVs are very large and pandas' (de)serialization of them is slow.
this patch switches to using a much faster data caching strategy because feather is much faster to (de)serialize and is smaller.

@cdolfi this is a draft, fixing an issue with the contributors visualizationss

@cdolfi okay fixed the bug, should work fine now. just have to do a 'docker system prune -af' before you try this branch because the redis 'cache' container isn't rebuilt in between composes so it's full of CSV data.

LGTM

authors: JamesKunstle MichaelClifford


text:
OsvFunTest: Ensure that queries for Composer packages work

The queries for the Packagist ecosistem have started working on the backend-side, see [1].
[1] https://github.com/google/osv.dev/issues/497

Failing tests were unrelated, so merging is ok.

repo: oss-review-toolkit/ort


text:
[Unit Testing]: More test cases

Add more unit testing test cases.
Related to issue #630 and extending PR #643
Signed-off-by: Arthur Chan arthurchan@adalogics.com

Not needed anymore, using another approach in PR #663

repo: ossf/fuzz-introspector


text:
✨ [experimental] Create probes within findings

This PR introduces the concept of probes, which will have a unique ID. These used to be called "rules".
Create probes within findings

Thanks for the review! Made the changes, PTAL

Still think the const approach is a good step for now.

I've made the changes.

repo: ossf/scorecard


text:
FFmpeg: 找不到FFmpeg，或FFmpeg不支持某些Codec，please restart it，no FFmpeg

找不到FFmpeg的问题，或者FFmpeg不符合要求：

Docker中已经内置了FFmpeg，参考：https://github.com/ossrs/srs/issues/1523#issuecomment-567436519
如果是非Docker，需要自己下载或者编译FFmpeg：https://ffmpeg.org/download.html

SRS会检测这个路径，可以选择软链到这个路径，或者直接拷贝过去：
/usr/local/bin/ffmpeg

编译开启FFmpeg工具的命令，开启后就会检测：
./configure --ffmpeg-tool=on

如果需要使用Ingest、Transcode等依赖FFmpeg工具的功能，都需要自己保障FFmpeg是可用的。

已经将ossrs/srs:dev中的FFMEPG，目前是4.1放到了docker中，参考srs-docker的使用说明。
对比镜像大小，SRS只有2.6MB左右，压缩的镜像是从74.88MB变成84.194MB增加了9.314MB，解压后的镜像从212MB变成234MB增加了22MB，也不知道是否值得 😭
层信息如下：

由于FFMPEG经常更新，而且有时候需要使用自己的版本，推荐还是自己编译，可以参考Dockerfile做自己的FFMPEG。这样就可以启动SRS时，用自己的FFMPEG替换SRS自带的了，方法和替换配置文件和日志文件一样，都是换掉里面的文件，映射下目录/usr/local/srs/objs/ffmpeg/bin/ffmpeg就好了：
docker run -p 1935:1935 -p 1985:1985 -p 8080:8080 \
    -v /path/of/ffmpeg:/usr/local/srs/objs/ffmpeg/bin/ffmpeg \
    ossrs/srs:3

在Docker中有了FFMPEG，那么配置文件中用到FFMPEG的配置，比如转码和ingest都是可用的了。

已经将ossrs/srs:dev中的FFMEPG，目前是4.1放到了docker中，参考srs-docker的使用说明。
对比镜像大小，SRS只有2.6MB左右，压缩的镜像是从74.88MB变成84.194MB增加了9.314MB，解压后的镜像从212MB变成234MB增加了22MB，也不知道是否值得 😭
层信息如下：
由于FFMPEG经常更新，而且有时候需要使用自己的版本，推荐还是自己编译，可以参考Dockerfile做自己的FFMPEG。这样就可以启动SRS时，用自己的FFMPEG替换SRS自带的了，方法和替换配置文件和日志文件一样，都是换掉里面的文件，映射下目录/usr/local/srs/objs/ffmpeg/bin/ffmpeg就好了：
docker run -p 1935:1935 -p 1985:1985 -p 8080:8080 \
    -v /path/of/ffmpeg:/usr/local/srs/objs/ffmpeg/bin/ffmpeg \
    ossrs/srs:3

在Docker中有了FFMPEG，那么配置文件中用到FFMPEG的配置，比如转码和ingest都是可用的了。

既然ffmpeg已经集成了，docker 创建容器的时候如何启用 ffmpeg？

ffmpeg推流报错Invalid data found when processing input如何解决

repo: ossrs/srs


text:
Support Google Address Sanitizer

See https://github.com/google/sanitizers

Address Sanitizer(Aasn)是一个快速的内存错误检测工具。在AddressSanitizer 可以看到详细的介绍。
从gcc 4.8开始，AddressSanitizer成为gcc的一部分。当然，要获得更好的体验，最好使用4.9及以上版本，因为gcc 4.8的AddressSanitizer还不完善，最大的缺点是没有符号信息。
为了尽早发现内存错误问题，在SRS中增加使用 Aasn 检测内存错误功能。考虑到Aasn在不同的平台上

authors: chen-guanghua winlinvip


text:
Osuny sliders

Type

[ ] Nouvelle fonctionnalité
[ ] Bug
[ ] Ajustement
[x] Rangement

Description
Niveau d'incidence

[ ] Incidence faible 😌
[x] Incidence moyenne 😲
[ ] Incidence forte 😱

Référence (ticket et/ou figma)
URL de test sur example.osuny.org
[branch]--example.osuny.netlify.app
URL de test du site (optionnel)
Screenshots

Reste un pb au click sur la lightbox :
Blocked aria-hidden on an element because its descendant retained focus. The focus must not be hidden from assistive technology users. Avoid using aria-hidden on a focused element or its ancestor. Consider using the inert attribute instead, which will also prevent focus. For more details, see the aria-hidden section of the WAI-ARIA specification at https://w3c.github.io/aria/#aria-hidden.
Element with focus: button
Ancestor with aria-hidden:
<picture>…</picture><button class="lightbox-button" tabindex="-1">…</button>
…

Mais le code semble correct https://accessibilityinsights.io/info-examples/web/aria-hidden-focus/

repo: osunyorg/theme