Add serialisation for groth16 and gm17 data objects

depends on https://github.com/filecoin-project/zexe/pull/2
this PR adds serialisation and de-serialisation for the data structures used in the groth16 as well as gm17 proof system.

merged manually in 9b473bd24e908f1d031f02ae642f2569e84e4aa1


feat: experimental mapping

this refactors the mapping to take a config for custom maps, fixes #16
currently, it hits 5 of the example mapping functions
TODO: Hit the other mapping examples, if anyone has anymore please put them here or in the issue
Additionally, will need to keep the sensible defaults for the mapping definitions and offer a way to put them in through config and merge them with the defaults

TODO:

Ability to set in config and merge in
Sensible defaults
Handle which key mappings - parse and hand off to which-key in a pcall?
Handle lazy key maps (expression_list)

also adds frame work for testing needed for #17


Upgrade flow-go so it contains cadence v0.23.0

Description
Upgrade flow-go version to this PR: https://github.com/onflow/flow-go/pull/1605 so that it contains cadence version v0.23.0

For contributor use:

[x] Targeted PR against master branch
[ ] Linked to GitHub issue with discussion and accepted design OR link to spec that describes this work
[ ] Code follows the standards mentioned here
[ ] Updated relevant documentation
[ ] Re-reviewed Files changed in the GitHub PR explorer
[ ] Added appropriate labels

Codecov Report

Merging #134 (4b4da8d) into master (3bffc6a) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #134   +/-   ##
=======================================
  Coverage   53.43%   53.43%
=======================================
  Files          20       20
  Lines        1937     1937
=======================================
  Hits         1035     1035
  Misses        790      790
  Partials      112      112

Flag
Coverage Δ

unittests
53.43% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3bffc6a...4b4da8d. Read the comment docs.


restore: rename PV when remapping a namespace if PV exists in-cluster

Signed-off-by: Steve Kriss<EMAIL_ADDRESS>closes #192
TODO:

[x] add unit test cases (positive cases & ensure adequate negative cases)
[ ] think about possible ways to simplify this code

Addressed comments so far + added test cases


Updated API caller file title in README.

Probably after renaming the file, it has been forgotten to rename it in the README.

oh, good catch & thanks for the PR!

I'm also fixing this for the other headings rn.


[stable/mariadb] Install-time master.resources syntax?

Is this a request for help?:
Yes
Just a simple installation syntax question.
I'm not sure how to set install-time configuration for master.resources part.
Documentations says just {} but I don't know what does that mean compares to other syntax parts where everything is just a string.
For example, I install the chart this way:
helm install --name mariadb bitnami/mariadb --set \
image.tag=10.2.17-debian-9-r22,\
master.persistence.storageClass=ssd,\
master.persistence.existingClaim=mysql-master-storage,\
master.persistence.size=100Gi,\
master.persistence.mountPath=/bitnami,\
rootUser.password=password,\
rootUser.forcePassword=true,\
db.name='',\
slave.replicas=2,\
replication.password=password,\
slave.persistence.storageClass=ssd,\
slave.persistence.size=100Gi,\
metrics.enabled=true,\
master.resources=??? <-----

How would this oneliner look with master.resources configured with these resources/limits:
resources:
  requests:
    cpu: 2
    memory: 3Gi
  limits:
    cpu: 2.5
    memory: 4Gi

--
Version of Helm and Kubernetes:
Any
Which chart:
stable/mariadb
What happened:
N/A
What you expected to happen:
N/A
How to reproduce it (as minimally and precisely as possible):
N/A
Anything else we need to know:
N/A
Thank you in advance!

Hey @pentago, I think you can do this with --set master.resources.requests.cpu=2,master.resources.requests.memory=3Gi,master.resources.limits.cpu=2.5,master.resources.limits.memory=4Gi. However, why not create your own values.yaml file and set all these values within there?

@prydonius you're rught about values.yaml, will di that.
Thanks for letting  me know, I'll test this.

@prydonius is this how properly formatted custom values.yaml should look?
I'm sure about everything else except resources sections.
image:
  tag: 8.0.12-debian-9-r25

root:
  password: password

db:
  user: ''
  password: ''
  name: ''

replication:
  enabled: true
  user: replicator
  password: password

master:
  persistence:
    enabled: true
    mountPath: /bitnami
    existingClaim: mysql-master-storage
      storageClass: ssd
    accessModes:
    - ReadWriteOnce
    size: 100Gi
  resources: {
    requests:
      cpu: 2
      memory: 3Gi
    limits:
      cpu: 2.5
      memory: 4Gi
  }

slave:
  replicas: 2
  persistence:
    enabled: true
      storageClass: ssd
    accessModes:
    - ReadWriteOnce
    size: 100Gi
  resources: {
    requests:
      cpu: 2
      memory: 3Gi
    limits:
      cpu: 2.5
      memory: 4Gi
  }

metrics:
  enabled: true
  resources: {
    requests:
      cpu: 0.5
      memory: 100Mi
    limits:
      cpu: 1
      memory: 300Mi
  }

Disregard. Just learned that consensus is that by declaring {} it simply means no value and if I remove curly braces pair everything below it is valid YAML and my chart installs properly.
Thanks!


feat: Kaskada Health Checks + Auto Recovery for Python (#254 / #267)

Description
Adds health checks to the Python client and improves overall code syntax.
Changes

Adds grpcio-health-checking to the Python pyproject.tml.
Updates the pylint max line to 200 (easier to read)
Replaces api_utils.run_subprocess with a KaskadaLocalService and a SubprocessFactory.
Replaces api_utils.check_socket with an actual health check.
Updated subprocess runs to synchronously terminate with the stop() method.
Add a keep alive watcher to automatically recover from failure.
Update the connection retry logic from the session to the client.
Create a LocalSession object to wrap around the Kaskada services to enable restarting.
Updates client docs and organization
Adds a HealthCheckClient.
Adds a HealthCheckServicer.
Adds a HealthCheckWatcher.

This looks wonderful.
I do want to ask about remote services though.  Are they still supported?

I saw that you can still specify an endpoint when creating a client, so it seems that it should still be supported, but I couldn't exactly tell from the code.
I also saw that there is a new should_connect param when creating a client.  Maybe that should be named is_local, or something similar?  The heath-check endpoints for manager and engine are unlikely to be available on remote running services.

I do want to ask about remote services though. Are they still supported?

In theory, remote services are supported. Remote services will need to expose the gRPC health check endpoint for the Engine and Manager. The Engine uses the same port (50052) and the Manager uses (6666). At the moment, they default the local host versions. We will need to revise this once a remote implementation comes up and running. There will be some configuration but the RemoteSession is a future implementation.

I saw that you can still specify an endpoint when creating a client, so it seems that it should still be supported, but I couldn't exactly tell from the code.

The client will attempt to use the defaults which are localhost for the Engine and Manager. In the future, we will need to customize this.

I also saw that there is a new should_connect param when creating a client. Maybe that should be named is_local, or something similar? The heath-check endpoints for manager and engine are unlikely to be available on remote running services.

The remote services use case is an interesting story since it differs from our normal local session quite differently. In a traditional microservice, they expose out the health services publicly to ensure clients check the status. Are they usually only for internal load balancers and not externally accessible? That'd be a consideration for changing this. But I would like to defer the change until needed for remote sessions.
The original intent of should_connect was to allow me to write a unit test around the client without it attempting to connect.

In a traditional microservice, they expose out the health services publicly to ensure clients check the status. Are they usually only for internal load balancers and not externally accessible? That'd be a consideration for changing this. But I would like to defer the change until needed for remote sessions.

Yes, health checks are almost never externally available.  They are generally only used by internal services like kubernetes pod health checks and load balancers.
When we used to host wren externally, we would only expose the 50051 service outside of our kubernetes environment. Sparrow was not exposed externally at at all. Any service that is exposed externally needs to implement authentication and authorization, so many services like sparrow are generally never exposed.


Change allowing 0 length passwords caused openssh regression

The fix for issue #4716 caused regression in OpenSSH. It unfortunately depends on OpenSSL not attempting decryption of encrypted keys when zero-length password is passed to the callback, but returning a predictable error - that password is not supplied. Unfortunately for some of the keys that are encrypted with the old PEM encryption the decryption succeeds due to the accidentally correct padding in the decrypted garbage and the error returned is different.
In my opinion OpenSSH code is wrong and depending on things that it should not depend on but strictly speaking this is behavioral change on OpenSSL side.
See https://bugzilla.mindrot.org/show_bug.cgi?id=2913 for the discussion with OpenSSH.

In my opinion OpenSSH code is wrong and depending on things that it should not depend on but strictly speaking this is behavioral change on OpenSSL side.

Interesting. Of course all bug fixes are a behavioural change in a way! One person's bug fix is another person's behaviour change if they happen to be relying on that buggy behaviour.

So true! :D

Tomáš would you close this non OpenSSL issue?

For protocol . issue is same as #6947. The difference is password length.
And yes 1.0.2p change "When unlocking a pass phrase protected PEM file or PKCS#8 container, we now allow empty (zero character) pass phrases." just reveals errorneous "translation of libcrypto errors" into SSH code.

I am not sure the issue is the same as #6947 - however it seems to be related.

Let's close this as it is not really issue in OpenSSL.


Document the noir-profiler

Problem
A few months ago we added a profiler under tooling/profiler. The profiler has been used almost exclusively internally. This profiler allows devs generate flamegraphs of the opcodes and backend constraints laid down by a given program. Just recently the profiler was expanded to also provide information on which part of the program is generated the most steps in the Brillig VM.
Happy Case
We should document the profiler inside the Noir repo and externally to allow developers to start to utilize this very useful tool.
Workaround
None
Workaround Description
No response
Additional Context
No response
Project Impact
Nice-to-have
Blocker Context
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response

Does the profiler also analyze witness generation?


Enable Selection middleware for single item results

So far, the selection middleware is working well for most of my needs.  One exception is where a query is designed to return a single item, but still wanting to use the selection middleware to limit the data retrieved, which is especially useful when the item contains multiple list properties.
I can use the following inline middleware immediately before the UseSelection middleware to make this work with any IQueryable as well as query providers supporting IAsyncEnumerable without taking a dependency on EntityFrameworkCore.  This is based on the idea of SingleOrDefault, but a FirstOrDefault version can easily be derived.
                .Use(next => async ctx => {
                    await next(ctx);
                    if (ctx.Result is IQueryable<Profile> profilesQuery) {
                        if (profilesQuery.Take(2) is IAsyncEnumerable<Profile> profiles) {
                            var foundProfile = false;
                            Profile? currentProfile = default;
                            await foreach (var profile in profiles) {
                                if (foundProfile) throw new InvalidOperationException("Sequence contains more than one element");
                                foundProfile = true;
                                currentProfile = profile;
                            }
                            ctx.Result = currentProfile;
                        }
                        else {
                            ctx.Result = profilesQuery.SingleOrDefault();
                        }
                    }
                })

The above code can be simplified if willing to take a dependency on System.Linq.Async.  I'd be hesitant in a generic sense of taking a dependency on EntityFrameworkCore, as I believe this should be designed to work with any IQueryable.

@TheJayMann  Please check with https://github.com/ChilliCream/hotchocolate/tree/10.4.0-rc.1 👍

Everything appears to be working with regards to this new feature.


Add variant of ObservableArrayType.reduce that reduces over a mapping

Mapping an array requires maintaining an index mapping, which is superfluous when we're going to ignore the ordering anyway; so array.map{$0.someInteger}.sum() does extra work.

Ugh, not really. If the key is not observable, then reduce's add and remove can extract it on the fly. If it is observable, then it may change on its own, so array.map{$0.someInteger}.reduce(…) is the way to go.


Print warnings when calling the deprecated functions

We wan't to remove the deprecated functions in future releases.
We should warn/annoy the user, that the function will be removed, whenever he tries to call that function.

This is already done. No change required.


Debugging usage

Moving my question from https://github.com/humbug/box/issues/53#issue-294948638 to here.
I think it would be good if it would be possible to easily switch from parallelMap() to a plain old array_map(), be it for debugging purposes or simply because in a special case parallelMap() is not working e.g. when the passed argument is not serializable.
Maybe an env variable would work, the inconvenient being it's gonna rely on global state, the benefit is would be easier and won't require much changes.
On the same token, the major downside I have with this library is the inability to use break points for the paralellised work. Would make it work?
If you have some insight regarding this that would be greatly appreciated, otherwise I'll try to give it a stab in the coming months :)

After giving this some thought, the correct place for a solution may in fact be in amphp/parallel (where you first opened the issue https://github.com/amphp/parallel/issues/39).
We already use an environment variable (or constant) AMP_DEBUG to turn on certain debugging features in amphp/amp. I think a similar constant such as AMP_PARALLEL_DEBUG may be a good idea. What I'm thinking is for this flag to cause DefaultWorkerFactory to return a worker that uses a context that executes in the same process. This way breakpoints could be set within Task implementors (parallelMap() is executed by a class implementing Task). That class already uses another such flag, AMP_PHP_BINARY, that can be set to define a specific path to the PHP executable binary.

@rybakit mind to share you configuration? Because I can't it get working. Whenever the breakpoint is in a function executed by the worker in another process the breakpoint is never hit

I've just thought about it: @rybakit is kinda right. What is not working is a breakpoint inside the payload: I think it's because the function is serialiazed/unserialized it's no longer able to pick up where it's coming from :/

@theofidry Correct. You can implement a Task class instead and use the amphp/parallel API, then it should continue to work.

Wouldn't it be easier then to simply call the callable in parallel()?
As the main point here is to not serialize, if we were to try to use the works & co. still it means creating a new task & context to execute the task within the same process. That's a non-negligeable amount of work and I'm not sure there's any benefit in it. The point of this debugging mode is more being able to debug the callable not execute the whole amphp toolchain

Yes, that's definitely easier.


clientv3/yaml: use TLS 1.2 in min version

To be consistent with 'pkg/transport' https://github.com/coreos/etcd/blob/master/pkg/transport/listener.go#L171

lgtm

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@83577a5). Click here to learn what that means.
The diff coverage is 100%.

@@            Coverage Diff            @@
##             master    #7675   +/-   ##
=========================================
  Coverage          ?   73.36%
=========================================
  Files             ?      329
  Lines             ?    26700
  Branches          ?        0
=========================================
  Hits              ?    19588
  Misses            ?     5632
  Partials          ?     1480

Impacted Files
Coverage Δ

clientv3/yaml/config.go
86.66% <100%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 83577a5...dee467d. Read the comment docs.


Number of candidates is not being affected by selectrum-num-candidates-displayed

I've set selectrum-num-candidates-displayed to 30. But I'm still only seeing 10 candidates (including the prompt). I'm at commit 548903e, which is the latest as I'm writing this. And I've confirmed selectrum mode is enabled by evaluating selectrum-mode. I've also tried rebuilding selectrum and starting a new emacs session.

Thanks for the report, I can confirm it. There seems to be a limit imposed by Emacs on the total height of the minibuffer, as the candidates are still displayed and selectable, just not visible in the frame.

There seems to be a limit imposed by Emacs on the total height of the minibuffer

Indeed. This seems to be the variable max-mini-window-height according to this stackoverflow question. I set it from 0.3 ot 0.5 and this allowed more candidates to be visible in the frame (though not yet 30).

I guess Selectrum should rebind that variable locally to the number candidates displayed plus one.

I guess Selectrum should rebind that variable locally to the number candidates displayed plus one.

Well, that number is the proportion of the frame that the minibuffer should occupy. So I think the value of that number would have to be a function of line height (relative to the size of the frame) and the number of candidates we want to display.

Forget what I just said. I took a peek at ivy's source code. I think we can do it essentially the way you suggested. I think this snippet is the way to do it.
In ivy--minibuffer-setup I see the minibuffer height set this way (I simplified the code a bit):
 (set-window-text-height nil height)

In ivy-minibuffer-grow/shrink:
(setq-local max-mini-window-height (cl-incf ivy-height)) ;; essentially what you said

Let me know if you encounter any further difficulty.

It looks good to me. I'll post a gif here when I can so people reading this will understand what the new behavior is.

Thanks.


make fails :(

Hi,
Make fails .... I would really appreciate if you could help.
Thank you!
Siarhei
e3429fa0975:AMQP-CPP root# make
make -C src all
make[1]: Entering directory '/workspace/ws/AMQP-CPP/src'
g++ -Wall -c -I. -std=c++11 -MD -g -fpic -o receivedframe.o receivedframe.cpp
In file included from /usr/include/sys/types.h:72:0,
from includes.h:24,
from receivedframe.cpp:8:
connectionstartframe.h:124:13: error: expected unqualified-id before 'unsigned'
uint8_t major() const
^
connectionstartframe.h:124:13: error: expected ')' before 'unsigned'
.....
File /usr/include/sys/types.h:
++++ BEGIN CODE+++
#ifndef _SYS_TYPES_H
#ifdef __cplusplus
extern "C" {
#endif
#include <features.h>
#define __NEED_ino_t
#define __NEED_dev_t
#define __NEED_uid_t
#define __NEED_gid_t
#define __NEED_mode_t
#define __NEED_nlink_t
#define __NEED_off_t
#define __NEED_pid_t
#define __NEED_size_t
#define __NEED_ssize_t
#define __NEED_time_t
#define __NEED_timer_t
#define __NEED_clockid_t
#define __NEED_blkcnt_t
#define __NEED_fsblkcnt_t
#define __NEED_fsfilcnt_t
#define __NEED_id_t
#define __NEED_key_t
#define __NEED_clock_t
#define __NEED_suseconds_t
#define __NEED_blksize_t
#define __NEED_pthread_t
#define __NEED_pthread_attr_t
#define __NEED_pthread_mutexattr_t
#define __NEED_pthread_condattr_t
#define __NEED_pthread_rwlockattr_t
#define __NEED_pthread_barrierattr_t
#define __NEED_pthread_mutex_t
#define __NEED_pthread_cond_t
#define __NEED_pthread_rwlock_t
#define __NEED_pthread_barrier_t
#define __NEED_pthread_spinlock_t
#define __NEED_pthread_key_t
#define __NEED_pthread_once_t
#define __NEED_useconds_t
#if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
#define __NEED_int8_t
#define __NEED_int16_t
#define __NEED_int32_t
#define __NEED_int64_t
#define __NEED_u_int64_t
#define __NEED_register_t
#endif     <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< this is line 72
#include <bits/alltypes.h>
#if defined(_GNU_SOURCE) || defined(_BSD_SOURCE)
typedef unsigned char u_int8_t;
typedef unsigned short u_int16_t;
typedef unsigned u_int32_t;
typedef char *caddr_t;
typedef unsigned char u_char;
typedef unsigned short u_short, ushort;
typedef unsigned u_int, uint;
typedef unsigned long u_long, ulong;
typedef long long quad_t;
typedef unsigned long long u_quad_t;
#include <endian.h>
#include <sys/select.h>
#include <sys/sysmacros.h>
#endif
#if defined(_LARGEFILE64_SOURCE) || defined(_GNU_SOURCE)
#define blkcnt64_t blkcnt_t
#define fsblkcnt64_t fsblkcnt_t
#define fsfilcnt64_t fsfilcnt_t
#define ino64_t ino_t
#define off64_t off_t
#endif
#ifdef __cplusplus
}
#endif
#endif
++++ END CODE+++
As an experiment, I changed (thinking that unit8_t is not defined) unit8_t >> int but the error persisted:
8e3429fa0975:AMQP-CPP root# make
make -C src all
make[1]: Entering directory '/workspace/ws/AMQP-CPP/src'
g++ -Wall -c -I. -std=c++11 -MD -g -fpic -o receivedframe.o receivedframe.cpp
In file included from /usr/include/sys/types.h:72:0,
from /usr/include/netinet/tcp.h:61,
from includes.h:29,
from receivedframe.cpp:8:
connectionstartframe.h:124:9: error: expected unqualified-id before 'unsigned'
int major() const
^
connectionstartframe.h:124:9: error: expected ')' before 'unsigned'
I am running Linux in a Docker container:
8e3429fa0975:AMQP-CPP root# uname -or
4.4.38-boot2docker Linux

https://github.com/tommitytom/AMQP-CPP/commit/3a088734100fcca65261d1f891d781bdf47ac40b

@barabenka I have merged tommytom's fixes into my windows nuget build:
https://github.com/fantastory/AMQP-CPP
Would you mind to check if it builds on linux correctly?

Thank you fantastory, make in your branch succeeds.
Unfortunately, "make install" fails:
01b321ccefb8:AMQP-CPP root# make install
mkdir -p /usr/include/amqpcpp
mkdir -p /usr/lib
cp -f amqpcpp.h /usr/include
cp: can't stat 'amqpcpp.h': No such file or directory
make: *** [Makefile:29: install] Error 1

Arghhh. I moved all includes to single folder but i only "install" it on windows.
I'll get some linux machine to fix things up. Hopefully tommitytom's branch would work for you.

Thank you, @fantastory. Tommitytom's branch does compile. However, I get the following error, when I include amqpcpp.h :(:
In file included from /usr/local/include/amqpcpp.h:39:0,
from /workspace/ws/ocl/test/include/testOcl.h:24,
from /workspace/ws/ocl/test/src/testOcl.cpp:22:
/usr/local/include/amqpcpp/outbuffer.h: In member function 'void AMQP::OutBuffer::add(uint16_t)':
/usr/local/include/amqpcpp/outbuffer.h:162:35: error: 'htobe16' was not declared in this scope
uint16_t v = htobe16(value);
^
The htobe16 function is defined in endian.h. There are several endian.h files in the system. I don't know which one it is trying to use.... I will continue looking into it tomorrow.
Thanks again!

htobe16()? bigendian is the network one, you can safely use htons()

Thank you for your help. The call to htobe16 is in AMQP-CPP/inlcude/outbuffer.h, so, it is not my code. Removing the file AMQP-CPP/inlcude/endian.h  solved this issue. The system already has endian.h file which defined htobe16/32 functions. The file in AMQP-CPP/inlcude/endian.h was not compatible.

AMQP-CPP/inlcude/outbuffer.h is a system abstraction, it selects which system endian.h to include.
The file should be included as <amqpcpp\endian.h> rather than <endian.h>.
It seem that you are including it and (probably other files) from amqpcpp build library (where you downloaded it with git), rather than from its installation location (where make install puts them).
I guess, you have AMQP-CPP.git/inlcude/ in your build include path. I did the same and find it usefull when testing library. That is why I moved whole AMQP-CPP.git/inlcude/ to AMQP-CPP.git/inlcude/amqpcpp.

I'm having trouble building (worked fine few ago when I built it on another machine),
cmake output:
$ cmake -G "Unix Makefiles"
-- The C compiler identification is GNU 4.9.2
-- The CXX compiler identification is GNU 4.9.2
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++
-- Check for working CXX compiler: /usr/bin/g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Warning (dev) at CMakeLists.txt:52 (set):
  Cannot set "AMQP-CPP_INCLUDE_PATH": current scope has no parent.
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Configuring done
-- Generating done
-- Build files have been written to: /home/user/git/AMQP-CPP

make output:
[  7%] Building CXX object CMakeFiles/amqp-cpp.dir/src/array.cpp.o
In file included from /home/user/git/AMQP-CPP/src/includes.h:70:0,
                 from /home/user/git/AMQP-CPP/src/array.cpp:7:
/home/user/git/AMQP-CPP/src/../include/channelimpl.h: In member function ‘void AMQP::ChannelImpl::onError(const ErrorCallback&)’:
/home/user/git/AMQP-CPP/src/../include/channelimpl.h:231:24: error: invalid use of incomplete type ‘class AMQP::ConnectionImpl’
         if (_connection->connected()) return callback("Channel is in an error state, but the connection is valid");
                        ^
In file included from /home/user/git/AMQP-CPP/src/includes.h:33:0,
                 from /home/user/git/AMQP-CPP/src/array.cpp:7:
/home/user/git/AMQP-CPP/src/../include/classes.h:30:7: error: forward declaration of ‘class AMQP::ConnectionImpl’
 class ConnectionImpl;
       ^
CMakeFiles/amqp-cpp.dir/build.make:54: recipe for target 'CMakeFiles/amqp-cpp.dir/src/array.cpp.o' failed
make[2]: *** [CMakeFiles/amqp-cpp.dir/src/array.cpp.o] Error 1
CMakeFiles/Makefile2:60: recipe for target 'CMakeFiles/amqp-cpp.dir/all' failed
make[1]: *** [CMakeFiles/amqp-cpp.dir/all] Error 2
Makefile:117: recipe for target 'all' failed
make: *** [all] Error 2

This was caused by a wrong commit from me, and has now been solved.


Missing OnClose/Dispose for inactive items of Conductor.Collection.OneActive

#14 adds a regression. Methods OnClose and Dispose are only called for the active item when exiting the Stylet.Samples.TabNavigation application in 1.1.18. Both are expected to be called also for inactive items (as it was in 1.1.17).

Turns out this was a different issue, which was unmasked in your test case after #14. Pre-1.1.17, you could trigger this by doing 'conductor.Items.Clear()`.

Fixed in v1.1.19.


To add properties of Probability

Describe the solution you'd like
-I would like to add properties of probability under different section which will display all the properties

Hi, I want to work on this issue I will start working on it as soon as I get assigned!! I am a part of GSSoC'21.
Kindly assign this issue to me!
Discord Username : Abhijeet Sinha(P)
Discord Tag: #4018

Go ahead
Deadline 1 April,2021 (11:59 PM IST)

is this issue still open?If open, can i work on this issue?

Hi @Ayushgup85 yes this issue is open and its date has been extended because my exams are going on.

Go ahead
Deadline 6 April,2021 11:59 PM IST


docs: Update some URLs to our new vanity URLs

Also a little be of typo fixing and docs updating, mostly from comparing to the same docs in OIIO and picking the more thorough description.

Any comments on this docs-only change?


member list gradient thing bug

the black gradient at the bottom of members list scrolls with the list instead of staying locked to the bottom

fixed 1de5510


compatibility with angular 1.6

fixed the changes in angular 1.6. for the promise api. success replaced to .then callback.
bower json is original. tested with angular 1.6.

+1

You change the indentation of so many files, it's almost impossible to see the diffs. But at the end of the day I think this is almost the same change as the #145.

yep. i'm sorry for that, it was my atom config. great to have that issue fixed.

unfortunately too much white space changes to review.
I can add ?w=1 to the URL, but still.
there are unrelated changes that should not be part of this PR


BLE : ATT Timeout occurred during multilink central connection

Describe the bug
Situation:
Modify the example of zephyr BLE central_hr so that it can be connected to multiple peripherals.
Each peripheral will subscribe to the central, and then the peripheral uses notify to send the data to the central, and the central uses bt_gatt_write to return the value to the peripheral.
Now I use one central to 5 peripherals to test connection stability
It will work normally at first, but after a period of time, central will suddenly get stuck and the following error message will pop up.
[00:00:00.258,422] <inf> bt_hci_core: Y123
[00:00:00.260,131] <inf> bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.260,131] <inf> bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.260,162] <inf> bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 2.4 Build 0
[00:00:00.260,925] <inf> bt_hci_core: Identity: ec:e4:cd:dc:1b:f0 (random)
[00:00:00.260,955] <inf> bt_hci_core: HCI: version 5.2 (0x0b) revision 0x0000, manufacturer 0x05f1
[00:00:00.260,955] <inf> bt_hci_core: LMP: version 5.2 (0x0b) subver 0xffff
[00:02:11.060,974] <err> bt_att: ATT Timeout
[00:02:11.069,580] <err> bt_att: ATT Timeout
[00:02:11.071,502] <wrn> bt_att: No pending ATT request
[00:02:11.071,502] <err> os: ***** MPU FAULT *****
[00:02:11.071,502] <err> os:   Data Access Violation
[00:02:11.071,502] <err> os:   MMFAR Address: 0x4
[00:02:11.071,502] <err> os: r0/a1:  0x00006899  r1/a2:  0x00024ddb  r2/a3:  0x20fb52f0
[00:02:11.071,533] <err> os: r3/a4:  0x00000004 r12/ip:  0x20003adc r14/lr:  0x0000db19
[00:02:11.071,533] <err> os:  xpsr:  0x61000000
[00:02:11.071,533] <err> os: Faulting instruction address (r15/pc): 0x0002600a
[00:02:11.071,533] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:02:11.071,533] <err> os: Current thread: 0x200013f0 (unknown)
[00:02:12.646,545] <err> os: Halting system

In addition, the time of each error is random
Sometimes jump out <err> bt_gatt: Error sending ATT PDU: -57
And I made the following changes in prj.conf
CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_CENTRAL=y
CONFIG_BT_SMP=y
CONFIG_BT_GATT_CLIENT=y
CONFIG_GPIO=y
CONFIG_NRFX_SPIS0=y
CONFIG_BT_MAX_CONN=5
CONFIG_BT_PRIVACY=n
CONFIG_BT_DEVICE_NAME="zephyr"
CONFIG_BT_DEVICE_APPEARANCE=833
CONFIG_BT_DEVICE_NAME_DYNAMIC=y
CONFIG_BT_DEVICE_NAME_MAX=65
CONFIG_USERSPACE=y
CONFIG_HEAP_MEM_POOL_SIZE=4096
CONFIG_BT_RX_BUF_LEN=258
CONFIG_BT_ATT_TX_MAX=10
CONFIG_BT_ATT_PREPARE_COUNT=5
CONFIG_BT_CONN_TX_MAX=18
CONFIG_BT_L2CAP_TX_BUF_COUNT=18
CONFIG_BT_L2CAP_TX_MTU=247
CONFIG_BT_L2CAP_RX_MTU=247
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_RX_BUFFERS=18
CONFIG_BT_CTLR_TX_BUFFERS=18
CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_CTLR_ADVANCED_FEATURES=y
CONFIG_BT_CTLR_XTAL_THRESHOLD=500000

Expected behavior
At present, I want to allow central to communicate with 30 peripherals through BLE, so that the connection will continue to be stable. If the peripheral is disconnected, it will be reconnected, and there will be no bt_att: ATT Timeout error.
Impact
I don’t know which side is the problem at the moment, I don’t know what to do, I’m very helpless.
Logs and console output
Usually there are errors as shown below

Sometimes there will be more <err> bt_gatt: Error sending ATT PDU

The link is my running video. The first few minutes were normal and met my expectations, but in the end it got stuck and an error occurred
https://youtu.be/m5Ki--iXmXw
Environment (please complete the following information):

OS: Ubuntu 18.04.5 LTS
Zephyr version: 2.4.99

Additional context
This is my central code, if you need to read it, you can download it, hope it helps
C_N_w.zip

Please ensure that you use unique GATT parameter variables for each simultaneous connection. For instance, your cmd_read which is using the same single static struct bt_gatt_read_params read_params; across all active connections.

Hello
I'm not sure what you mean, I didn't use cmd_read, I did bt_gatt_write on the conn when I received the notify from the peripheral
This should not use the same.

Please ensure that you use unique GATT parameter variables for each simultaneous connection. For instance, your cmd_read which is using the same single static struct bt_gatt_read_params read_params; across all active connections.
@cvinayak
Hello
Or should I modify my bt_gatt_write_params to be like this?
static struct bt_gatt_write_params write_params[CONFIG_BT_MAX_CONN];
Then when writing, use this to manage?
write_params[bt_conn_index(conn)]

yes, something like that, to avoid using the same memory for multiple simultaneous transactions.

Indeed, this has improved a lot, which made my connection stable for more than 3 hours.
But in the end there was still the problem of ATT timeout error.

yes, something like that, to avoid using the same memory for multiple simultaneous transactions.

In this case, does discover_params also need to be set to
 static struct bt_gatt_discover_params discover_params[CONFIG_BT_MAX_CONN];?
So ATT timeout error, is it a problem that occurs when I use the same memory for multiple transactions at the same time?

is it a problem that occurs when I use the same memory for multiple transactions at the same time?

Yes.
If you have based your application out of an upstream sample. I suggest you send a PR with your changes to make the sample capable of multiple connections simultaneously. This will make it easier to review your changes.

I suggest you send a PR with your changes to make the sample capable of multiple connections simultaneously.

I don’t really understand, how can I send a PR? Is there any sample code?
In addition, I found that I can improve my stability by changing these
#define MIN_CONNECTION_INTERVAL
#define MAX_CONNECTION_INTERVAL
#define SLAVE_LATENCY
#define SUPERVISION_TIMEOUT

Is there any reason for this?

I pulled my code request but I’m not sure if I’m doing this right
https://github.com/zephyrproject-rtos/zephyr/pull/30680#issue-538975971

Multiple connections are being established sequntially and gatt service discovery is performed using the same single instance of discover_params. This is bug in application and not in the Bluetooth Subsystem.
No guard preventing sequential multiple connections:
https://github.com/zephyrproject-rtos/zephyr/pull/30680/files#diff-2fcfc31aeea68ed5719fe2686a5507a564ea9c85d0ca14216d6d6953eb7af5f8R452
Use of single instance of discover_params to perform GATT discovery:
https://github.com/zephyrproject-rtos/zephyr/pull/30680/files#diff-2fcfc31aeea68ed5719fe2686a5507a564ea9c85d0ca14216d6d6953eb7af5f8R574

Multiple connections are being established sequntially and gatt service discovery is performed using the same single instance of discover_params. This is bug in application and not in the Bluetooth Subsystem.
No guard preventing sequential multiple connections:
https://github.com/zephyrproject-rtos/zephyr/pull/30680/files#diff-2fcfc31aeea68ed5719fe2686a5507a564ea9c85d0ca14216d6d6953eb7af5f8R452
Use of single instance of discover_params to perform GATT discovery:
https://github.com/zephyrproject-rtos/zephyr/pull/30680/files#diff-2fcfc31aeea68ed5719fe2686a5507a564ea9c85d0ca14216d6d6953eb7af5f8R574

Resolving as issue in the user's code. Please reopen if you find that not to be the case.

Resolving as issue in the user's code. Please reopen if you find that not to be the case.


Adding AWS ECS Service Discovery

Adding a service discovery handler that queries the aws sdk for ecs services. If it
finds a service running with an exposed port in the defined port range
, it is added a scraping target.
Docker labels are also copied over automatically as labels.
Had to update the aws sdk in /vendor, which caused some small changes in
the ec2 sd. Most of the files in the PR are the AWS sdk update, since it was quite out of date. I tried to remove most of the unneeded files from it, such as tests.

This change is

Hi!
Is this feature/branch alive? Will be updated or can we work on the same feature?
Thanks!

Per another PR, the API rate limits are so low that this isn't practical.


Allow cgp to be larger.

We store the size of globals as a shifted value, which extends the maximum size of globals in a compartment from 64 KiB to 256 KiB.
This adds two new tests.  One is added to the misc test and just checks that we correctly handle globals that are larger than the range of a csetbounds with an immediate offset.
The second checks that much larger globals work.  This test is disabled because it uses so much RAM that we don't have enough for the allocator tests.
At some point, we should refactor the test suite to allow subsets of the test suite to be built.
Add test for large objects.
Fixes #230

I see the linker script catches single data structures that are too large but when the big data segment is something that overflows total memory the test suite links but fails at runtime (though I'm not using sail so this might be peculiar to my environment).

That's something I'd expect to be caught by something device specific.  If you create a firmware file that is larger than the memory then you've done something wrong.  It's probably a good idea to add a check in the loader though.

It appears simple to support even larger data but that would require a "non-standard" compartment def (and raise the minimum). It turns out my original test case used a 320K array which does not fit with a shift of 2. Probably good enough to require users to handle this but a comment explaining where all the "/4"s are would be helpful (maybe just a pointer to the eventual commit).

We can look at that.  This is a simple fix that doesn't require significant changes and allows a single compartment to be as big as we expect the largest SRAM to be for most devices in the next year or so.  If people are shipping devices with more than 256 KiB of SRAM then that's a good time to revisit it.  On devices like that, the size savings from using 16-bit sizes are largely irrelevant and it's probably simpler to just use a 32-bit size.
I would expect most use cases to want to use the heap for this kind of thing, rather than a static carve out.  That would let you do things like use a big chunk of RAM for some post-quantum key exchange on boot to get a per-session symmetric key and then recycle the memory for your workload, for example, whereas a fixed carveout would require more total SRAM.
As previously discussed, the heap would require some work to allow it to support larger total memory sizes.  This isn't too difficult, but it is not urgent for us since it is not a feature that any of the current prototyping platforms or any ASICs that we expect to see in the near term can use.  If it's something that you want to work on, I can help find the places in the code that will need changing.


added vpdn and vpdn-group, extended aaa, ntp and some other small por…

…tions

Sorry for not having merged this yet. I'll take a closer look at it later today.
Cheers!

Thanks! Merged and pushed a new version


Occasional errors when .post()'ing alert to an HTTP server

In a percentage of times (5-40%), we get a Connection reset error on the HTTP server that receives the POST request from the alert node. We handle the alert just fine so this is not critical, but it seems that the connection is closed before it gets a chance to reply.
CAUSE: java.net.SocketException: Connection reset
The exception is thrown when attempting to write a response to the socket. The response is usually sent within 1ms of receiving the POST request. Is there some configurable timeout or intentional reason why we'd reset the connection so soon?

@lpalm  Are there any relevant errors in the Kapacitor logs during those times?

Doesn't look like it.
My version is Kapacitor 1.0.0~beta1 (git: master c6f7db54eeccc0cced849740a53f256458259966), by the way.

@lpalm Ok thanks for checking. This is going to take some work to figure out. The code for the post handler is trivially simple, so the issue is likely hidden in the Golang net/http package's default transport.

Here's a shot in the dark.
Is this code is handling the alert POST request? https://github.com/influxdata/kapacitor/blob/b56550e110033892f1635339b57e2d510c637281/alert.go#L809
If so, should we be setting any headers here (e.g. content-type?)


Loading GEO on Ontobee

From http://purl.obolibrary.org/obo/geo.owl
Thanks,
Melanie

Loading GEO failed.
The error messages:
Loading RDF store:
geo: loading data from http://purl.obolibrary.org/obo/geo.owl
geo: getting final url http://purl.obolibrary.org/obo/geo.owl
Coult not load ontology:
org.semanticweb.owlapi.model.UnloadableImportException: Could not load imported ontology: http://www.ifomis.org/bfo/1.1 Cause: Problem parsing http://www.ifomis.org/bfo/1.1
Could not parse ontology.  Either a suitable parser could not be found, or parsing failed.  See parser logs below for explanation.
The following parsers were tried:

RDFXMLParser
OWLXMLParser
OWLFunctionalSyntaxOWLParser
TurtleOntologyParser
OWLOBOParser
KRSS2OWLParser
ManchesterOWLSyntaxOntologyParser

Detailed logs:
Parser: RDFXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLFunctionalSyntaxOWLParser
Encountered "  "< "" at line 1, column 1.
Was expecting:
"Ontology" ...
(Line 0)

Parser: TurtleOntologyParser
uk.ac.manchester.cs.owl.owlapi.turtle.parser.ParseException: Encountered "" at line 1, column 1.
Was expecting one of:

Parser: OWLOBOParser
org.coode.owlapi.obo.parser.TokenMgrError: Lexical error at line 1, column 51.  Encountered: "\n" (10), after : ""

Parser: KRSS2OWLParser
de.uulm.ecs.ai.owlapi.krssparser.ParseException: Encountered " ">" " "" at line 1, column 1.
Was expecting:

Parser: ManchesterOWLSyntaxOntologyParser
Encountered '' at line 1 column 1.  Expected either 'Ontology:' or 'Prefix:' (Line 1)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1077)
    at org.coode.owlapi.owlxmlparser.OWLImportsHandler.endElement(OWLImportsHandler.java:28)
    at org.coode.owlapi.owlxmlparser.OWLXMLParserHandler.endElement(OWLXMLParserHandler.java:895)
    at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLNSDTDValidator.endNamespaceScope(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
    at org.coode.owlapi.owlxmlparser.OWLXMLParser.parse(OWLXMLParser.java:47)
    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:165)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:687)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:628)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:602)
    at org.hegroup.rdfstore.OWLMerge.main(OWLMerge.java:65)

Caused by: org.semanticweb.owlapi.io.UnparsableOntologyException: Problem parsing http://www.ifomis.org/bfo/1.1
Could not parse ontology.  Either a suitable parser could not be found, or parsing failed.  See parser logs below for explanation.
The following parsers were tried:

RDFXMLParser
OWLXMLParser
OWLFunctionalSyntaxOWLParser
TurtleOntologyParser
OWLOBOParser
KRSS2OWLParser
ManchesterOWLSyntaxOntologyParser

Detailed logs:
Parser: RDFXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLFunctionalSyntaxOWLParser
Encountered "  "< "" at line 1, column 1.
Was expecting:
"Ontology" ...
(Line 0)

Parser: TurtleOntologyParser
uk.ac.manchester.cs.owl.owlapi.turtle.parser.ParseException: Encountered "" at line 1, column 1.
Was expecting one of:

Parser: OWLOBOParser
org.coode.owlapi.obo.parser.TokenMgrError: Lexical error at line 1, column 51.  Encountered: "\n" (10), after : ""

Parser: KRSS2OWLParser
de.uulm.ecs.ai.owlapi.krssparser.ParseException: Encountered " ">" " "" at line 1, column 1.
Was expecting:

Parser: ManchesterOWLSyntaxOntologyParser
Encountered '' at line 1 column 1.  Expected either 'Ontology:' or 'Prefix:' (Line 1)
    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:197)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:687)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:628)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadImports(OWLOntologyManagerImpl.java:1045)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1070)
    ... 21 more

geo: loading data from http://purl.obolibrary.org/obo/geo.owl
geo: getting final url http://purl.obolibrary.org/obo/geo.owl
Coult not load ontology:
org.semanticweb.owlapi.model.UnloadableImportException: Could not load imported ontology: http://www.ifomis.org/bfo/1.1 Cause: Problem parsing http://www.ifomis.org/bfo/1.1
Could not parse ontology.  Either a suitable parser could not be found, or parsing failed.  See parser logs below for explanation.
The following parsers were tried:

RDFXMLParser
OWLXMLParser
OWLFunctionalSyntaxOWLParser
TurtleOntologyParser
OWLOBOParser
KRSS2OWLParser
ManchesterOWLSyntaxOntologyParser

Detailed logs:
Parser: RDFXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLFunctionalSyntaxOWLParser
Encountered "  "< "" at line 1, column 1.
Was expecting:
"Ontology" ...
(Line 0)

Parser: TurtleOntologyParser
uk.ac.manchester.cs.owl.owlapi.turtle.parser.ParseException: Encountered "" at line 1, column 1.
Was expecting one of:

Parser: OWLOBOParser
org.coode.owlapi.obo.parser.TokenMgrError: Lexical error at line 1, column 51.  Encountered: "\n" (10), after : ""

Parser: KRSS2OWLParser
de.uulm.ecs.ai.owlapi.krssparser.ParseException: Encountered " ">" " "" at line 1, column 1.
Was expecting:

Parser: ManchesterOWLSyntaxOntologyParser
Encountered '' at line 1 column 1.  Expected either 'Ontology:' or 'Prefix:' (Line 1)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1077)
    at org.coode.owlapi.owlxmlparser.OWLImportsHandler.endElement(OWLImportsHandler.java:28)
    at org.coode.owlapi.owlxmlparser.OWLXMLParserHandler.endElement(OWLXMLParserHandler.java:895)
    at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLNSDTDValidator.endNamespaceScope(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLDTDValidator.handleEndElement(Unknown Source)
    at org.apache.xerces.impl.dtd.XMLDTDValidator.endElement(Unknown Source)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
    at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
    at org.coode.owlapi.owlxmlparser.OWLXMLParser.parse(OWLXMLParser.java:47)
    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:165)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:687)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:628)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:602)
    at org.hegroup.rdfstore.OWLMerge.main(OWLMerge.java:65)

Caused by: org.semanticweb.owlapi.io.UnparsableOntologyException: Problem parsing http://www.ifomis.org/bfo/1.1
Could not parse ontology.  Either a suitable parser could not be found, or parsing failed.  See parser logs below for explanation.
The following parsers were tried:

RDFXMLParser
OWLXMLParser
OWLFunctionalSyntaxOWLParser
TurtleOntologyParser
OWLOBOParser
KRSS2OWLParser
ManchesterOWLSyntaxOntologyParser

Detailed logs:
Parser: RDFXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLXMLParser
org.xml.sax.SAXParseException; systemId: http://www.ifomis.org/bfo/1.1; lineNumber: 1; columnNumber: 50; White spaces are required between publicId and systemId.

Parser: OWLFunctionalSyntaxOWLParser
Encountered "  "< "" at line 1, column 1.
Was expecting:
"Ontology" ...
(Line 0)

Parser: TurtleOntologyParser
uk.ac.manchester.cs.owl.owlapi.turtle.parser.ParseException: Encountered "" at line 1, column 1.
Was expecting one of:

Parser: OWLOBOParser
org.coode.owlapi.obo.parser.TokenMgrError: Lexical error at line 1, column 51.  Encountered: "\n" (10), after : ""

Parser: KRSS2OWLParser
de.uulm.ecs.ai.owlapi.krssparser.ParseException: Encountered " ">" " "" at line 1, column 1.
Was expecting:

Parser: ManchesterOWLSyntaxOntologyParser
Encountered '' at line 1 column 1.  Expected either 'Ontology:' or 'Prefix:' (Line 1)
    at uk.ac.manchester.cs.owl.owlapi.ParsableOWLOntologyFactory.loadOWLOntology(ParsableOWLOntologyFactory.java:197)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:687)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadOntology(OWLOntologyManagerImpl.java:628)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.loadImports(OWLOntologyManagerImpl.java:1045)
    at uk.ac.manchester.cs.owl.owlapi.OWLOntologyManagerImpl.makeLoadImportRequest(OWLOntologyManagerImpl.java:1070)
    ... 21 more

Failed to download owl file!
Done!
Oliver
From: Melanie Courtot<EMAIL_ADDRESS>Sent: Wednesday, May 13, 2015 6:32 PM
To: ontoden/ontobee
Subject: [ontobee] Loading GEO on Ontobee (#41)
From http://purl.obolibrary.org/obo/geo.owl
Thanks,
Melanie
—
Reply to this email directly or view it on GitHubhttps://github.com/ontoden/ontobee/issues/41.

Electronic Mail is not secure, may not be read every day, and should not be used for urgent or sensitive issues

GEO is already loaded into Ontobee.
I am closing this issue. Thanks.


MAPREDUCE-7416. Upgrade Junit 4 to 5 in hadoop-mapreduce-client-shuffle

Description of PR
Upgrade Junit 4 to 5 in hadoop-mapreduce-client-shuffle
JIRA - MAPREDUCE-7416
For code changes:

[X] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
1m 27s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
45m 47s

trunk passed

+1 :green_heart:
compile
0m 30s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
0m 29s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 31s

trunk passed

+1 :green_heart:
mvnsite
0m 32s

trunk passed

+1 :green_heart:
javadoc
0m 36s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javadoc
0m 27s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
0m 57s

trunk passed

+1 :green_heart:
shadedclient
25m  6s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 30s

the patch passed

+1 :green_heart:
compile
0m 24s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
0m 24s

the patch passed

+1 :green_heart:
compile
0m 21s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
0m 21s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 1 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-0 :warning:
checkstyle
0m 15s
/results-checkstyle-hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-shuffle.txt
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle: The patch generated 5 new + 20 unchanged - 1 fixed = 25 total (was 21)

+1 :green_heart:
mvnsite
0m 23s

the patch passed

+1 :green_heart:
javadoc
0m 19s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javadoc
0m 19s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
0m 50s

the patch passed

+1 :green_heart:
shadedclient
24m 58s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
0m 46s

hadoop-mapreduce-client-shuffle in the patch passed.

+1 :green_heart:
asflicense
0m 38s

The patch does not generate ASF License warnings.

108m 16s

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5340/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5340

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint spotbugs checkstyle

uname
Linux 3294d9f52775 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / af53e96bd24cc4f5990ca3688eb0e1d4092efe16

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5340/1/testReport/

Max. process+thread count
752 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle U: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5340/1/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

Hi @aajisaka. This is the rebase of this https://github.com/apache/hadoop/pull/5020. Please help in review. Thanks

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 59s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  1s

codespell was not available.

+0 :ok:
detsecrets
0m  1s

detect-secrets was not available.

+0 :ok:
xmllint
0m  1s

xmllint was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 3 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
47m 40s

trunk passed

+1 :green_heart:
compile
0m 31s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
compile
0m 30s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
checkstyle
0m 32s

trunk passed

+1 :green_heart:
mvnsite
0m 33s

trunk passed

+1 :green_heart:
javadoc
0m 38s

trunk passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javadoc
0m 27s

trunk passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
0m 55s

trunk passed

+1 :green_heart:
shadedclient
23m 10s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 29s

the patch passed

+1 :green_heart:
compile
0m 22s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javac
0m 22s

the patch passed

+1 :green_heart:
compile
0m 20s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
javac
0m 20s

the patch passed

-1 :x:
blanks
0m  0s
/blanks-eol.txt
The patch has 1 line(s) that end in blanks. Use git apply --whitespace=fix <<patch_file>>. Refer https://git-scm.com/docs/git-apply

-0 :warning:
checkstyle
0m 15s
/results-checkstyle-hadoop-mapreduce-project_hadoop-mapreduce-client_hadoop-mapreduce-client-shuffle.txt
hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle: The patch generated 1 new + 20 unchanged - 1 fixed = 21 total (was 21)

+1 :green_heart:
mvnsite
0m 23s

the patch passed

+1 :green_heart:
javadoc
0m 20s

the patch passed with JDK Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04

+1 :green_heart:
javadoc
0m 19s

the patch passed with JDK Private Build-1.8.0_352-8u352-ga-1~20.04-b08

+1 :green_heart:
spotbugs
0m 46s

the patch passed

+1 :green_heart:
shadedclient
22m 48s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
0m 48s

hadoop-mapreduce-client-shuffle in the patch passed.

+1 :green_heart:
asflicense
0m 37s

The patch does not generate ASF License warnings.

105m 20s

Subsystem
Report/Notes

Docker
ClientAPI=1.42 ServerAPI=1.42 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5340/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/5340

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient codespell detsecrets xmllint spotbugs checkstyle

uname
Linux 7d4c7e17dfba 4.15.0-200-generic #211-Ubuntu SMP Thu Nov 24 18:16:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 8875536ad645c5fdc7969c75aa49ef305aa53e27

Default Java
Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Multi-JDK versions
/usr/lib/jvm/java-11-openjdk-amd64:Ubuntu-11.0.17+8-post-Ubuntu-1ubuntu220.04 /usr/lib/jvm/java-8-openjdk-amd64:Private Build-1.8.0_352-8u352-ga-1~20.04-b08

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5340/2/testReport/

Max. process+thread count
741 (vs. ulimit of 5500)

modules
C: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle U: hadoop-mapreduce-project/hadoop-mapreduce-client/hadoop-mapreduce-client-shuffle

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-5340/2/console

versions
git=2.25.1 maven=3.6.3 spotbugs=4.2.2

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


Add NeRF--

NeRF--: Neural Radiance Fields Without Known Camera Parameters
by  Zirui Wang, Shangzhe Wu, Weidi Xie, Min Chen, Victor Adrian Prisacariu.
An end-to-end framework for training NeRF models given only RGB images, without pre-computed camera parameters.

As I observed from a lot of experiments I have conducted with NeRF (on real world car scenes), it is true that NeRF doesn't require any "correct" intrinsics+extrinsics to achieve good results. By "correct" I mean careful camera calibration using checkerboard and so on. Rather, using these correct values, surprisingly, produces inferior performance. Hence now I'm always using colmap estimated values even if they are not "correct", and it also seems that there exists a lot of possible intrinsics+extrinsics combinations that make NeRF work well.
This work confirms my experience that many calibrations work for NeRF, and it is possible to learn one of them. I'm looking forward to experimenting how it performs with my data and how much longer it takes compared to NeRF+COLMAP (there are more parameters to optimize, so I expect a longer training time, but at the same time it saves COLMAP time).

Hello @mwtarnowski , thanks again!
Same as the previous PR, I have put the citation of this paepr here. Could you update your PR to cite this txt file?
Very helpful and timely PR!

@kwea123 Why not colmap init + updating camera parameters during NeRF optimization?

Done.

Thank you!

@kwea123 Why not colmap init + updating camera parameters during NeRF optimization?

Yes, it also improves the score, as shown by the paper. It's something I'd like to implement and test in the future.

@kwea123 no problem!


new(modern_bpf): add readv,preadv,pread syscall

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test

/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area API-version

/area build

/area CI

/area driver-kmod

/area driver-bpf

/area driver-modern-bpf

/area libscap-engine-bpf

/area libscap-engine-gvisor

/area libscap-engine-kmod

/area libscap-engine-modern-bpf

/area libscap-engine-nodriver

/area libscap-engine-noop

/area libscap-engine-source-plugin

/area libscap-engine-savefile

/area libscap-engine-udig

/area libscap

/area libpman

/area libsinsp

/area tests

/area proposals

Does this PR require a change in the driver versions?

/version driver-API-version-major

/version driver-API-version-minor

/version driver-API-version-patch

/version driver-SCHEMA-version-major

/version driver-SCHEMA-version-minor

/version driver-SCHEMA-version-patch

What this PR does / why we need it:
Support for readv, preadv,pread syscall in modern bpf
Which issue(s) this PR fixes:

Part of #723
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

NONE

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: loresuso
Once this PR has been reviewed and has the lgtm label, please assign gnosek for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Ready for review!

I'm adding also preadv and pread soon, since they are similar

Added all three syscalls!

LGTM label has been added.  Git tree hash: 39cfbc1a308b368607859a9424eb46d8f6e14ea1

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: incertum, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

New changes are detected. LGTM label has been removed.

/milestone next-driver

LGTM label has been added.  Git tree hash: 972de1957b7e7ebdd5ff4dd504456870a433ec57

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: incertum, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/hold

New changes are detected. LGTM label has been removed.

I have rebased this PR and solved conflicts with the socketcall one (pay attention), and addressed @Andreagit97 comment, nice catch! Btw, I am not getting why ci/circleci: test-drivers-engines-arm64 is failing 🤔

LGTM label has been added.  Git tree hash: 8266ebaa0a540aae33cd0e7db5d0821f6a4f3f3a

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, incertum, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, incertum, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

/unhold

/close
/reopen

@loresuso: Closed this PR.

In response to this:

/close
/reopen

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

/reopen

@loresuso: Reopened this PR.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, hbrueckner, incertum, loresuso
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [Andreagit97,FedeDP,incertum]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Proposed RFC Suggestion: Make community the clearing house of process

Summary:
Add structure to community repro to provide guidance to new users and to aid discovery of the great content here.
Proposing we organize content around three main themes

Develop (Use existing https://github.com/o3de/community/tree/main/contributors)

Links to existing getting started guides
Overview of how to contribute
Links to existing Contribution guides (ie https://github.com/o3de/community/pull/144, https://github.com/o3de/community/blob/main/CONTRIBUTING.md)
Links to style / coding guides
Links to deprecation guide
Breaking change guide
RFC process
Brief doc on how PRs work - Making PR, link to guides, AR process etc (link to https://github.com/o3de/community/pull/144)

Process (New https://github.com/o3de/community/tree/main/process)

How to communicate with the project (discuss GHI, Discord, mailing lists)
Division of effort, TSC, SIGs and what they are responsibie for, marketting.
How to file bugs and feature requests - Making GHI, expectations
How to update the community docs (guidance for contributors to these pages)

SIGs (New https://github.com/o3de/community/tree/main/sigs)

Common SIG docs include SIG issue triage guide, PR guide
Election process

Update the README.md to be more of a landing page.
What is the motivation for this suggestion?
Community has lots of useful content but theres no organization, theres no guide as to what this is or where to find content.
Suggestion design description:
Covered above mostly so skipping detailed design for now

May as needed move some docs (like SIG election guidance) under these folders, to provide more clarity.
Not proposing move https://github.com/o3de/community/blob/main/CONTRIBUTING.md as this is linked from several external locations, but may revise to add some additional links.

What are the advantages of the suggestion?
Make o3de/community be the process wiki for the project like https://wiki.blender.org/wiki/Main_Page. Acts the clearing house for links, even if the links are SIG/release or other repros
What are the disadvantages of the suggestion?

Currently no clear guidance around who can update community. Lack of ownership from all SIGs.
May repeat existing content, but will improve discovery of content thats not on o3de.org

How will this be work within the O3DE project?

It will only contain general guidance information, SIG specific information will just be linked.
Will add links to https://www.o3de.org/contribute/ and https://www.o3de.org/docs/contributing/ where appropriate.

Are there any alternatives to this suggestion?

Could use the actual GitHub wiki but theres no approval mechanism there, anyone with permissions can live edit.
Expand https://www.o3de.org/docs/contributing/ and https://www.o3de.org/contribute/ . But believe o3de.org and docs-community do not have capacity or desire to own 'process' docs.

What is the strategy for adoption?

Will review o3de.org links for contributors and redirect to o3de/community as much as possible. Some of the content will migrate to o3de.org site
Advertise in sig-all when changes are made, to increase visibility and request contributions
Work with TSC to gain guidance and alignment for other things.

I'm fully supportive of this idea! 🥳
For the Develop section, I'd suggest moving all 'guide' style docs to the 'guides' folder (currently in the root of the community repo with review and deprecation guides being there already, it could be moved to go under a 'Develop' folder in future). There are some docs in sig-core for things like coding standards and API ref guidelines that could be moved there too.
Overall an excellent idea and it will definitely help people from the community find their way around much more easily!
Thanks @lmbr-pip! 😄

Early contribution towards this: https://github.com/o3de/community/pull/151

I support this RFC proposal!
As part of the development theme, I suggest we also include links to docs contribution guides to the community landing page. (Assuming that these themes are the basis of creating the landing page.)
+1 to have README.md be a landing page. This will highly improve visibility of all the important information in this repo. I see this page being a great starting point for contributors. To further increase visibility and unification, I'd also recommend other sigs link back to the community landing page as well.
For the general process docs in this community repo, the processes for docs may differ so we'll need to link accordingly. Feel free to add me or sig-docs-community to related PRs, so I can watch out for these. (I've added some comments to the PR you linked above, for example.)
I'm all for updating o3de.org/docs/contributing and o3de.org/contribute as well, to be consistent with the community repo. I think this is an important step so that the separate contributing docs don't feel disjointed.
Awesome stuff, thanks for putting this together 🙂


Added RebaseCommand

Background
We're replacing all Git CLI calls in our plugin with those of the Git Client, since we'd like to make use of the Credentials API, but it's missing the ability to rebase.
Related issue: JENKINS-30839
Implementation
I added a RebaseCommand and added it to all the GitClient implementations. The implementations are pretty bare-bones and only allow for setting the target.
Testing
I added two test cases that test the rebase with and without a conflict. I also tested our own plugin, using a snapshot version of the git client, all the tests pass and the rebase works just fine.

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

@praqma-thi is this still of interest to you? I haven't seen an answer to my earlier question on recovery from rebase failure.

Definitely. I committed some changes adding recovery to the CLI implementation and cleaning the JGIT implementation up a bit. I must've forgotten leaving a message about it.

Thanks.  I'll evaluate the changes and let you know what I learn.

@MarkEWaite Is there anything else you'd like to see done/tested before this can be merged in?

Nothing else that I need from you.

Merged to master, with some additional assertions added to the recovery case.


feat(#major); qidao; add eth and harmony deployments

#1431 Add QiDao Ethereum and Harmony Deployments. Moonbeam has no vaults labeled in the docs: https://docs.mai.finance/functions/smart-contract-addresses
Testing:

https://okgraph.xyz/?q=dmelotik%2Fqidao-harmony
https://okgraph.xyz/?q=dmelotik%2Fqidao-ethereum

@ishraq8 could you put these on your list to QA

@dmelotik Everything looks good but I am a bit confused about the supplyside revenue. Is ethereum excluded from supplyside? it is showing zero

Updated docs here: https://github.com/messari/subgraphs/pull/1677
should be good to go


[6.0] Parse #if canImport as a function call instead of a specialized expression node

Explanation: The parser had special knowledge about how to parse canImport inside #if conditions. This was inconsistent with eg. the parsing of #if swift(<6.0), which gets parsed as a function call. To make it easier to interpret the version passed to canImport(MyModule, _version: <#version#>), add ExprSyntax.interpretedAsVersionTuple that takes eg. 1.2.3, which got parsed as a member access 3 to the 1.2 float literal and re-parses it as a VersionTupleSyntax. This relaxation also allows string literals as version parameters to #if canImport.
Scope: Parsing of canImport directives in #if conditions.
Risk: Low, we’ve to quite a few tests for this, function calls are more permissive than CanImportExprSyntax and it is unlikely that anyone is relying on the interpretation of the version number
Testing: Updated the existing test cases
Issue: rdar://121070235, #1972
Reviewer:  @bnbarham and @rintaro on https://github.com/apple/swift-syntax/pull/2025

@swift-ci Please test

@swift-ci Please test Windows


Dynamically resizing jstree container to fit width of items as they are expanded

I've got a jstree in a container that I would like to horizontally expand as items of the jstree are expanded. Here is a jsfiddle describing my current situation: http://jsfiddle.net/0xwg3c2c/
How can I accomplish this?

This is not jstree related, but still: http://jsfiddle.net/0xwg3c2c/4/
Best regards,
Ivan


[BREAKING] tokenizeEBTCard on ForageSDK accepts ForagePANEditText as arg

I accidentally closed #61. This is a duplicate if you are experiencing dejavu
Description
Previously tokenizeEBTCard's implementation relied on
the sharing of panEntry within the ForageSDK singleton
object. Sharing state is generally considered bad practice
because it does not scale to multiple parallel consumptions
well.
This commit decouples (and deletes) the shared state. Now,
tokenizeEBTCard accepts a ForagePANEditText as an argument
and has no reliance on shared state. The end result is:

easier to test the shouldTokenize logic since it can be
extract to a service and not live in the view layer near the
shared state
no shared state means multiple instances of ForagePANEditText
can co-exist without issue

Also

[x] update the Sample App to pass the ForagePANEditText element. Will do that in a subsequent commit
[x] update the README.md to describe new usage of ForageSDK.tokenizeEBTCard
[ ] Add video recording showcasing flow still works as expected

Tests Added / Updated?

YES - this PR adds service layer tests for the guard logic of whether to tokenize an EBT card
NO - we still don't have espresso enabled so no end-2-end tests to validate new view logic. Instead I'll provide screenshots

Screenshots

Closing this PR to create a new one associated with the branch devin/fx-423-android-remove-storeentry-and-panentry-related-code so that the Linear bot can track this


[InterFlux] Consolidation polling loop

The client calls have been tested in isolation, but not as part of the full poller yet.

Re-opened


Being stuck on Rust 1.61.0 is unacceptable

We are rapidly approaching (really, have passed already several times over) the point where it does not make sense to continue pinning a version, even for the convenience of anyone's security processes.

rustc 1.61.0 is not supported from a security perspective, as it is not the latest version. If there are any showstopping security bugs, the Rust Project will not fix them. So there will never be a rustc 1.61.1. The way the Rust Project tends to spell "security patch" is "next train" and thus the patch release for rustc 1.61.0 is actually 1.62.0.
By not upgrading, we are passing on critical fixes to rustc's handling of the aarch64 call ABI, and are essentially hoping and praying that, if deployed on aarch64, we don't hit it.
Some versions of rustc introduce relatively major features and programming conveniences to stable usage. 1.65 is particularly notable for introducing the initial version of generic associated types. These are very useful for complex ownership lifetime situations, the classic one being an iterator that yields elements with a generic lifetime, instead of all the elements being bound by a single lifetime decided by the iterator. While a somewhat abstract-sounding feature, complex lifetime situations unfortunately happen all the time in FFI because, by definition, you have entities that can have "two owners" conceptually and are thus bound by two lifetimes. This tends to result in situations that, in current-day Rust, are often solved by simply brute-forcing something using unsafe code, instead of modeling the actual lifetimes involved. By holding back the version pinned for PL/Rust, this is causing upstream annoyance in PGX. I had hoped to be able to use these to handle some issues with generating the SQL entity graph introduced by the new approach which would allow removing various special cases. It also probably limits the soundness of improving allocations.
Same as 2, but more specifically with core::ffi::CStr. It allows removing dependencies (core_cstr), so it reduces the amount of code that anyone has to worry about in the supply chain, but by pinning to 1.61 we are losing that opportunity.
Same as 2, but more specifically with std::thread::scope. It allows removing a large dependency in the build system for pgx-pg-sys, the rayon dependency which brings in about a dozen other crates, so it significantly reduces the amount of code that anyone has to worry about in the supply chain, but by pinning to 1.61 we are losing that opportunity.
tcdi/plrust#118 will not actually be fully solved with anything less than rustc 1.63.0, as #[link_section] is not independently detected as unsafe until then, only #[no_mangle] but that is, again, still an unsupported version in security terms, so realistically, moving from an unsupported version to an unsupported version is not really acceptable.
Compile times have been raised as a concern, and by pinning we are passing on significant compile time improvements. If it takes 24 hours to compile a "hello world" in PL/Rust on a direly under-provisioned machine, then that's still from 43 minutes to 2 hours and 24 minutes in savings. And due to the issues like needing to build rayon, the savings may be larger.
It's just tedious to work on fixing things upstream for PGX and then have to go to PL/Rust and reinstall cargo pgx for the specific pinned rustc version. These pointless rebuilds slow down every single patch I might write for PL/Rust. It can easily consume an hour or more on pure faffing about when switching back and forth, partly assisted by sometimes forgetting and only hitting the secondary issues caused by not doing so, thus having to debug it, and only then remembering to rebuild and reinstall, etc. This is already a test suite that takes too long to run and debug, this makes it even more unconscionable.
It is very likely we are going to find another issue like tcdi/plrust#118, or want to try to actively find others that use similar ideas but don't rely on that specific attribute, that are not yet covered by rustc. That may warrant me or someone else studying the unsafe detection upstream in rustc and submitting patches for what we find, and that would only come to stable ~2 versions after it merges.
It makes it impossible to develop a process for smoothly upgrading postgrestd to new Rust versions if we are not actually allowed to upgrade to new Rust versions.
I can't even imagine what sorts of things we are giving up, honestly, by not having access to std::backtrace::Backtrace. It's intended to be a key component of newer, more sophisticated and better-scoped error-handling in Rust. Even if it's mostly going to be a diagnostic improvement, it's a lot to not have.
This last point is a stand-in for all the concerns that I have quietly sublimated instead of actively thinking about because this has been presented as a non-negotiable requirement.

It's becoming really hard to avoid using more recent features, because a lot of the work that has been done to make our pointer abstractions better has been entirely recent. And by "recent", I mean "it was stabilized 6 months ago". While working to make pgx::datum::Array<'a, T> safer, more correct, and eventually faster, I accidentally used a library feature stabilized in Rust 1.63, to which I say: lmao.

Per the tracking issue for #![feature(slice_ptr_len)], it's almost impossible to get the len of a pointer to a slice correctly without NonNull<[T]>::len().


Having issue with accessing directory inside a repository having same name as username

Gitea version (or commit ref): master 20/10/2019
Git version: git version 2.23.0.windows.1
Operating system: windows 10 18999 build
Database (use [x]):

[ ] PostgreSQL
[ ] MySQL
[ ] MSSQL
[x] SQLite

Can you reproduce the bug at https://try.gitea.io:

[x] Yes (provide example URL) https://try.gitea.io/hiteshnayak305/hiteshnayak305
[ ] No
[ ] Not relevant

Log gist: https://gist.github.com/hiteshnayak305/3421c3aa04cafb8a15e540a79936df61

Description
accessing folders inside repository with same name as user name gives error 500.
...
Screenshots

Migrating this to view logs suggest problem is unrelated to username but nil reference with new GPG code added recently:
2019/10/20 16:37:36 ...les/context/panic.go:35:1() [E] PANIC:: runtime error: invalid memory address or nil pointer dereference
        /usr/local/opt/go/libexec/src/runtime/panic.go:82 (0x40447d0)
                panicmem: panic(memoryError)
        /usr/local/opt/go/libexec/src/runtime/signal_unix.go:390 (0x40445ff)
                sigpanic: panicmem()
        /Users/mrsdizzie/.go/src/code.gitea.io/gitea/models/gpg_key.go:684 (0x4bb116c)
                ParseCommitWithSignature: log.Error("Error getting default public gpg key: %v", err)
        /Users/mrsdizzie/.go/src/code.gitea.io/gitea/routers/repo/view.go:184 (0x4f3225f)
                renderDirectory: ctx.Data["LatestCommitVerification"] = models.ParseCommitWithSignature(latestCommit)
        /Users/mrsdizzie/.go/src/code.gitea.io/gitea/routers/repo/view.go:455 (0x4f37882)
                renderCode: renderDirectory(ctx, treeLink)
        /Users/mrsdizzie/.go/src/code.gitea.io/gitea/routers/repo/view.go:395 (0x4f36d91)
                Home: renderCode(ctx)

OK, I think I understand what's happened here. The stack trace implies that L684 here is the cause - but actually it's wrong the cause is coming from L685
https://github.com/go-gitea/gitea/blob/c8f3146cd52887c0bdd815ad0bdeb954b242c8fc/models/gpg_key.go#L682-L685
The defaultGPGSettings is nil. But how can that be?
https://github.com/go-gitea/gitea/blob/c8f3146cd52887c0bdd815ad0bdeb954b242c8fc/modules/git/commit.go#L503-L508
c.repo must be nil so this code will return nil, nil.

Now c.repo being nil implies it is an unattached commit. It absolutely should be associated with a repository otherwise we cannot examine whether it was signed by the default key.
So there's another bug that this is revealing in:
https://github.com/go-gitea/gitea/blob/c8f3146cd52887c0bdd815ad0bdeb954b242c8fc/modules/git/commit_info.go#L15
In particular:
https://github.com/go-gitea/gitea/blob/c8f3146cd52887c0bdd815ad0bdeb954b242c8fc/modules/git/commit_info.go#L67-L76
Where at L74 the coerced commit doesn't gain a reference to the underlying repository
So that needs fixing and although L685 is responsible for the panic it was a good thing because we'd have great difficulty tracking down this bug without it!


Extension causes high cpu load

Issue Type: Performance
Extension Name: copilot-chat
Extension Version: 0.23.1
OS Version: Windows_NT x64 10.0.19045
VS Code version: 1.96.0

:warning: Make sure to attach this file from your home-directory:
:warning:file:///c%3A/Users/cb2s1q9/AppData/Local/Temp/GitHub.copilot-chat-unresponsive.cpuprofile.txt
Find more details here: https://github.com/microsoft/vscode/wiki/Explain-extension-causes-high-cpu-loadGitHub.copilot-chat-unresponsive.cpuprofile.txt

We just released a new version. Can you try with the latest version and tell us if performance has improved?

I also updated VSC and it seems to work so far, thanks.
Von: Bhavya U @.>
Gesendet: Mittwoch, 18. Dezember 2024 20:27
An: microsoft/vscode-copilot-release @.>
Cc: Schwitzing, Jochen @.>; Author @.>
Betreff: Re: [microsoft/vscode-copilot-release] Extension causes high cpu load (Issue #3221)
Sie erhalten nicht häufig E-Mails von<EMAIL_ADDRESS>Erfahren Sie, warum dies wichtig isthttps://aka.ms/LearnAboutSenderIdentification
We just released a new version. Can you try with the latest version and tell us if performance has improved?
—
Reply to this email directly, view it on GitHubhttps://github.com/microsoft/vscode-copilot-release/issues/3221#issuecomment-2552106287, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BIZXHRPKTNWI2INBAIOVOLD2GHEAZAVCNFSM6AAAAABTRR6SSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJSGEYDMMRYG4.
You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>


Make Cypress baseSearchURL more robust

New feature description
The baseSearchURL used by the cypress tests is stored separately from the react webapp.  So each time the react app changes something such as sorting parameters, the cypress tests will need to be updated.  Options:

Change cypress to import the baseSearchURL value form the react code
Change cypress to liberally use wildcard or * matching within the baseSearchURL
Change the server side API encapsulate its arguments.  For example, you would just pass the search term and no sorting options.  The server side would always return sorted.  Not sure if this is possible or desired.

Additional context
Issue identified by PR #164

Selected Option 2 because:

I'm not sure option 1 is possible
Option 3 is probably a fair amount of work.
Option 2 is easy


Fixed #4. Added PolyMath to the title of README

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Warning: This coverage report may be inaccurate.
We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
To ensure accuracy in future PRs, please see these guidelines.
A quick fix for this PR: rebase it; your next report should be accurate.

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.712%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
4109

Relevant Lines:
4432

💛  - Coveralls


Make streamer compatible with audit-argument-checks

Great job on this package!
Here's a small update to make streamer compatible with audit-arguments-checks.

Thanks @Pagebakers :)


Can we have the python environment you used for data processing?

Hello author
when I was processing data, I found that pytorch-lightning and clip-by-openai were not compatible. Can I have a look at the environment you used when processing data?

We create different environments for different tools. We are working on merging requirements together.


Pin piff to 1.3.3.

Checklist

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

Rerender?

@conda-forge-admin, please rerender


Webhook implementation

The webhook implementation is crucial for making our callback applicable in various scenarios by generalizing its usage for Kitodo.Presentation, Kitodo.Production and maybe other applications like an internal ticket system or something else.
The existing Kitodo.Production Active MQ implementation within the ocrd_lib.sh script should be replaced with the generalized webhook functionality for this purpose.
The Active MQ functionality should be extracted into a separate "kitodo_production_endpoint_script," which will only be utilized within the "for_production" script. The idea is to initiate an HTTP proxy, whose URL will be passed as the webhook receiver URL, and this proxy will forward the request to the Active MQ. Additionally, it would also be feasible to install the script on the Kitodo.Production system and make the endpoint accessible there.
Currently, the following webhook events are planned maybe with a prefix "ocrd_":

info
started
error (maybe or should be splitted to error_occured, error_resolved)
completed

Are there any more events here that should be taken into consideration?
What is missing or should it be further described?

Is this meant to solve #64? Why do you throw out ActiveMQ – I thought we would like to keep multiple options (maybe even in parallel)?

@bertsky I've modified the pull request description. If there are additional questions or concerns, let's address them in more detail through the discussion.
fyi I haven't added you as a reviewer yet, as the pull request is not at that stage yet.

Ok, the edited description still does not explain it explicitly, so I will try to say it in my own words – please CMIIW.
The reason for throwing out the ActiveMQ mechanism (replacing it with the more general REST interface which is easier to reuse) would be that we want to keep ocrd_lib.sh (ActiveMQ client) and the entry point script CLIs (no ACTIVEMQ / ACTIVEMQ_CLIENT / ACTIVEMQ_QUEUE runtime variables) simple.
However, to still be able to report back to Kitodo.Production, we not only then have to set up another service acting as a kind of proxy (translating the POSTed JSON data to the former ActiveMQ message). (That part is still missing from the PR.) We also have to keep the --process-id and --task-id interface, because we definitely need that information. (So this part must be optional for the callback interface itself.)
Regarding terminology, please use callback instead of webhook.

The reason for throwing out the ActiveMQ mechanism (replacing it with the more general REST interface which is easier to reuse) would be that we want to keep ocrd_lib.sh (ActiveMQ client) and the entry point script CLIs (no ACTIVEMQ / ACTIVEMQ_CLIENT / ACTIVEMQ_QUEUE runtime variables) simple.

We also want other applications to be able to use the webhooks to be informed about the status of the OCR processing. For example, Kitodo-Presentation and also keeping the functionalities from the ocrd_lib.sh as general as possible.

However, to still be able to report back to Kitodo.Production, we not only then have to set up another service acting as a kind of proxy (translating the POSTed JSON data to the former ActiveMQ message). (That part is still missing from the PR.) We also have to keep the --process-id and --task-id interface, because we definitely need that information. (So this part must be optional for the callback interface itself.)

The proxy could be provided within the scope of the repository Kitodo-Production ActiveMQ and wouldn't need to be versioned in the Manager. The proxy could be provided as a standalone script, which could then be easily installed into an existing Kitodo.Production instance. It's conceivable that it could also be installed here in the Dockerfile of Kitodo-Production ActiveMQ.
In the ocrd_lib.sh, the parameters are currently being returned to the receiver. Currently, the necessary parameters for process_mets.sh and process_images.sh are provided here, without distinguishing which ones are actually required. Therefore, I would like to implement a mechanism similar to parse_args as an abstract function, which allows setting the necessary parameters for the receiver in the respective script.

Regarding terminology, please use callback instead of webhook.

I find the term 'webhook' more suitable than 'callback' and would like to keep it that way.
https://www.svix.com/resources/faq/webhook-vs-callback/

@bertsky Changed the asynchronous behavior. Synchronous is now the default.


Remove DumpIT - seems the project is not maintained  anymore

@hslatman I heard that DumpIT is no longer maintained  , are you aware of this?

I was not aware of that, and I don't have any indication it is under continuous development or not. There's no open source version of it available, so I guess it's OK to remove it.


wrong urls

for dynamic urls. how are wrong urls handled? because wrong links seems to break the app. I tried this link htps://asd.com and its raising at io_client.dart and also osError: OSError (OS Error: connection refused, errno = 111). pls is there a bull to check if a url is valid or not?

Hey @Livingstone99
Thanks for using the package. I have added a new method AnyLinkPreview.isValidLink() in version 2.0.4 which allows one to verify whether the link is valid or not prior.
Hope this solves the issues.
Also for custom UI there's a new method that is added which gives the raw data AnyLinkPreview.getMetadata()
Feel free to re-open the issue if the new method doesn't satisfy your use case.
Cheers,
Suresh


Find gtdb files with pattern vs hardcoding exact names

Context: https://github.com/kbase/collections/pull/329#discussion_r1228747088
Instead of looking for an exact file name, use the pattern gtdbtk.*.summary.tsv to find the gtdbtk output files in the tool execution code and the parser. This future proofs us a bit

@Xiangs18 this is done isn't it?

Hi @MrCreosote, it is merged already!


Remove unneeded swaggo generated file.

Overview
Fixes #522. This file isn't needed, so it's fine to delete.
Description
Fixed additional documentation issues.

Codecov Report

Merging #524 (46b1033) into main (777620f) will decrease coverage by 0.13%.
The diff coverage is 19.04%.

@@            Coverage Diff             @@
##             main     #524      +/-   ##
==========================================
- Coverage   20.06%   19.94%   -0.13%
==========================================
  Files          49       49
  Lines        6150     6183      +33
==========================================
- Hits         1234     1233       -1
- Misses       4687     4720      +33
- Partials      229      230       +1

Impacted Files
Coverage Δ

pkg/server/router/credential.go
2.94% <ø> (ø)

pkg/server/router/did.go
3.57% <ø> (ø)

pkg/server/server.go
58.80% <19.04%> (-9.41%)
:arrow_down: