Rename fanoutprocessor to FanOutConnector

This implements https://github.com/open-telemetry/opentelemetry-service/issues/283

Codecov Report

Merging #285 into master will not change coverage.
The diff coverage is 90%.

@@           Coverage Diff           @@
##           master     #285   +/-   ##
=======================================
  Coverage   73.13%   73.13%
=======================================
  Files         111      111
  Lines        6446     6446
=======================================
  Hits         4714     4714
  Misses       1488     1488
  Partials      244      244

Impacted Files
Coverage Δ

processor/fanoutconnector.go
100% <100%> (ø)

service/builder/receivers_builder.go
83.63% <100%> (ø)
:arrow_up:

service/builder/pipelines_builder.go
92.72% <50%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

Please have another look.


[FLINK-17093][python][table-planner][table-planner-blink] Fix Python UDF to make it work with inputs from composite field

What is the purpose of the change
This pull request fixes Python UDF to make it work with inputs from composite field
Brief change log

*Add rule PythonCalcExpandProjectRule which expand the input fields which are from composite fields for Python UDF *

Verifying this change
This change added tests and can be verified as follows:

Added tests testPythonFunctionWithCompositeInputs and testChainingPythonFunctionWithCompositeInputs

Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (no)
The serializers: (no)
The runtime per-record code paths (performance sensitive): (no)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn/Mesos, ZooKeeper: (no)
The S3 file system connector: (no)

Documentation

Does this pull request introduce a new feature? (no)
If yes, how is the feature documented? (not applicable)

@dianfu  Thanks a lot for the fix. It looks good from my side.


Searches extended passive mode used for passive

What the program do ?
---- used for FTP
Searches extended passive mode used for passive
In what programming language it is written?

This pull request do not contains files in specific folders. Please fix it and reopen


[KYUUBI #2653] Init frontend framework

Why are the changes needed?

How was this patch tested?

[ ] Add some test cases that check the changes thoroughly including negative and positive cases if possible

[ ] Add screenshots for manual tests if appropriate

[ ] Run test locally before make a pull request

Codecov Report

Merging #2840 (4ba70b0) into master (ead33d7) will decrease coverage by 0.22%.
The diff coverage is 3.61%.

@@             Coverage Diff              @@
##             master    #2840      +/-   ##
============================================
- Coverage     63.37%   63.14%   -0.23%
- Complexity      203      205       +2
============================================
  Files           485      488       +3
  Lines         21731    21810      +79
  Branches       2864     2874      +10
============================================
+ Hits          13771    13773       +2
- Misses         6659     6736      +77
  Partials       1301     1301

Impacted Files
Coverage Δ

.../kyuubi/client/api/v1/dto/OverviewInformation.java
0.00% <0.00%> (ø)

...e/kyuubi/client/api/v1/dto/WebuiConfiguration.java
0.00% <0.00%> (ø)

.../apache/kyuubi/server/api/v1/ApiRootResource.scala
84.21% <0.00%> (-4.68%)
:arrow_down:

...rg/apache/kyuubi/server/api/v1/WebuiResource.scala
0.00% <0.00%> (ø)

...ache/kyuubi/server/KyuubiRestFrontendService.scala
86.15% <100.00%> (ø)

...scala/org/apache/kyuubi/server/ui/JettyUtils.scala
80.76% <100.00%> (-0.72%)
:arrow_down:

...n/scala/org/apache/kyuubi/engine/ProcBuilder.scala
85.00% <0.00%> (+0.62%)
:arrow_up:

...ache/kyuubi/spark/connector/tpch/TPCHCatalog.scala
57.14% <0.00%> (+2.38%)
:arrow_up:

...apache/kyuubi/spark/connector/tpch/TPCHTable.scala
52.00% <0.00%> (+4.00%)
:arrow_up:

Continue to review full report at Codecov.

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

kyuubi-server/src/main/resources/org/apache/kyuubi/ui/static/icon.min.css truncated not deleted?

Did you run:
npm run build

before generating the binary package?

The first-round review is about building and code style, and how can we handle the license for frontend components and dependencies?

@pan3793: Any ETA on this PR will get merged to master? Thanks.

Plan to get in master after cutting branch-1.6 because of the lack of frontend developers/reviewers.

@tongwl Are you interested in joining us to build the Kyuubi Web UI together?

@tongwl Are you interested in joining us to build the Kyuubi Web UI together?

Hi @yanghua, sure. My team is also using kyuubi, We are interested in in contributing to Kyuubi :)

@tongwl Are you interested in joining us to build the Kyuubi Web UI together?

Hi @yanghua, sure. My team is also using kyuubi, we are interested in in contributing to Kyuubi :)

Hi @tongwl, can you leave a comment at https://github.com/apache/incubator-kyuubi/discussions/925, so we can add you in our official website

Close and in favor #3250


Archive 2021 meeting notes

It's time to archive the meetings notes from 2021

@afrittoli , I will make sure to include the correct contents from vocab meetings.


libFirestack.a?

Where can I find libFirestack.a?
I'm following step 1 in the manual setup steps

Holla @marclundgren What do you mean? Did you call react-native link react-native-firestack?

@marclundgren Okay, I've got it... I forgot to list a step on the installation process for manually linking. I'll update the readme shortly, but for you:
Make sure you add the Firestack library in the Libraries list


adobe-reader install failure

~$ brew cask install adobe-reader
==> Satisfying dependencies
complete
==> Downloading http://ardownload.adobe.com/pub/adobe/reader/mac/AcrobatDC/1501620039/AcroRdrDC_1501620039_MUI.dmg
######################################################################## 100.0%
==> Verifying checksum for Cask adobe-reader
==> Running installer for adobe-reader; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
Password:
==> installer: Package name is Adobe Acrobat Reader DC (Continuous)
==> installer: Upgrading at base path /
==> installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
Error: Command failed to execute!

==> Failed command:
["/usr/bin/sudo", "-E", "--", "/usr/sbin/installer", "-pkg", "#<Pathname:/usr/local/Caskroom/adobe-reader/2015.016.20039/AcroRdrDC_1501620039_MUI.pkg>", "-target", "/"]

==> Output of failed command:
installer: Package name is Adobe Acrobat Reader DC (Continuous)
installer: Upgrading at base path /
installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)

==> Exit status of failed command:
#<Process::Status: pid 55655 exit 1>
~$ brew cask info adobe-reader
adobe-reader: 2015.016.20039
Adobe Acrobat Reader DC
https://www.adobe.com/products/reader.html
Not installed
https://github.com/caskroom/homebrew-cask/blob/master/Casks/adobe-reader.rb
==> Contents
  AcroRdrDC_1501620039_MUI.pkg (pkg)
~$ brew cask --version
0.60.0 (git revision f50d4; last commit 39 minutes ago)

Please always follow the reporting bugs guide. To do so, edit the top post and then comment after this one so I can check back.
Closing in the meantime, because a number of people never report back and it’s useless to keep the issue open in that case and without all the required information.
All that said, I cannot reproduce.

I am having the same problem:
(Remember to run brew update; brew cleanup; brew cask cleanup before reporting your issue. It usually fixes things!)
Description of issue
Failure of install adobe-reader after migration brew/cask from /opt to /usr/local
Output of brew cask <command> --verbose
# xiaolong at Xiaolongs-MacBook-Pro.local in ~ [1:44:49] tty:s001 L:2 N:2 C:1
$ brew cask install --force-upgrade adobe-reader --verbose
==> Satisfying dependencies
complete
==> Downloading http://ardownload.adobe.com/pub/adobe/reader/mac/AcrobatDC/1501620039/AcroRdrDC_1501620039_MUI.dmg
Already downloaded: /Users/xiaolong/Library/Caches/Homebrew/adobe-reader-2015.016.20039.dmg
==> Verifying checksum for Cask adobe-reader
==> Running installer for adobe-reader; your password may be necessary.
==> Package installers may write to any location; options such as --appdir are ignored.
==> installer: Package name is Adobe Acrobat Reader DC (Continuous)
==> installer: Upgrading at base path /
==> installer:PHASE:Preparing for installation…
==> installer:PHASE:Preparing the disk…
==> installer:PHASE:Preparing Adobe Acrobat Reader DC (Continuous)…
==> installer:PHASE:Waiting for other installations to complete…
==> installer:PHASE:Configuring the installation…
==> installer:STATUS:
==> installer:%27.923725
==> installer:PHASE:Writing files…
==> installer:%45.799802
==> installer:PHASE:Optimizing system for installed software…
==> installer:%55.603953
==> installer:PHASE:Running package scripts…
==> installer:%56.570065
==> installer:PHASE:Running package scripts…
==> installer:PHASE:Validating packages…
==> installer:%97.750000
==> installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)
Error: Command failed to execute!

==> Failed command:
["/usr/bin/sudo", "-E", "--", "/usr/sbin/installer", "-pkg", "#<Pathname:/usr/local/Caskroom/adobe-reader/2015.016.20039/AcroRdrDC_1501620039_MUI.pkg>", "-target", "/", "-verboseR"]

==> Output of failed command:
installer: Package name is Adobe Acrobat Reader DC (Continuous)
installer: Upgrading at base path /
installer:PHASE:Preparing for installation…
installer:PHASE:Preparing the disk…
installer:PHASE:Preparing Adobe Acrobat Reader DC (Continuous)…
installer:PHASE:Waiting for other installations to complete…
installer:PHASE:Configuring the installation…
installer:STATUS:
installer:%27.923725
installer:PHASE:Writing files…
installer:%45.799802
installer:PHASE:Optimizing system for installed software…
installer:%55.603953
installer:PHASE:Running package scripts…
installer:%56.570065
installer:PHASE:Running package scripts…
installer:PHASE:Validating packages…
installer:%97.750000
installer: The upgrade failed (The Installer encountered an error that caused the installation to fail. Contact the software manufacturer for assistance.)

==> Exit status of failed command:
#<Process::Status: pid 80474 exit 1>
Error: Kernel.exit

Output of brew doctor

$ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry and just ignore them. Thanks!

Warning: Putting non-prefixed findutils in your path can cause python builds to fail.

Warning: Unbrewed dylibs were found in /usr/local/lib.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected dylibs:
    /usr/local/lib/libcdt.5.dylib
    /usr/local/lib/libcgraph.6.dylib
    /usr/local/lib/libgvc.6.dylib
    /usr/local/lib/libgvpr.2.dylib
    /usr/local/lib/libpathplan.4.dylib
    /usr/local/lib/libxdot.4.dylib

Warning: Unbrewed header files were found in /usr/local/include.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.

Unexpected header files:
    /usr/local/include/graphviz/arith.h
    /usr/local/include/graphviz/cdt.h
    /usr/local/include/graphviz/cgraph.h
    /usr/local/include/graphviz/color.h
    /usr/local/include/graphviz/geom.h
    /usr/local/include/graphviz/graphviz_version.h
    /usr/local/include/graphviz/gvc.h
    /usr/local/include/graphviz/gvcext.h
    /usr/local/include/graphviz/gvcjob.h
    /usr/local/include/graphviz/gvcommon.h
    /usr/local/include/graphviz/gvconfig.h
    /usr/local/include/graphviz/gvplugin.h
    /usr/local/include/graphviz/gvplugin_device.h
    /usr/local/include/graphviz/gvplugin_layout.h
    /usr/local/include/graphviz/gvplugin_loadimage.h
    /usr/local/include/graphviz/gvplugin_render.h
    /usr/local/include/graphviz/gvplugin_textlayout.h
    /usr/local/include/graphviz/gvpr.h
    /usr/local/include/graphviz/pack.h
    /usr/local/include/graphviz/pathgeom.h
    /usr/local/include/graphviz/pathplan.h
    /usr/local/include/graphviz/textspan.h
    /usr/local/include/graphviz/types.h
    /usr/local/include/graphviz/usershape.h
    /usr/local/include/graphviz/xdot.h

Warning: Unbrewed .pc files were found in /usr/local/lib/pkgconfig.
If you didn't put them there on purpose they could cause problems when
building Homebrew formulae, and may need to be deleted.


/getting-started remove "Looking to get started with an earlier version?"

Remove this line in the beginning note 'Looking to get started with an earlier version?'

Completed with in-page [Edit]


Keep Query params when creating a Next paging operation

Context

Pageable operations are cloned to create a new OperationNext operation which contains the configuration to make the call to get the next page, generally using a nextLink

Problem:
When cloning the original operation we're clearing all the parameters and later on bringing back in only the HeaderParameters this is causing us to miss required QueryParameters such as api-version in this issue https://github.com/Azure/autorest.typescript/issues/770
Fix:
In addition to Header parameters also clone the Query parameters

Trying to see if I can trigger CI by closing/reopening the PR :)

OK, I'm going to merge this for now but I need to migrate the old CI over to our new DevOps org in the future.


Load codeparrot/apps raising UnicodeDecodeError in datasets-2.18.0

Describe the bug
This happens with datasets-2.18.0; I downgraded the version to 2.14.6 fixing this temporarily.
Traceback (most recent call last):
  File "/home/xxx/miniconda3/envs/py310/lib/python3.10/site-packages/datasets/load.py", line 2556, in load_dataset
    builder_instance = load_dataset_builder(
  File "/home/xxx/miniconda3/envs/py310/lib/python3.10/site-packages/datasets/load.py", line 2228, in load_dataset_builder
    dataset_module = dataset_module_factory(
  File "/home/xxx/miniconda3/envs/py310/lib/python3.10/site-packages/datasets/load.py", line 1879, in dataset_module_factory
    raise e1 from None
  File "/home/xxx/miniconda3/envs/py310/lib/python3.10/site-packages/datasets/load.py", line 1831, in dataset_module_factory
    can_load_config_from_parquet_export = "DEFAULT_CONFIG_NAME" not in f.read()
  File "/home/xxx/miniconda3/envs/py310/lib/python3.10/codecs.py", line 322, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

Steps to reproduce the bug

Using Python3.10/3.11
Install datasets-2.18.0
test with

from datasets import load_dataset
dataset = load_dataset("codeparrot/apps")

Expected behavior
Normally it should manage to download and load the dataset without such error.
Environment info
Ubuntu, Python3.10/3.11

The same error with mteb datasets.

Here is the requirements.txt from a clean virtual environment (managed by conda) where I only install datasets by
pip install datasets.
The pip list:
aiohttp==3.9.3
aiosignal==1.3.1
attrs==23.2.0
certifi==2024.2.2
charset-normalizer==3.3.2
datasets==2.18.0
dill==0.3.8
filelock==3.13.3
frozenlist==1.4.1
fsspec==2024.2.0
huggingface-hub==0.22.2
idna==3.6
multidict==6.0.5
multiprocess==0.70.16
numpy==1.26.4
packaging==24.0
pandas==2.2.1
pyarrow==15.0.2
pyarrow-hotfix==0.6
python-dateutil==2.9.0.post0
pytz==2024.1
PyYAML==6.0.1
requests==2.31.0
six==1.16.0
tqdm==4.66.2
typing_extensions==4.11.0
tzdata==2024.1
urllib3==2.2.1
xxhash==3.4.1
yarl==1.9.4

And the error can be reproduced.
Downgrading to datasets==2.14.6 changes some packages' versions:
Successfully installed datasets-2.14.6 dill-0.3.7 fsspec-2023.10.0 multiprocess-0.70.15

and the dataset can be downloaded and loaded.
Then I upgrade the version to 2.18.0 again; now the dataset can be loaded with such a line:
Using the latest cached version of the module from /home/xxx/.cache/huggingface/modules/datasets_modules/datasets/codeparrot--apps/04ac807715d07d6e5cc580f59cdc8213cd7dc4529d0bb819cca72c9f8e8c1aa5 (last modified on Sun Apr  7 09:06:43 2024) since it couldn't be found locally at codeparrot/apps, or remotely on the Hugging Face Hub.
So the latest version works wrong when requesting the dataset info.
But if you cannot reproduce this, I may ignore some detailed information: I use HF_ENDPOINT=https://hf-mirror.com for some reason (if not use this I cannot connect to huggingface resources) and the error occurs when requesting the dataset's info card.
Maybe the error is caused by this environment variable.
I'll open an issue in the author's repo now.

Here is the requirements.txt from a clean virtual environment (managed by conda) where I only install datasets by pip install datasets. The pip list:
aiohttp==3.9.3
aiosignal==1.3.1
attrs==23.2.0
certifi==2024.2.2
charset-normalizer==3.3.2
datasets==2.18.0
dill==0.3.8
filelock==3.13.3
frozenlist==1.4.1
fsspec==2024.2.0
huggingface-hub==0.22.2
idna==3.6
multidict==6.0.5
multiprocess==0.70.16
numpy==1.26.4
packaging==24.0
pandas==2.2.1
pyarrow==15.0.2
pyarrow-hotfix==0.6
python-dateutil==2.9.0.post0
pytz==2024.1
PyYAML==6.0.1
requests==2.31.0
six==1.16.0
tqdm==4.66.2
typing_extensions==4.11.0
tzdata==2024.1
urllib3==2.2.1
xxhash==3.4.1
yarl==1.9.4

And the error can be reproduced.
Downgrading to datasets==2.14.6 changes some packages' versions:
Successfully installed datasets-2.14.6 dill-0.3.7 fsspec-2023.10.0 multiprocess-0.70.15

and the dataset can be downloaded and loaded.
Then I upgrade the version to 2.18.0 again; now the dataset can be loaded with such a line: Using the latest cached version of the module from /home/xxx/.cache/huggingface/modules/datasets_modules/datasets/codeparrot--apps/04ac807715d07d6e5cc580f59cdc8213cd7dc4529d0bb819cca72c9f8e8c1aa5 (last modified on Sun Apr 7 09:06:43 2024) since it couldn't be found locally at codeparrot/apps, or remotely on the Hugging Face Hub.
So the latest version works wrong when requesting the dataset info.
But if you cannot reproduce this, I may ignore some detailed information: I use HF_ENDPOINT=https://hf-mirror.com for some reason (if not use this I cannot connect to huggingface resources) and the error occurs when requesting the dataset's info card. Maybe the error is caused by this environment variable. I'll open an issue in the author's repo now.

This is useful and my same error is settled!!!


OnLoad @ windows OS does not seem to run plugin

@angular/core 4.1.3
@angular/cli 1.0.3
OS Windows 10
Result: Nothing happens when loading project.
ExResult: Modal or evergreen message are shown.

Is this a Windows 10 specific issue or an angular cli 1.0 specific issue? I've testing on Windows 10 with CLI v8 that seemed to work

Still happens on windows 10. Will try updating a few versions of my cli.

fixed in #75


Power port to Power outlet connection

Environment

Python version:  3.6.8
NetBox version:  2.5.5

Hi. When I try the connection between a power port and a power outlet, netbox returns an error.
Steps to Reproduce

create a power port in a device
create a power outlet in a pdu
try to do a connection

Expected Behavior
Cable connection created.
Observed Behavior
If I didn't specify a length:
IntegrityError at /dcim/power-ports/59/connect/
null value in column "length_unit" violates not-null constraint
DETAIL:  Failing row contains (11, 2019-02-06, 2019-02-06 11:06:36.054882+00, 59, 1, 5000, t, , , null, null, null, 27, 25).
If I specify a length:
DataError at /dcim/power-ports/59/connect/
value too long for type character varying(2)

I'm not able to replicate this on v2.5.5. Looks related to #2616, which was raised during the v2.5 beta. Did you try upgrading from a beta to the current release? This would result in missing migrations.

I'm not able to replicate this either.


Feat: Dynamic Constraint Weight in constraint factory

Constraint Weight can be configured at runtime/dynamically using ConstraintWeightOverrides but it's a bit tedious to configure.
Could it be possible to configure them dynamically/lazily using the constraintFactory ? Example:
constraintFactory.forEach(MyValue::class.java)
   .join(ConstraintDefinition::class, // ...
   .penalize( { constraintDef, _ -> constraintDef.level } ) { constraintDef, value -> constraintDef.score(value) }

The approach you propose here is effectively turning a constraint weight into a match weight. A constraint weight is a configurable yet static number - a match weight depends on the specific impact you want the particular constraint match to make.
Since you already have a fully dynamic match weight, I really do not see the point of a dynamic constraint weight as well. Set your constraint weight to 1 (which is the default), and use match weight to penalize by an arbitrary amount - that is how the system is designed to function.
What do you intend to accomplish by making both the constraint and the match weights dynamic?

I see your point now, thanks for clarifying. Not the first time we're seeing such request.
The goal for ConstraintWeightOverrides is to allow this configuration to happen at solution-level - this makes sense, because if you need to override weights (especially if you want to change what's hard and what's soft), you're really solving two mutually incompatible problems.
Conceptually, allowing to do this on the match level IMO doesn't make sense - I don't see which single constraint can be both hard and soft, based on what it matched. Would overtime hours suddenly be less serious, because it's Bob and not Ann? Can Ed be in two places at once, but nobody else can? Would fuel costs suddenly break the solution, if the driver is Peter and not Paul?
Instead, this requirement seems to me like a side effect of some other problem you're attempting to solve. Perhaps having two constraints would bring performance costs, and therefore you're trying to get it done with just one constraint?

Here is an example:
I have a planning with configurable tasks.
I have a task limit rule (constraint). Sometime a task is mandatory (hard) sometime it is not (soft). But in both cases they are a limit constraint.
The user create the tasks and choose what tasks are mandatory (hard or soft level) and the weight of the constraint.
I could probably use the constraint override but I don't like to have to use "constraint name" to associate a dynamic weight to a constraint.
Especially when the name of the constraint itself is dynamic. ( .asConstraint("Task Limit TASK_ID=XYZ")).
I think it would be easier to just set the weight from the constraintFactory by keeping the weight in some planningvalue.
Yes having two constraints could be a solution, but they would be the same, they would have the same flow (forEach/join/map/groupBy/penalize etc.) the only difference is one penalizing hard and the other is penalizing soft.

Thanks for the explanation.
I would indeed go with two constraints here. A constraint called "Mandatory tasks must be assigned" is different in my mind to a constraint called "Reward optional task assignments" - even though their implementation may be virtually the same.
Consider score analysis, another feature of the solver - if you see matches from the same constraint being hard once, and soft another time, you have to start drilling down into justifications to figure out what exactly happened. Having two constraints for this saves you from that work, it makes score analysis self-explanatory.
The fact that two constraints take more performance is often not really a problem, because many constraints are cheap. For expensive constraints, the Enterprise Edition of Timefold Solver has a "node sharing" feature which can (under the hood) merge those executions is they are indeed the same.


Have a fix name in Polkadot telemetry for the current validator

Solved!

Cool. Thanks. I will update telemetry alerting and build a new Release of archipel dappnode package also


[BUG] Missing Proxima Nova and Jost font in 1.1.0

Describe the bug
Now repository doesn't contain Proxima Nova and Jost font.
Expected behavior
Contain Jost and Proxima Nova
Screenshots

Same problem here

Were these fonts present? I downloaded 1.0.0 and no "Josh" or "Proxima Nova" font is showed.

Were these fonts present? I downloaded 1.0.0 and no "Josh" or "Proxima Nova" font is showed.

Hi @JSBmanD, Proxima Nova is not a Google Font and Jost is currently available

Therefore I'm closing this issue. Please reopen it if this still occurs, with a small code sample so that I can reproduce the issue.


Update Privacy Guidelines -- new introduction proposed

Proposed:  a new document introduction, intended for readers without close knowledge of the Open Voice Network.

I have completed review and approve of the new proposed introduction.  It provides context for the "why" of the document.


Add CLI for configuring inventory files

See the Osmosis installer for inspiration:
https://github.com/osmosis-labs/osmosis-installer

MVP:
A wizard will collect the following info:

Gaia version
Start a testnet or join a testnet?

Start: set up a validator- ask about a faucet
Join: ask for genesis, and peers

Ask about state sync: request RPC servers

Host address


PMB-21: Limit addition for users

Problem:

Someone can spam a lot of cringey songs to the playlist

Solution:

Limit amount of songs added to, like, 3 songs

Changes:

Api
Server

Also, need to update bot help message, since it does not say anything about skipping songs and new functionality.


Additional cert env automated

I've noticed users customizing Dockerfiles to add the following. Are any of these appropriate or necessary to add, or should they be unnecessary because we run update-ca-certificates? I have seen one user export these even after running update-ca-certificates.

SSL_CERT_FILE
PIP_CERT and PIP_CLIENT_CERT (Pip/Poetry/etc)
BUNDLE_SSL_CA_CERT (Bundler)

they should follow https://github.com/containerbase/buildpack/blob/main/docs/custom-root-ca.md
So either use update-ca-certificates or defined env vars

Are those variables not needed if certs are added at build time?

yes, they should be removed, but probably don't harm 😉


:bug: analyze command should not run analysis when --help option is set

closes: #305

@Parthiba-Hazra thank you!


Download CSV name dataset name

Relates to:
CSV Download
Context
Is your feature request related to a problem? Please describe.
When a user downloads a csv from the application the export is named something like "Export, Dataset Entries, 2024-03-29".  If the user downloaded a different dataset it would have a similiar name.  Potentially be confusing when they download a lot and go to use it.
Describe the solution you'd like
Can the download be renamed Dataset name - date or something more descriptive  eg. Buildings-2024-03-29.

I went with the format
{data type}, {dataset name}, {ISO short date}
e.g.

Export, Employee Directory, 2024-04-02.csv


Consider EasyCLA acceptance for private accounts

Summary
Currently EasyCLA fetches the user details from Github, where the GitHub account needs to be in some form public. Please consider adding private details from the contributor EasyCLA approval, especially for CCLA.
For example in CCLA approval criteria the email address is not specific to the GitHub account it just says, email address, which could apply for private accounts.

@jarias-lfx kindly expound on this. For private emails we cant fetch the details from the repository provider
cc @mlehotskylf

@nickmango If this can't be implemented as requested I would suggest to close this as "Won't do".

Closing.


Decrease MAX_RESTART_WINDOW from 3600 to 10

The MAX_RESTART_WINDOW is used in the configuration of the supervision
tree. In the previous configuration 10 restarts in an hour would
results in the application failing. This was out of line wiht our
other supervision tree configurations which typically set the max
restart window to 10 seconds.

cc @chef/lob
This change is debatable.  I think that the newer bear and folsom in oc_erchef should resolve the crashes we were seeing that led us to hit the max; but since this was still so far out of line with the supervision configurations we have in oc_erche:
https://github.com/chef/oc_erchef/blob/master/apps/oc_chef_wm/src/oc_chef_wm_sup.erl#L80
I figured it was worth considering.

@chef/erlangers Was going through old PRs, this one still looks pretty reasonable to me.

+1

Miss you guys! But why did I get this alert?

@joedevivo You must still be in our chef/erlangers group, I'll take you out.  Also, we definitely miss you as well. Hope you are doing great!

@joedevivo you never call or write. I still have your Def Leppard/Winger mix tape and a cardigan that you left here.

@metadave I do actually still have your ChefConf badge :D


Function pointer

Not ready for review

This change is

I will wait until you say its ready for review :smile:

Review status: 0 of 14 files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Ready for review

Not ready in according to travis

Partly #85

Ready for review

If you want, then I can try to separate to small PRs.

This is a such a big and great feature it will be the v0.19.0 Uranium release 👍

Reviewed 11 of 16 files at r1, 6 of 7 files at r2, 3 of 4 files at r3, 1 of 1 files at r4.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable


add timer to header of locust

Better not restart the count when it stopped, but just pause the timer. In the other hand you should restart the timer when it start a new test or ramp

check lagi boleh @erlanggakrisnamukti @Amadeea

gas


OptimizeOptimize function call for const columns.

Proposed changes
Since there are many function tasks under construction, it's necessary to standardize the behavior of convert a column may be const to a concrete column.
The basic method to replace previous usgae convert_to_full_column_if_const is like:
ColumnPtr argument_columns[2];
bool col_const[2];
for (int i = 0; i < 2; ++i) {
    std::tie(argument_columns[i], col_const[i]) =
            unpack_if_const(block.get_by_position(arguments[i]).column);
    check_set_nullable(argument_columns[i], null_map); // set null map if you need.
}

Then, specialize the function like vector_scalar to distinguish the implementation by col_const.
Problem summary
Made specialization for some function calls for its' some columns' ColumnConst. Avoid expanding those columns.
Performance Improvement
The test result will be updated soonly.
Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[x] Is this PR support rollback (If NO, please explain WHY)

Further comments
There are still some pervious usage haven't update.

run buildall

run buildall


snap investigate error where transaction from address is different from address of the sending wallet

This task was fixed in this PR https://github.com/celo-org/gas-snap/pull/33


Browser connection tests

\cc @AlexanderMoskovkin @churkin
@VasilyStrelyaev please check the spelling in strings
Warning: I've temporary added node_modules/hammerhead for the testing purposes. So, review just the first commit. Second contains huge diff with the hammerhead's code and deps

@inikulin The Travis CI build failed

FPR

LGTM

LGTM

Test names:
Should fire "ready" event once established and redirect to idle page -> Should fire "ready" event and redirect to idle page once established
Should respond with error on queries if not ready -> Should respond to queries with error if not ready

/r-

FPR

LGTM

Thanks


[TypeScript] Bracket pair colorization fails when wraping type parameters

Does this issue occur when all extensions are disabled?: Yes (using extension bisect)

Version: 1.82.2
Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d
Date: 2023-09-14T05:51:20.981Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: <IP_ADDRESS>-electron.0
OS: Linux x64 6.4.12-1-default
Bracket pair colorization works fine if type parameters stay on the same line:

But fails if we wrap the type parameters:

A good minimal code snippet for this (from the comment under another issue):
export const mapResponse = {
  blogPost: <I extends {
    created: string;
    updated: string;
  }>(input: I) => {
    return {
      ...input,
      created: DateTime.fromISO(input.created),
      updated: DateTime.fromISO(input.updated)
    };
  }
};

This is a known issue (search for existing issues).

@hediet Sorry I did search but couldn't find a related one. Is this not going to be fixed as closed as "not planned"?


add basic auth support for elasticsearch

In GitLab by @luotian-github on Dec 7, 2018, 08:59
create a new nginx container, this nginx container with basic auth and proxy the incoming request to elasticsearch. because the kibana container using the inter container communications so there is no necessary to add basic auth to kibana. the kubernetes fluentd config need to add the basic auth. the auth config looks like: output.conf: |-
Enriches records with Kubernetes metadata
<filter kubernetes.**>
type kubernetes_metadata

<match **>
type elasticsearch
user admin
password 12345
log_level info
include_tag_key true
host <IP_ADDRESS>
port 9200
logstash_format true
Set the chunk limits.
buffer_chunk_limit 2M
buffer_queue_limit 8
flush_interval 5s
Never wait longer than 5 minutes between retries.
max_retry_wait 30
Disable the limit on the number of retries (retry forever).
disable_retry_limit
Use multiple threads for processing.
num_threads 2

In GitLab by @sokril on Nov 8, 2019, 08:29
assigned to @tmon546596046

In GitLab by @sokril on Dec 26, 2019, 06:52
changed the description

In GitLab by @luotian-github on Jun 24, 2020, 03:17
assigned to @luotian-github and unassigned @tmon546596046

In GitLab by @luotian-github on Jun 24, 2020, 03:17
suported in 7.3

In GitLab by @luotian-github on Jul 2, 2020, 09:18
verified fixed

In GitLab by @luotian-github on Jul 2, 2020, 09:18
closed


runtime: simplify account saver filter

Problem
negation inside a bracketed OR makes the filter predicate used to select what accounts need to be saved unusually difficult to understand for what is essentially one line of code
Summary of Changes
rewrite in a more straightforward imperative style. the logic itself is unchanged

honestly i thought it was a me problem for a bit that i needed to write out in words what this did every time i read it, but then i remembered a conversation a couple weeks ago where myself and the other person discussed this function for several minutes only to realize we both had it backwards


Feature: Slack unfurling

With Slack unfurling support, Slack users could preview contents without clicking the link and could continue conversations.
https://api.slack.com/reference/messaging/link-unfurling
And support for authenticated unfurling would be great for private GROWI deployments.
https://api.slack.com/reference/messaging/link-unfurling#authenticated_unfurls

FYI: This feature is available with crowi.
https://github.com/crowi/crowi/pull/204

+1


In nightly, Option menu is covered on Abilities screen

Hi, this may be related to #218 but seeing the following when trying to use Options menu on the nightly:

Huh... Have refreshed page and am now unable to recreate that - even at various ctrl-zoom levels in the browser.

AAH! Recreated:  Only happens on Abilities screen

oh no :(

Thanks for the fix :)


Consistency Control Headers

Describe the feature
Hi,
Is there a plan to add support to send consistency control headers as part of S3 Put operations?
I need to be able to send the following consistency control header values - all, strong-global, strong-sit, read-after-new-write, available.
Thank you
Use Case
Some metadata headers are unavailable to be set using the S3 CPP SDK.
Using the AddMetadata adds a "x-amz-meta" prefix, which doesn't solve this issue.
Proposed Solution
No response
Other Information
No response
Acknowledgements

[ ] I may be able to implement this feature request
[ ] This feature might incur a breaking change

Hi Adhitya,
AWS S3 is strong read-after-write consistent:
https://aws.amazon.com/about-aws/whats-new/2020/12/amazon-s3-now-delivers-strong-read-after-write-consistency-automatically-for-all-applications/
https://aws.amazon.com/s3/consistency/
I suggest to inquiry S3 customer support if you would like to check for a different or additional consistency control.
If you want to send a custom header with a request, you should be able to overwrite virtual function of a base request class, i.e. GetRequestSpecificHeaders or GetRequestSpecificHeaders(for non-streaming requests), to be more specific:

Inherit from a request class, for example PutObjectRequest
Implement/override a GetRequestSpecificHeaders function that will return additional headers you want.
Pass your an object of your inherited request class to the regular SDK's operation API, a slicing will happen, but thanks to the virtual inheritance, your overwritten method will be still called and custom headers inserted into the request.

Best regards


required_recipe endpoint is missing

From the release notes:
Added the ability to serve a required recipe file to chef-clients.
The setting required_recipe["enable"] in chef-server.rb enables the required recipe feature.
The setting required_recipe["path"] in chef-server.rb specifies the recipe file to serve.
The /organizations//required_recipe endpoint returns 404 for all organizations by default. It returns 401 when the request is not made by a client from the requested org and the feature is enabled.
The /organizations//required_recipe endpoint returns the required recipe and 200 only when the endpoint is enabled and requested by an authorized client.
See Chef RFC 89 for a complete description on the required_recipe endpoint.

Added by #192


enum's with negative values seem unusable

Attempting an enum definition like this
enum SUBTYPE:int {
XREF          = -12,
BIN_ARRAY     = -11,
REGION        = -10,
}
leads to  error messages like this
rpmtag_json_parser.h: In function ‘_RPM_SUBTYPE_parse_json_enum’:
rpmtag_json_parser.h:196:30: error: integer constant is so large that it is unsigned [-Werror]
*value =<PHONE_NUMBER>3709551605, *value_sign = 1;
^~~~~~~~~~~~~~~~~~~~

This is a large issue.
I will submit a quick fix that solves the above issue on the constants, but it also affects default value assignment in the reader and possible other places. Enum definitions in the reader are already handled, but I'm not sure it is done right since using UL, ULL suffixes are not fully portable.
Ideally *value =<PHONE_NUMBER>3709551605, *value_sign = 1; should be *value = UINT64_C(18446744073709551605), *value_sign = 1;
but then it must be ensured <inttypes.h> is handled correctly with and without fallback to "flatcc/portable/pstdint.h".
There are also issues with very large vectors in the builder with the size_t type for byte vectors longer than 2^31 bytes on 32-bit platforms, and 2^15 bytes on 16-bit platforms, but we also don't want to plaster every constant with a fat type qualifier.
Similar issues have been fixed earlier, I believe, but clearly not capturing all cases.

Please let me know if this solves the immediate issue at hand.
I think the other cases are less likely to cause problems and it is better to spend some time thinking about how to best handle it.
In some cases it may be better to do nothing since bloating a lot of files with unlike needed type qualifiers doesn't help much (e.g. size_t size arguments in the builder interface). It can be fixed later if really needed.
However, I still believe default values such as 2^32-1 for ulong fields could cause problems in realistic cases.

WORKSFORME. Thank you for the incredibly quick repair!

The last commit wraps default values and enums in UINT32_C(42) type values. No reported issues, but there is a risk of compiler errors or warnings for large user supplied values.
There are no such wrappers for size_t types in the builder for string or vector lengths but it is unlikely to have a vector have the addressable memory range on any system.


Update README for mTLS installation steps

Signed-off-by: Chen Xintong<EMAIL_ADDRESS>

see comments inline.

Thanks, done.


SDK API Reference should be more clear about optional params and defaults

For example, the SDK xcall documentation references optional params, but gives no information about them:
https://docs.connext.network/developers/reference/SDK/sdk-base#xcall

Chore: Annotate all types and funcitons to regenerate docs

We can potentially use https://github.com/SoftwareBrothers/better-docs for autogenerating better docs.


[REQUEST] Add a weight setting

Is your feature request related to a problem? Please describe.
Not really a problem but i think it would be interesting for the bag to not completly negate the weight of items for more challenge
Describe the solution you'd like
A setting that allow items to still cause weight increase while inside the bag (or maybe making it so items inside only weight half the normal, that kind of customization)

the game does not allow for dynamic weights, and item can only have one weight and that weight cannot change during a play session.


[AutoPR consumption/resource-manager] Adding new properties to Consumption Usage Details

Created to sync https://github.com/Azure/azure-rest-api-specs/pull/3357

This PR has been merged into https://github.com/Azure/azure-sdk-for-go/pull/2226


Investigate Code generate animation (e.g. gif)

https://www.kaggle.com/code/banerz/linear-classifier-from-scratch-with-animation
https://www.kaggle.com/code/banerz/visualize-the-decision-boundary-of-a-neural-net
https://github.com/open-academy/machine-learning/blob/main/open-machine-learning-jupyter-book/slides/ml-advanced/kernel-method.ipynb


Change logInfo to logWarning

Signed-off-by: remzi<EMAIL_ADDRESS>close #3959
This PR is to keep in sync with apache/spark@2fc9c0b (change logInfo to logWarning)

build

build

build

build

build


refactor(api): add dispense to PAPI engine core

Overview
Part of RCORE-135
Adds dispense command to PAPI protocol engine core.
Changelog

Implemented InstrumentCore.dispense to a given well
Refactored existing dispense so pipette movement happens inside the core
Added a get_absolute_dispense_flow_rate for calculating absolute flow rate, which is used in the ProtocolEngine

Review requests

Test dispense command both on the ProtocolEngine as well as the legacy command for regressions.
Did I miss any tests?
does the logic moved to the cores makes sense?

Risk assessment
Medium. Changes the way dispense works via PAPI with the ff on and off. need to smoke test properly.

Tested on an OT3! works as expected!


Add back statsig SDK to docs

Summary
When reverting the web experiments SDK, I overlooked the fact that the current sdk implementation was was in the static js folder.  This file is loaded and cached in the browser, and when the file is changed, the file name is still static and will not bust the browser cache.
The proposed solution here is to use the docusaurus plugin framework for our sdk integration (side note - we can make this into a docusaurus plugin and publish it on npm if we want).  This implementation is not loaded and cached in the browser, but rather built into the js bundle for the website.
Next, we should probably give koala the same treatment - that implementation hasnt changed (yet), but could cause a similar issue as currently implemented.
Test plan
Note that I could not verify the browser caching issue because it does not reproduce locally, nor via the netlify deployments (the url changes for each deployment)
Tested pageview logging on a local build:

Inspect the head for the statsig script and did not find it there, nor in the browser static resources files, so we should no longer have a caching issue when updating:

Worth having employees verify as we roll this out.

🚀 Deployed on https://64b9945286e4fc3848179331--cozy-fox-0defec.netlify.app


Support for Spark Packages

Spark 1.3/1.4's spark-submit tool now accepts a --packages argument.  The value is treated as a Maven coordinate, automatically downloading the corresponding JAR and it dependencies to the classpath.
The tool uses a few repositories out-of-box , including local-maven-cache, local-ivy-cache, Maven Central, and a repository associated with spark-packages.org.   Users may also specify custom repositories.
My suggestion is that packages be supported in notebook metadata to be employed as appropriate on both the driver and executor classpath.   Ideally packages would be first-class in the notebook template UI.
The essential code is here: spark/core/src/main/scala/org/apache/spark/deploy/SparkSubmit.scala::resolveMavenCoordinates

@EronWright how is that different from the current :dp support?

@EronWright thanks for the reference, very interesting I must say!
Also, @maasg is right, you can use

:dp to ask for libraries to be included in the
the notebook classpath
the spark.jars property (which will ship them to workers)
remote-repo to add more ivy or maven repos (including s3 ones, which spark-submit cannot do)
local-repo to tell where you want your ivy repo to land → I generally point it to my ~/.ivy2 but you could also set A different one per notebook (to split the downloads or whatever)

All these contexts are also available in the notebook metadata (see here):

customDeps
customRepos
customLocalRepo

Would those thiniges fill your needs or do you have something else in mind?

@andypetrella  awesome - seems the delta is very small.   At a high-level the goal is to claim support for Spark Packages.  The only apparent gap is inclusion of the Spark Packages repository in the default resolvers.   Then update the docs.
Some extra info:
Website
Announcing Spark Packages
Publishing Instructions
Sample

I think it is a good feature, because putting everything to assembly.jar is not pleasant.

@antonkulaga you're right and that's exactly the purpose of :dp, hence you don't have to create an assembly :-D
Here we are injecting the spark-packages maven repo by default in the list of repos, which makes a LOT of sense


Update THIRD_PARTY.md

winget.Pro is now (and has been, for a while) open source.

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.5 schema?

Thanks for Contributing


mark_as_unread

Currently, it appears that forwarding emails using the library marks the forwarded message as "read."  Is there a way to prevent this behavior, or alternatively, mark the message as unread like we can use mark_as_read right now?

I don't get it.
If you forward a message and send it, the recipients receive it as unread.

The tool is being used on a shared mailbox-- I want to be able to forward
it (with additional information that I have) to my personal mailbox, and
leave the original untouched so that they don't think that the email is
"processed" and can respond to their own customer requests.
On Fri, Nov 9, 2018 at 10:37 AM Alejandro Casanovas <
<EMAIL_ADDRESS>wrote:

I don't get it.
If you forward a message and send it, the recipients receive it as unread.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/janscas/pyo365/issues/16#issuecomment-437417093, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACLP_o34XI2MBO7SqSts4r4Ssn36Oo_Xks5uta8ugaJpZM4YW2Cz
.

--
Very respectfully,
Jesse L. Pink
<EMAIL_ADDRESS>(567) 274-6520

Then simply mark the message you forward as uneas after the forward.

Do I do that to the forwarded_message or the message that was forwarded?
That's why I was asking for a .mark_as_unread() function in the first place
On Fri, Nov 9, 2018, 12:42 PM Alejandro Casanovas<EMAIL_ADDRESS>wrote:

Then simply mark the message you forward as uneas after the forward.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/janscas/pyo365/issues/16#issuecomment-437455540, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACLP_kphmaRJjzq_wy7xRPjTYWxI_1RIks5utcyBgaJpZM4YW2Cz
.

Do it in the message you say it's being marked as read.


Fixes #6891 by implementing support for VARIANT  DType

Describe your changes :
Fixes #6891  by implementing support for VARIANT  DType. We also fixes a bug with the testSuite workflow where we processed all testCases for each table entity (we now filter only the testCases relevant for the entity). We also fixed some elements of the local docker to easily run only specific ingestion dependencies.

Type of change :

[x] Bug fix
[x] Improvement
[ ] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation

Frontend Preview (Screenshots) :
For frontend related change, please link screenshots of your changes preview! Optional for backend related changes.

Checklist:

[x] I have read the CONTRIBUTING document.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] All new and existing tests passed.

Reviewers
Ingestion: @open-metadata/ingestion

leaving it approved as it fixes the errors. One question i would have would be if instead of adding a new type which might only be part of Snowflake, we could keep the JSON mapping and just convert it as we are doing in the ORM to Variant at runtime 🤔 But well, let's open an issue and see how we can improve it later


Tilt syncing on Kind cluster produces an error and resorts to Docker image rebuild

Using KIND (http://kind.sigs.k8s.io) and Docker v18.09-ce on Ubuntu Cosmic.
Tilt file:
k8s_yaml(helm('helm'))

# web
docker_build(
    'docker.io/flyboy/web',
    '.',
    dockerfile='Dockerfile.web',
    live_update=[
        sync('.', '/usr/app')
    ]
)

k8s_resource('flyboy-web', port_forwards=9000)

Dockerfile for web app:
FROM node:10-alpine
ARG NODE_ENV=production
WORKDIR /usr/app
COPY package.json .
COPY package-lock.json .
RUN npm ci
COPY . .
CMD npm run serve

Modifying a file produces:
updating 1 files [/home/matthiasak/Code/flyboy-web/src/main.ts]
tar: lseek: Invalid seek
got unexpected error during build/deploy: command terminated with exit code 1
STEP 1/3 — Building Dockerfile: [docker.io/flyboy/web]

Thanks for the report! Let me try to repro this...

Awesome, thanks @nicks. For the record, even though I'm using Docker CE, these days they are using containerd under the hood. Could that be the issue?

ok, i've got a repro case! I think it might be a KIND bug.

:+1: thanks for digging in - can you help me report to KIND?

don't worry! We're on it. It might also be a Tilt bug!
The protocol for copying things to a kubernetes cluster is not well-specified, and figuring out who is doing the wrong thing can be tricky.

Repro steps so far (for other Tilt engineers)

Check out https://github.com/windmilleng/tilt-frontend-demo
Change the FROM image to alpine
Run tilt up --update-mode=exec
Edit src/App.js

This shows up on kind because kind implicitly turns on --update-mode=exec, but I was able to reproduce the problem with other clusters.

Hey @matthiasak I spent some time looking in to this this morning. I think this problem is due to an incompatibility between the way Tilt is creating the tar archive and the way that busybox tar, which ships with Alpine and is not GNU or BSD tar, reads the tar archive. I'm not sure exactly what that incompatibility is yet.
You should be able to work around this by adding a RUN apk add tar to your Dockerfiles that you use with Tilt. This installs GNU tar. Let me know if that doesn't work for you!
In the meantime we're going to try to dig in to what exactly the incompatibility is between our code and busybox tar.

This article covers some of the differences between busybox and other tar implementations. Might be a good jumping off point.

@jazzdan someday, somehow I'm buying you a beer :beers:

Should I close this issue @jazzdan / @nicks?

Let's leave it open. I suspect that there's a small fix we can do to make the tarball compatible with busybox. (kubectl cp also uses tar to copy things, and the tarball it creates seems to work ok)


Run in the Gazebo and real panda?

Hey,
Thanks for your nice project! I wanna try my own low level controller(cartesian impedance controller and so on) in c++ as the controller plugin just like u have done in this project, but for gazebo simulation. This kind of try can let me familiarize with franka robot. I read the doc Franka Control Interface. The reason for opening this issue is that the used interfaces in Franka Gazebo(Franka_HwSim) and real Franka(Franka_Hw) are not the same. Did you run the simulation on the gazebo? Did you run the controller on the real panda? If i want to run my controller on the real panda, should i also change my code for the real panda because of the Interface(Franka_Hw), even though i can run the controller for simulation？I found that you don't use the Franka_Hw in your controller. It's not the same way as the ones I've seen. I am very confused about the kind of issues right now. I'm looking forward to some of the experiences you can share. Thanks a lot for your time! !

The reason for opening this issue is that the used interfaces in Franka Gazebo(Franka_HwSim) and real Franka(Franka_Hw) are not the same. Did you run the simulation on the gazebo? Did you run the controller on the real panda?

We run the Panda with this package both in Gazebo as well as in my RL software stack SkiREIL directly with DART. We also ran it on the real Panda for some projects.

If i want to run my controller on the real panda, should i also change my code for the real panda because of the Interface(Franka_Hw), even though i can run the controller for simulation

We used the standard interfaces. I would need to look up which ones directly. In none of these cases we needed to change any code. However, this project only needs the information that is exposed with the normal ros_control interface.
One thing you can do is to set up ìiwa_ros with this controller project. iiwa_ros does not use any special interfaces and it would probably be easier to based on that setup.

I assume this is resolved. If there are other specific question, feel free to reopen.


Where to get latest gcpp/ccs binaries?

I do not like to use bioconda.
I hope to download these binaries manually.

We do not provide direct download link for legal reasons.


1.0.19

This PR
Upgrades the design system to version 1.0.19.
Specifically:

Regenerate build files (no changes due to builds in previous PRs)
Update changelog and package version

This might need to be updated with the latest changes

@jedgar1mx I'll add them in at 2:30p after some meetings

@jedgar1mx should be good to go now.


No warning on conflicting definitions

On mips, the st_rdev and st_dev fields of struct stat are of type long unsigned int rather than dev_t for $REASONS. The posix/stat.pxd file shipped with Cython correctly defines them as dev_t. To get my source code to compile under mips, I therefore thought I'd just teach Cython about this peculiarity:
from posix.stat cimport *
cdef extern from "<sys/stat.h>" nogil:
    cdef struct struct_mstat "stat":
        int   st_dev
        ino_t   st_ino
        mode_t  st_mode
        nlink_t st_nlink
        uid_t   st_uid
        gid_t   st_gid
        int st_rdev
        off_t   st_size
        blksize_t st_blksize
        blkcnt_t st_blocks
        time_t  st_atime
        time_t  st_mtime
        time_t  st_ctime

However, this did not have any effect at all. On further investigation, renaming eg st_ino to st_ino_fo did not result in any warnings either.
It seems to me that Cython silently uses its own definition of struct stat, and ignores everything that attempts to re-define it. I would have expected that a more local declaration takes predecence. But even more important, I think Cython should at least warn if it encounters such a conflicting definition.

It is a warning, though not a very verbose one. https://github.com/cython/cython/blob/53a3e9a2e88ed5045eec52885e9fad6d69aa787e/Cython/Compiler/Symtab.py#L452 I'd be very much in favor of making this louder, possibly eventually an error. The issue is some projects rely on being able to re-declare things (e.g. they use pxi files that have definitions that get included multiple times).


Would be good to log tracebacks

When trying to add a new data source, I get this alert dialog:

Which is almost useful but not quite.  It'd be great if the full traceback was at least logged in the web console.

Yeah the python stacktrace in the javascript popup isn't great...

Seems like it should be pretty easy to at least log the full trace in the console, I can add that soon.

We're at a much better place now in terms in error message handling. Closing.


Added documentation for includeEmptyDirectories option to README

Added documentation for includeEmptyDirectories option to README
Checklist

[x] Run npm run test
[x] Run npm run lint

@iNerdStack
Ah, I forgot about the documentation! Thank you for taking care of this.
I'll merge it right away!


Update and clarify sort and sortable key

Expand on the sort parameter definition and add the mentioning of the field sortable to the definition of what can be in /info/<entries> properties' dictionaries.
The most major thing here (in my opinion) is the clarification that if sorting is possible for an entry endpoint, the sortable key MUST be present for all fields under data.properties.<field> at /info/<entries> and can be either true or false.
Mainly this is because I am unsure how to sort on lists/arrays, and would like to flag these as NOT sortable.
A minor, but important, addition is the mentioning of sortable under what can be in the data.properties.<field> dictionary.

It is good that sortable is added to the example, but I don't understand the rationale for this:

The most major thing here (in my opinion) is the clarification that if sorting is possible for an entry endpoint, the sortable key MUST be present for all fields under data.properties. at /info/ and can be either true or false. Mainly this is because I am unsure how to sort on lists/arrays, and would like to flag these as NOT sortable.

I don't get why this is necessary? The description now clearly means that an omitted sortable means the same thing as sortable: false. If I only support sort on a few fields, it just seems unnecessary to force me to include sortable: false on everything else in my database. But, with the old formulation, if your implementation prefers to do it, you are still allowed.

I don't get why this is necessary? The description now clearly means that an omitted sortable means the same thing as sortable: false. If I only support sort on a few fields, it just seems unnecessary to force me to include sortable: false on everything else in my database. But, with the old formulation, if your implementation prefers to do it, you are still allowed.

I see your point. I guess my rationale comes from looking at this through the glasses of a client, where simply having the sortable key, implies the entry point is sortable (for some keys), while it is not sortable at all if I cannot find a sortable key for any property.

simply having the sortable key, implies the entry point is sortable (for some keys), while it is not sortable at all if I cannot find a sortable key for any given property.

If I understand you correctly, you are saying that you want clients to be able to use the presence or absence of the sortable key under any property as a way to deduce whether "sort is supported"?
I think this promotes a fragile implementation, which should not be supported. In general, for boolean indicator fields like this, it just is more expected, and robust, to let the absence of a key mean the exact same thing as false.
In this specific case, assigning this type of meaning to sortable: false would make a tricky distinction between "sort is supported, but no properties the client is aware of can be used to sort the output" (i.e., all properties return sortable: false) and "sort is not supported" (no sortable key present). I can imagine edge cases with sortable database-specific fields that are temporarily included for testing where it gets non-trivial to know whether sortable: false or no sortable key should be returned for other properties.
So, IMO, the algorithm that should be used by clients is: if any one property (that the client is aware of) contains sortable: true, then sort is supported. The client should anyway almost always want to tabulate the keys that can be used for sorting at the same time as it determines if sorting is supported.

@rartino I agree with your assessment of it being a fragile implementation. I will look at what I have and adjust it accordingly. Thanks for taking the time to consider this properly :)

@rartino and @merkys, I have added a new sentence describing what to do with a field name that cannot be used for sorting under an entry listing endpoint that supports sorting. Please feel free to review again :)

(...) /info/ endpoints only support json output (right?) so there is no point in trying to use output-format-agnostic language specifically for that output (right?).

Glancing through the specification, I cannot find a place where we specifically say that /info endpoints only support JSON output. However, we may state in more subtle ways.
E.g., in the base info response, we have the field entry_types_by_format, which is the only field truly connecting up endpoints and output formats. Since this is has to be entry type endpoints (i.e., not /info endpoints), then we are basically saying that a server has no other choice but to convey /info endpoints in our "default" format, i.e. JSON.

@CasperWA what you are saying matches my conclusions. We could say it more explicitly, but as far as I can tell, nothing is in error with what we have. I also don't think it would make sense for anything but entry endpoints to deliver data on other formats.


adds the extract_public() method for RSAPrivateKey

While generally passing around RSAPrivateKey as a PublicKey trait is optimal, there are some instances where you want to deal in concrete types and not be passing around the secret private data.  This PR adds a utility extract_public() method for RSAPrivateKey for those circumstances.

Thanks, also note that if you don't need the private key anymore, you can do the following already
let public_key: RSAPublicKey = my_private_key.into();

Now called to_public_key.   :)


Organize samples

Samples consist of two pieces:

A source code repository
A build CR, and for completeness, a buildrun CR

As of today, we have the CR samples in the samples directory. In, addition, for e2e tests, more CRs are in the test/data directory. That's fine for now.
Our sample code repositories are distributed across the planet. I suggest to bring them into the shipwright-io organization to mitigate that somebody removes the repos.
There are several ways to setup these repos. Putting together some options.
(1) A single samples repository named samples with a directory structure containing the sample code
(+) A single visible has good visibility
(-) Can become large. A lot of unnecessary files will be cloned for a build run.
(-) Does not work for build strategies that do not yet / can never support the contextDir feature. Not sure if we have some.
(2) One repository for each strategy named samples-{strategy}, may or may not contain sub-directories for different languages, e. g. sample-docker or sample-buildpacks
(+) Good for somebody who specifically looks how the sources for a specific strategy need to be prepared.
(-) Does not work for build strategies that do not yet / can never support the contextDir feature. Not sure if we have some.
(3) One repository for each language named sample-{language} (e. g. sample-java). Sample is built in a way supporting multiple strategies (specifically thinking about docker and buildpacks)
(+) Good for somebody who specifically looks for how the sources for a specific language can be built and who does not know much about the strategies
(+) Is small which will speed up e2e tests that use the repo.
(-) Can be confusing because it will contain a Dockerfile that is needed for a docker build but unnecessary for buildpacks. And will contain a buildpack.yml to configure certain buildpack details but that file is not relevant for the docker build.

If the samples are going to include source code to build, then I am inclined to go with option 3. I really like the idea of having multiple build strategies highlighted with the same set of source code. Being able to pick and choose build strategies is the "killer feature" IMO.
We should probably restrict the number of sample-xxx repositories to two or three languages - perhaps Java, NodeJS, and Python?
I also think we should use example-xxx instead of sample - a sample is generic, an example is specific.

This is an "option 3" example I cooked up today: https://github.com/adambkaplan/shipwright-example-nodejs

I think we should support both option 2 and option 3 in our new org: https://github.com/shipwright-io
For different types of example and for different tests.

Hi @adambkaplan or @qu1queee ,
I think we can go head moving the samples to our Shipwright org for v0.4.0
As we discussed in the meeting, we planed to create some separate repos for different source.
Like:

https://github.com/SaschaSchwarze0/npm-simple
git@github.com:qu1queee/newtaxi.git
git@github.com:qu1queee/new-nodejs-ex.git
https://github.com/SaschaSchwarze0/java-simple
etc ...

I found I have the permission to create new repo like:
https://github.com/shipwright-io/samples-npm-simple
If no objection, we will open the new repos for these personal sources and switch in our e2e test.

@zhangtbj thanks. I think is fine, but I will prefer different names, something like:

https://github.com/shipwright-io/samples-nodejs
https://github.com/shipwright-io/samples-java
https://github.com/shipwright-io/samples-go

Agree, they are better names.
If all agree, we can create the new repos by following these names.
BTW, @qu1queee, I cannot delete this repo: https://github.com/shipwright-io/samples-npm-simple
Can you help delete it on your side?

@zhangtbj so I covered most of the work via https://github.com/shipwright-io/build/pull/635. PR explains what I did, Im looking for help with:

we are missing the repo for JAVA runtime and the source code there. @SaschaSchwarze0 maybe you can help here.

Im looking for feedback in general for the new repos:
- https://github.com/shipwright-io/sample-php
- https://github.com/shipwright-io/sample-ruby
- https://github.com/shipwright-io/sample-nodejs
- https://github.com/shipwright-io/sample-go
@adambkaplan fyi ^^

we are missing the repo for JAVA runtime and the source code there. @SaschaSchwarze0 maybe you can help here.

I do not think I can create a repo, but if somebody creates one, I can add some Java sample to it.

Done. Is here: sample-java. @qu1queee

I would like to pick up this issue to add an e2e test for testing image building from a private repo.

I've split the private repository work into a separate issue: https://github.com/shipwright-io/build/issues/689

/close
Given that we are tracking the private repository work into a separate issue, I think we can call this issue done.


Update Erlang versions

Update all 23,24,25 to latest patch versions
Use 24 as a base for the full CI run

For posterity, leaving the commands used to update the versions in couchdb-ci repo:
ERLANGVERSION=<IP_ADDRESS> ./build.sh buildx-platform-release
BUILDX_PLATFORMS=linux/amd64 ERLANGVERSION=<IP_ADDRESS> ./build.sh buildx-platform debian-bullseye
ERLANGVERSION=<IP_ADDRESS> ./build.sh buildx-platform debian-bullseye
BUILDX_PLATFORMS=linux/amd64 ERLANGVERSION=25.2 ./build.sh buildx-platform debian-bullseye


Godot 4.0 KinematicBody3D Jitters when run into certain part of the wall using move_and_slide.

Godot version
4.0 beta5 official
System information
Windows 10, AMD Ryzen 7 3700X, RTX 2060 SUPER
Issue description
When CharacterBody3D run into certain part of a wall, it seems to be going back & forth into the wall and also slightly jumping up & down.
After a bit of research it looks like it is a known issue from Godot 3.x. For example: #32182 #61616
But I didn't find any report mentioning this bug for 4.0.
Here's the footage of the issue:
https://user-images.githubusercontent.com/88960642/204081347-6b8f07e0-ca76-46d8-b741-2f11973e64c6.mp4
Steps to reproduce

Add a CharacterBody3D and a CollisionShape3D of a capsule
Attach a script with default Basic Movement template to the CharacterBody3D
Add a floor and some walls using MeshInstance and generate Trimesh Static Body
Run the game and slide the CharacterBody3D against the wall

Minimal reproduction project
GD4.0 CharacterBody Collision Test.zip

Video doesn't play in firefox for me, but it does play in other media players if downloaded. Here's a re-upload that should play in-browser (apologies if this is only me and there are now two videos that both work fine):
https://user-images.githubusercontent.com/64640811/204084703-8a6cc34b-8186-45eb-8402-a7e45da67390.mp4

Probably related with #59632


Add Istio Gateway at the example

Add Istio Gateway at the example

We have already added this to make work the mTLS. So maybe we can close it, WDYT @rafabene )

+1 ... Closing....


"A CLR Profiler has already been attached" after few run with ForceGC

I used "HeapDump /ForceGC" directly to trigger GC on some process periodically. However I noticed that after it runs few times it start to throw errors like this:
"A CLR Profiler has already been attached.  You cannot attach another. (a process restart will fix)"
The problem is that I need keep the process running, e.g. w3wp process from iis. Is there anyway to find out why the profiler is still attached and how to detach it if possible?

Seems that the w3wp process is still having EtwClrProfiler.dll loaded after HeapDump quits.

@bigbearzhu you have to tear down the process, the dll once loaded in a certain way (i.e. from process startup) will always have it attached.

It is not attached at process startup. It is attached when HeapDump runs and detached after it finishes. It succeeds for a few times, and then start to fail to detach for some reason. Had a look at CorProfilerTracer.cpp line 298:
if ((MatchAnyKeywords & DetachKeyword) != 0 && !m_profilerLoadedAtStartup && !m_detaching)
Could m_profilerLoadedAtStartup be true when detaching so it is not detached?
https://msdn.microsoft.com/en-us/library/dd997942(v=vs.100).aspx#attach_details

Within the target process, the procedure for loading a profiler at attach-time is similar to the procedure for loading a profiler at startup-time: The CLR CoCreates the given CLSID, queries for the ICorProfilerCallback3 interface, and calls the ICorProfilerCallback3::InitializeForAttach method.

looked into the log of the EtwClrProfiler.dll. Seems it is getting error when trying to detach the profiler:
Creating new CorProfilerInstance
ClrProfiler Initializing
Registering the ETW provider
Initialize() returns 0
ProfilerControlCallback DoETWCommand IsEnabled 0x2 Level 0x5I64 MatchAny 0x0
DoETWCommand(IsEnabled=2, Level=5 Keywords=0x8000,0)
Detaching
Done Detaching Detaching ret = 0x80131363

while a successful detaching log is like this:
Creating new CorProfilerInstance
ClrProfiler Initializing
Registering the ETW provider
Initialize() returns 0
ProfilerControlCallback DoETWCommand IsEnabled 0x2 Level 0x5I64 MatchAny 0x0
DoETWCommand(IsEnabled=2, Level=5 Keywords=0x8000,0)
Detaching
Done Detaching Detaching ret = 0x0
ProfilerDetachSucceeded
Shutdown
Destroying CorProfilerInstance

As far as I can find, 0x80131363 is CORPROF_E_UNSUPPORTED_CALL_SEQUENCE as from here which I totally have no clue how that could happen and be solved. :(

I have same issue found on a different process (unrelated to w3wp). Mine is a very thread-hungry process, in case that rings some bells.


[FLINK-9694][table] Fix NPE in CRowSerializerConfigSnapshot constructor

What is the purpose of the change
Fix NPE in CRowSerializerConfigSnapshot constructor
Verifying this change
This PR adds new test to cover regression.
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): (yes / no)
The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no)
The serializers: (yes / no / don't know)
The runtime per-record code paths (performance sensitive): (yes / no / don't know)
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Yarn/Mesos, ZooKeeper: (yes / no / don't know)
The S3 file system connector: (yes / no / don't know)

Documentation

Does this pull request introduce a new feature? (yes / no)
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

LGTM, +1

+1, I will close my PR #6231 about this issue

Thanks, merging