[No QA] Add clarification notes on datepicker

Details
Add documentation notes regarding

https://github.com/Expensify/App/pull/5509#discussion_r718817770
and https://github.com/Expensify/App/pull/5509#discussion_r718818563

Fixed Issues

$ N/A
Tests

Only added comments
Tested that the app still works
QA Steps

Tested On

[x] Web
[ ] Mobile Web
[ ] Desktop
[ ] iOS
[x] Android

Screenshots

Web

Mobile Web

Desktop

iOS

Android

cc @roryabraham

🚀 Deployed to staging by @chiragsalian in version: 1.1.4-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


paket.dependencies autocompleete

Hi!
It'll be great if paket.dependencies file will autocomplete package names.
What are you think about it?

Moved to ionide-vscode-paket repo - https://github.com/ionide/ionide-vscode-paket/issues/19


Gitcord: Attempts to send messages to archived channels

When an issue is closed on GitHub, it's twin text channel on Discord is archived. This means that if anyone comments on a closed issue on GitHub, there is no where for the comment to go in our Discord server, so perhaps it should just be skipped.

[TEST]
Sending a comment from an open issue!

[TEST]
Sending a comment that will close the issue!

[TEST]
Sending a comment from a closed issue!

[TEST]
Sending a comment that will reopen the issue!


cancel is blocking but some docs say it is not

The API documentation for cancel clearly says:

cancel is a non-blocking Effect. i.e. the Saga executing it will resume immediately after performing the cancellation.

However, the blocking / non-blocking table says it is blocking. Experimentally it appears to be blocking, and I think it is very important that it is blocking.
Due to https://github.com/redux-saga/redux-saga/issues/408, if cancel is non-blocking it means that if you want to wait for a task to cleanup after being canceled that you need to pass a custom channel into the forked task, then issue cancel then run take on the channel to wait for it to die and finally be sure not to join on it. If it is blocking then you can just do a cancel instead of a join and be sure that the task is done, same as you would have with join which is much nicer.

It might be some kind of an issue for async cleanups. Could you specify when that's needed for you?

However, the blocking / non-blocking table says it is blocking. Experimentally it appears to be blocking, and I think it is very important that it is blocking.

It is a mistake then. The cancellation is non-blocking

If it is infact non-blocking then I think it'd be very useful to add a blocking variant to redux-saga. We've commonly been writing code that spawns some long-running sagas, waits for some action and then cancels the sagas. This is in contrast to having the individual sagas cancel themselves.
Unfortunately, after the cancel if we then join to wait for them to cleanup this will also cancel the parent saga which is very non-intuitive if you are coming from join semantics in a traditional threading paradigm. Even if we yield task.done instead it has the same effect as the join in that it cancels the parent saga.
Broken code (that I really wish worked but unfortunately the join cancels the current task which I claim should be considered a bug but #408 seems to claim is not a bug):
function* userLifecycleSaga() {
  while (true) {
    yield take('USER_DID_LOGIN');
    const updateTask = yield fork(watchUserState);
    yield take('USER_WILL_LOGOUT');
    yield cancel(updateTask);
    yield join(updateTask);
  }
}

Required workaround:
function* watchUserState(finishedChannel) {
  try {
  }
  finally {
    yield put(finishedChannel, 'anything');
  }
}

function* userLifecycleSaga() {
  while (true) {
    yield take('USER_DID_LOGIN');
    const finishedChannel = yield call(channel);
    yield fork(watchUserState, finishedChannel);
    yield take('USER_WILL_LOGOUT');
    yield cancel(updateTask);
    yield take(finishedChannel);
  }
}

Unfortunately this pattern is exhausting when it watchUserState needs to do the same thing with its sub-tasks, etc.
I'd argue that it is a bug that yield join(task) causes the caller to be cancelled.

A quick followup argument for not canceling when you join. You can always choose explicitly to do that behavior in user code thanks to yield cancel(). Assuming that join does not propagate a cancellation to the caller itself - they can do it themselves to get the current behavior:
yield cancel(updateTask);
yield join(updateTask);
if (updateTask.isCancelled()) {
  yield cancel();
}

Here is my workaround incase it helps anyone until (hopefully) join is fixed:
import {channel} from 'redux-saga';
import {all, call, join, put, take} from 'redux-saga/effects';

export function* waitForTask(task) {
  const barrier = yield call(channel);
  yield spawn(function* () {
    try {
      yield join(task);
    }
    finally {
      yield put(barrier, task);
    }
  });
  yield take(barrier);
}

export function* waitForTasks(...tasks) {
  return all(tasks.map(waitForTask));
}

This is then used later instead of join:
function* userLifecycleSaga() {
  const task1 = yield fork(watchSomething);
  const task2 = yield fork(watchSomethingElse);
  yield cancel(task1);
  yield waitForTasks(task1, task2);
}

Closing due to inactivity.  If this is still an issue then please reply and I will reopen and try to help.  Thanks!


chore: emit events

Closes: #7706

Thank you for the PR, @Sruthi2357. We will take this on in the team as it might require some spec updates and updates to the events themselves.


Poll support

Now that WhatsApp have polls too, currently when a poll is sent from whatsapp nothing is received on telegram side

I tried and received the poll, actually the last time I simply didn't received anything, no error or log, maybe connection issues

I reproduced the issue but I have no output in logs, how can I help?

Telegram
Whatsapp

here's the logs I received in debug mode
mag 08 09:27:33 rasp bash[401173]: 2023-05-08T09:27:33.807+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:99        new unhandled whatsapp event type        {"event_type": "*events.Connected"}
mag 08 09:27:33 rasp bash[401173]: 2023-05-08T09:27:33.944+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:99        new unhandled whatsapp event type        {"event_type": "*events.OfflineSyncCompleted"}
mag 08 09:28:20 rasp bash[401173]: 2023-05-08T09:28:20.687+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:44        new Message event        {"event_id": "C08E65191B730C02B44D8C71E5BA8821"}
mag 08 09:28:20 rasp bash[401173]: 2023-05-08T09:28:20.687+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:80        took text from Conversation        {"event_id": "C08E65191B730C02B44D8C71E5BA8821", "text": ""}
mag 08 09:28:20 rasp bash[401173]: 2023-05-08T09:28:20.687+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:92        new message from others        {"event_id": "C08E65191B730C02B44D8C71E5BA8821"}
mag 08 09:28:20 rasp bash[401173]: 2023-05-08T09:28:20.859+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:243        trying to retrieve context info from Message        {"event_id": "C08E65191B730C02B44D8C71E5BA8821"}
mag 08 09:28:20 rasp bash[401173]: 2023-05-08T09:28:20.860+0200        DEBUG        WaTgBridge_Dev        whatsapp/handlers.go:308        no context info found in any kind of messages        {"event_id": "C08E65191B730C02B44D8C71E5BA8821"}


Additional team stats

Codecov Report

Merging #95 into master will increase coverage by 0.08%.
The diff coverage is 92.53%.

@@            Coverage Diff            @@
##           master     #95      +/-   ##
=========================================
+ Coverage   85.61%   85.7%   +0.08%
=========================================
  Files          73      74       +1
  Lines        2997    3057      +60
  Branches      436     443       +7
=========================================
+ Hits         2566    2620      +54
- Misses        371     374       +3
- Partials       60      63       +3


Problem with the name of the datafield set

If the name of the datafield set contains uppercase characters...
\DeclareDatafieldSet{NAME}{
  \member[...]
}

\DeclareStyleSourcemap{
  \maps{
    \map[foreach={NAME}]{
      \step[fieldsource=\regexp{$MAPLOOP}, match=..., replace=...]
    }
  }
}

...  the sourcemapping fails.
Is there any particular reason why loopval must be written in lower case?

Looks like a bug. Which combinations of upper/lower for the set name and loopval don't work?

set name can be written in any way (upper case, CamelCase, etc.)
loopval can be written only in lower case
if set name is written in upper case and loopval is written in lower case, the sourcemapping works fine
but, if set name is written in lower case and loopval is written in upper case, the sourcemapping fails

Can you try 2.20 DEV version from SF? I think this should be fixed.

I just downloaded and installed biber 2.21 (beta). Unfortunately, nothing has changed.

Works now for me - which platform binary did you download of 2.20?
\documentclass{article}
\usepackage{biblatex}
\addbibresource{biblatex-examples.bib}
\DeclareDatafieldSet{TEST}{
  \member[field=title]
}
\DeclareStyleSourcemap{
  \maps{
    \map[foreach={TEST}]{
      \step[fieldsource=\regexp{$MAPLOOP}, match=a, replace=z]
    }
  }
}
\begin{document}
\cite{kastenholz}
\printbibliography
\end{document}

I'm typesetting on macos 14.5 (Sonoma, latest version) and use the MacTeX-2024 Distribution.
I downloaded and installed the binary compressed into biber-darwin_x86_64.tar

Hmm, can you get 2.21 dev version from sourceforge? This works for me with the above example.

I just reinstalled. Now it works, thanks.


intermediate results skeleton

is this sufficient for someone to add the rabbitmq part onto and close #34?

to be completed in #46


Cert manager helm chart

The helm chart is copied from the source repo, but slightly modified so we can set our registry instead of quay.
/hold
Wanted to get this out there for comments, but need to create a repo for helm chart if this looks good.

its very possible you did this and I just missed it, but for these helm charts that we are copying from upstream, maintenance will be become a nightmare. Could we put in a place a process for clearly marking the aws changes in the code or in the readme (if we really dont want to clutter the code) so that when we need to update its a simpler diff process?

/override cfssl-tooling-presubmit
/override hegel-tooling-presubmit

/unhold

/test eks-anywhere-cli-tools-tooling-presubmit

build kit can't open some files, looks like some disk issue. Retesting


question about the $z^e$ in equ.9

This work is very interesting. In section 2 Notations, define $z^e$ as the batch of validation  samples.
What I am curious about is how to select the validation batch for each training sample to calculate the gradient similarity between the training sample $z^{r}_{i}$ and the validation batch $z^e$.  Different selection of $z^e$ may result in significant differences in gradient similarity.  I don't know if I misunderstood.
Looking forward to your reply ！: ）

Similar to the choice of training batches, $z^e$ is randomly choosen from the validation set. For each training step, the $z^e$ will be different, i.e. sample from the validation set. As the training process proceeds, the validation batch will iterate over all samples in the validation batch. Similar to the concept of SGD, here we sample a batch from the validation set.
The selection of $z^e$ should be random to represent the performance on unseen dataset.

For more details, you can refer to our code https://github.com/twinkle0331/LGTM/blob/main/run_glue.py#L689

Thank you!


Feature Request: Use HAs ingress auth

Hey,
Home Assistant allows sending the authenticated username via the X-Remote-User-Name header: https://developers.home-assistant.io/docs/add-ons/security#authenticating-a-user-when-using-ingress
And Paperless seems to be able to receive such a header:
https://docs.paperless-ngx.com/configuration/#PAPERLESS_ENABLE_HTTP_REMOTE_USER
So it should be possible to use the HA auth to authenticate against a paperless user, which would improve UX by skipping the paperless login.

I'll probably add this as a toggable feature,
You can already update paperless.conf manually.
Some users are using external auth providers and use direct access to the add-on, so ingress auth doesn't match all user`s needs

This would be an amazing feature :-). I just wonder what this would mean to migrating to this approach - would this have any effects on user roles and such?

@klassm you will just be logged in to the username corresponding to the home assistant one.

I'll probably add this as a toggable feature,
You can already update paperless.conf manually.
Some users are using external auth providers and use direct access to the add-on, so ingress auth doesn't match all user`s needs

I tried that with:
PAPERLESS_ENABLE_HTTP_REMOTE_USER=true
PAPERLESS_ENABLE_HTTP_REMOTE_USER_API=true
PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME=HTTP_X_REMOTE_USER_NAME

But that didn't work out. Afterwards, I didn't look any further.

There's a nginx proxy https://github.com/BenoitAnastay/paperless-home-assistant-addon/blob/main/paperless-ngx/rootfs/etc/nginx/templates/ingress.gtpl
I need to add the header there, my comment wasn't accurate then.

There is something wierd with paperless, it seems that ingress path interfer with remote user header somehow

Implemented in the last release


chore: add parallax template

@Thom-x — The template looks awesome — would you mind if it gets added to the repo?

No problem, go ahead 👍

@Thom-x — FYI, If you want to show off your template on your repo — I have them generated here: https://modem7.github.io/docker-error-pages/


Bug?

Gledopto connected to hue hub stopped working
At the same time they work from the hue program


Adjust for docker.io rate limits

Describe the bug
Builds can fail due to docker.io rate limits like so:
Unable to find image 'busybox:latest' locally
docker: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit.
See 'docker run --help'.

To Reproduce
do a bunch of builds, then look at the logs
Expected behavior
builds run
Additional context
This is caused by using base images hosted by docker.io we can use a different registry for base images to avoid this.

I think this is sorted for now. If building the builder images becomes a problem, something like #150 can solve that

we still pull docker.io images and so can hit rate limits. For example registry:2 tinygo and rust images are all pulled. I'm not sure which of these are rate-limit-free

a friend of mine setup a cron job to mirror images to GitHub's registry. I don't have access to create packages, but I could set something like this up if someone gives me karma https://github.com/open-telemetry/opentelemetry-java/blob/main/.github/workflows/docker-test-containers.yml

We should probably address this...
Step 1/8 : FROM rust:1.44.1
toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Replacing         run: make builders with something like this could help, but it has to be revised to also work with osx. Meanwhile I think it would be time better spent using images that are explicitly not on docker.io
        run: |
          # While parent layers are references to docker.io, add Google's mirror to help avoid docker.io rate limits.
          # * See https://cloud.google.com/container-registry/docs/pulling-cached-images
          echo '{ "registry-mirrors": ["https://mirror.gcr.io"] }' | sudo tee /etc/docker/daemon.json
          sudo service docker restart
          make builders

I have access now, so will fix this


Whenever my program runs, swigger automatically refreshes the page. Then the api parameters are lost, which is very inconvenient. How to make it not refresh automatically?

Whenever my program runs, swigger automatically refreshes the page. Then the api parameters are lost, which is very inconvenient. How to make it not refresh automatically?

Disable hot reload in Visual Studio.


Discuss: rework ThemeRegistry.Current

With the rework to a Builder pattern, a discussion came up for ThemeRegistry.Current:  https://github.com/Assorted-Development/winforms-themes/pull/6#issuecomment-1666193187

We should, at some point, reconsider the necessity of ThemeRegistry.Current since it's not set automatically at the moment and could be easily confused with a property that always holds the current applications' theme - especially since, with this issue, it doesn't get set automatically anymore at all.

For the ThemeRegistry, we already use a specialised holder class ThemeRegistryHolder, maybe this would be a solution

Before discussing our options we may need to define what our requirements are:

The current solution allows to have multiple ThemeRegistrys (when not using ThemeRegistryHolder.ThemeRegistry) - each with their own Current theme.
The user should be able to use their own way of publishing the Current them (e.g. Microsoft.Extensions.DependencyInjection)
It should be clean code (obviously)
It should be easy to understand for a user
Do not add another dependency to the library (if possible)
...

So what are our options:
a) The most obvious option is to do nothing at all: Remove the Current property and rely on the using application to handle everything. Most likely, this would mean removing ThemeRegistryHolder too for the same reasons.
b) Add a ThemeHolder class to the project. This would be the same as ThemeRegistryHolder. It extracts the logic for the current theme from the IThemeRegistry and allows users without other options to access the current theme easily.
c) We could keep ThemeRegistry.Current but make it more explicit by adding a SetCurrentSelector(Func<IThemeRegistry, ITheme> selector) to the builder. If this was used to set a selectorfor the current theme, Current will return the theme as selected by this function. If no function was provided, this would raise an error. This way, callers can still access any theme, but Current would return the current theme in all cases. Maybe the function could also be an interface also providing a CurrentChanged event to notify the registry when the current theme changes. This way, Current would not need to call the function continuously.
d) ...

Sooo.. I think requirement 1 is nice, but not that necessary since most applications won't have more than one theme applied to them at any given time. At least I can't think of any reason for that, but I'm happy to read any from you :smile:.
I agree with 2. to 5., though. Requirement 6 would (probably obvious) be that we even can apply more than one theme (not at once, but in general) to an application and therefore might still need the Current property or something like it.
With that said: If we want to provide a Current, we are also responsible for it to return the real current theme at all times.
If we don't, we invite confusion and a lot of potential oversight (even if by the users) in regards to theming behavior.
I also do prefer keeping Current, so that would remove option a).
Option c) looks a bit complex (especially if we don't really need multiple ThemeRegistrys), Option b) still lacks the automatic behavior I described above or would make it way harder to implement imho.
So I'd propose kind of a middle ground option d):
We could introduce an Apply(ITheme) inside IThemeRegistry that calls ITheme.Apply and lets Current return this theme, so that everyone who wants to use Current can have an automatic way built-in to really handle everything whereas users that want more flexibility still can call Apply on the ITheme.
What do you think?

Okay, so far we are aligned in regards to the requirements. The first topic was not a hard dependency but a nice to have (and no, I have no usecase for that).
Let's focus on the options (c) and (d) for now:

Option c) looks a bit complex (especially if we don't really need multiple ThemeRegistrys)

What do you mean with complex? The easiest implementation (as I said, we could improve this with an interface providing Change detection) would be:

Update ThemeRegistryBuilder to allow setting a function Func<IThemeRegistry, ITheme>
Update IThemeRegistry.Current to not having a setter and the getter calls the function with itself as parameter and returns the result of the function call
a simple function impl could look like

private ITheme GetCurrentTheme(IThemeRegistry registry) {
   //get current settings from config
   ThemeCapabilities caps = ...;
   //return the current theme
   return registry.Get(caps);
}

We could introduce an Apply(ITheme) inside IThemeRegistry that calls ITheme.Apply and lets Current return this them

Where does the ThemeRegistry get all the forms from that the theme should get applied to? We shouldn't expect all applications to have a crentral registry of all forms and even then, Apply(ITheme) would need to get the forms passed as parameter. It seems to me that you just do a SetCurrentTheme() here.

Option c) looks a bit complex (especially if we don't really need multiple ThemeRegistrys)

What do you mean with complex? The easiest implementation (as I said, we could improve this with an interface providing Change detection) would be:

Update ThemeRegistryBuilder to allow setting a function Func<IThemeRegistry, ITheme>
Update IThemeRegistry.Current to not having a setter and the getter calls the function with itself as parameter and returns the result of the function call
a simple function impl could look like

private ITheme GetCurrentTheme(IThemeRegistry registry) {
   //get current settings from config
   ThemeCapabilities caps = ...;
   //return the current theme
   return registry.Get(caps);
}

What I meant with complex is (but maybe I just think in the wrong direction) that the user doesn't have a simple way to just set a Theme and have it returned by Current as the current theme. The user would always be forced to provide some kind of lookup table (or something similar).
But I would be completely fine with this solution if we don't find anything less complex😄

We could introduce an Apply(ITheme) inside IThemeRegistry that calls ITheme.Apply and lets Current return this them

Where does the ThemeRegistry get all the forms from that the theme should get applied to? We shouldn't expect all applications to have a crentral registry of all forms and even then, Apply(ITheme) would need to get the forms passed as parameter.

Maybe my signature example was a bit to simplified, what I meant was to just give a possibility to "forward" the call via IThemeRegistry - it could also mean providing something like Apply(ITheme, Form, [ThemeOptions].

I will open a PR with my proposed change and we can discuss the pro and contra there.


pianoteq.standard-8: init at 8.1.1

Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Why is ofborg not reporting any changed packages?

@SuperSandro2000 that's a good question. These packages are also not shown on search.nixos.org

@SuperSandro2000 maybe it's because it relies on a paywalled source download.

@SuperSandro2000 could you have another look?


TypeError: object of type 'NoneType' has no len()

Hi,
apologies in advance for the rookie question and if it has already been answered on another post (I did try and search for it).
Off teh back of the excellent TM1py presentations by Marius Wirtz at the Cubewise TM1 horizon event I have downloaded the latest Python (version 3.8), Jupyter and TM1py with pandas. I have succesfully established a connection to a TM1 server using check.py.
I am now trying to follow the examples from the presentation "Getting from zero to writing your first script in TM1py" by Marius and am stuck on Challenge 1!
I have entered the following code succesfully:
import pickle
from datetime  import datetime
import pandas as pd
from TM1py import TM1Service, Hierarchy, Dimension, Element
However the next part:
tm1 = TM1Service(adress="loncgapv08", port=40078, user="", password="", ssl=True)
Gives me the following error:

TypeError                                 Traceback (most recent call last)
 in
----> 1 tm1 = TM1Service(adress="loncgapv08", port=40078, user="", password="", ssl=True)
c:\python\python38\lib\site-packages\TM1py\Services\TM1Service.py in init(self, **kwargs)
11
12     def init(self, **kwargs):
---> 13         self._tm1_rest = RestService(**kwargs)
14
15         # instantiate all Services
c:\python\python38\lib\site-packages\TM1py\Services\RestService.py in init(self, **kwargs)
148             self._base_url = "http{}://{}:{}".format(
149                 's' if self._ssl else '',
--> 150                 'localhost' if len(self._address) == 0 else self._address,
151                 self._port)
152
TypeError: object of type 'NoneType' has no len()
Any ideas what I am doing wrong? I have tries fully qualifiying the address eg "https://loncgapv08" but that does not help. I'm using the same credentials/valies etc as I was using for the check.py.
Cheers
Mike

Hi,
it's just a typo in adress. It should be address

PS
Thanks.  I must have looked at the code 50 times and not noticed that.
Marius thanks for taking time out to reply, it’s much appreciated.
Cheers
Mike
Sent from my iPhone

On 27 Aug 2020, at 17:26, Marius Wirtz<EMAIL_ADDRESS>wrote:

Hi,
it's just a typo in adress. It should be address
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

 Feel free to post more questions.


Resource file not found: gmod/helpers/macros/template/Sent.lua on 0.2.3

Running haxelib run gmodhaxe caused the issue

Many thanks for submitting an issue - have released a new version now 0.3.0 on here and haxelib and that should resolve things. I thought the templates were working, oh well


[swarm] docker swarm init outputs misleading message using --force-new-cluster

Output of docker version:
Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 23:54:00 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:        Thu Jul 28 23:54:00 2016
 OS/Arch:      linux/amd64

Output of docker info:
Containers: 0
 Running: 0
 Paused: 0
 Stopped: 0
Images: 0
Server Version: 1.12.0
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 0
 Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge overlay host null
Swarm: active
 NodeID: df6gzrjv1n81e13jgr5bxp2z8
 Is Manager: true
 ClusterID: 0xbv16vkxegfboode2p9t3xr5
 Managers: 1
 Nodes: 5
 Orchestration:
  Task History Retention Limit: 5
 Raft:
  Snapshot interval: 10000
  Heartbeat tick: 1
  Election tick: 3
 Dispatcher:
  Heartbeat period: 5 seconds
 CA configuration:
  Expiry duration: 3 months
 Node Address: <IP_ADDRESS>
Runtimes: runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 4.4.16-boot2docker
Operating System: Boot2Docker 1.12.0 (TCL 7.2); HEAD : e030bab - Fri Jul 29 00:29:14 UTC 2016
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 995.9 MiB
Name: master1
ID: XFBC:QIPK:ZJH5:MGSZ:D6IA:32XG:TUHL:6E43:HXOQ:FVLW:OY64:HWD4
Docker Root Dir: /mnt/sda1/var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 31
 Goroutines: 117
 System Time: 2016-07-29T01:08:52.00834001Z
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
 provider=virtualbox
Insecure Registries:
 <IP_ADDRESS>/8

Additional environment details (AWS, VirtualBox, physical, etc.):
Steps to reproduce the issue:

docker swarm init --force-new-cluster --advertise-addr <IP_ADDRESS>

Describe the results you received:
To add a worker to this swarm, run the following command:
    docker swarm join \
    --token  \
    <IP_ADDRESS>:2377

To add a manager to this swarm, run the following command:
    docker swarm join \
    --token  \
    <IP_ADDRESS>:2377

Describe the results you expected:
To add a worker to this swarm, run the following command:
    docker swarm join \
    --token xxxxxxxxx \
    <IP_ADDRESS>:2377

To add a manager to this swarm, run the following command:
    docker swarm join \
    --token xxxxxxxxx \
   --manager \
    <IP_ADDRESS>:2377

Additional information you deem important (e.g. issue happens only occasionally):

Was this a machine that was upgraded from a previous version of docker (e.g. RC4 or RC5)?
Before doing --force-new-cluster, did the docker swarm join-token ... output a join-token, or was it empty?

@thaJeztah sorry about the delayed reply. I wasn't able to reproduce this error.


Splits Delivery and Payment Checkout Steps

Several Spree modules rely on certain checkout-transition callbacks being triggered during checkout. As a result of smushing delivery and payment steps together, Sprangular inadvertently skips these callbacks, which causes some weird behaviours. See #168 for additional details.
This commit attempts to correct this issue by performing the two checkout steps discretely.

@dw Looks good :+1:

CI builds (other than Hound) are not supposed to pass, right?

@joshnuss Any issues merging this?

Actually, hold pls.

The only bit that makes me slightly uncomfortable passing in an on-selection handler to the shipping-rate selection directive. It feels awkward; ng-model should handle it. But I can't figure out how to impel advancement of the checkout process if the shipping-rate doesn't change.
Thoughts?

@joshnuss Much as I appreciate the complement, I wish I didn't receive quite as much random GitHub mail of this sort :)

@DanielWright if you've tested it, it looks good to merge
(sorry I keep using the wrong username)

Hah, it's a bit confusing since I go by DW everywhere else. (Sorry, the-real-dw.)
Rod and I are working through the UX implications in one of our host apps, I'm going to leave this PR unmerged until we are feeling a bit more comfortable.

@rodrigodalcindev
How do you feel about where the UX is at for this?

@DanielWright I'm not sure we have got to a consensus regarding the delivery-payment split yet.

@rodrigodalcindev
Same question as last time. D'you think we're close enough on UX now that we can get this integrated and mergeable?

@DanielWright I've tweaked the checkout view's UI/UX in order to reflect the step splitting. I'll rebase it to #63 once the PR is merged to master.


Apply cloud shell bug fixes

Bug fixes that will be applied on top of the initial cloud shell migration #848. Putting this PR up for testing purposes. I'll explain each fix individually later.
How to test:
Make sure to run webpack before testing locally. The feature relies on the cloudShellLauncher.ts file being webpacked and put in dist.

I'll explain each fix individually later

I still plan on doing this 🙈 , I will ping people when I'm done. Busy busy


If you press enter without a space after a calendar entry, it turns pink

@nywillb I think this is because the code is including the newline as part of the first word.

Fixed!

@thatoddmailbox check before you close

@willweinstein but I did

@thatoddmailbox but its worse

@thatoddmailbox @willweinstein There is just no pull request for it. He fixed it.

@nywillb no he didn't, go on the planner and check

There is no pull request for it.  CUZ THE BUG IS DIFFERENT THAN DESCRIBED

@willweinstein I think this has been fixed. If it hasn't, reopen, and explain exactly what you are talking about.


kill xoputil.BaseAttributeType in favor of xopbase.DataType; add test…

… coverage

Codecov Report
Base: 65.77% // Head: 75.94% // Increases project coverage by +10.17% :tada:

Coverage data is based on head (b800626) compared to base (26aba20).
Patch coverage: 55.67% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##             main      #57       +/-   ##
===========================================
+ Coverage   65.77%   75.94%   +10.17%
===========================================
  Files          39       39
  Lines        3714     3742       +28
===========================================
+ Hits         2443     2842      +399
+ Misses       1198      832      -366
+ Partials       73       68        -5

Flag
Coverage Δ

go_tests
75.94% <55.67%> (+10.17%)
:arrow_up:

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

Impacted Files
Coverage Δ

xopbase/datatype_enumer.go
0.00% <0.00%> (ø)

xopat/attributes.go
45.28% <50.00%> (+0.38%)
:arrow_up:

xopjson/attributes.go
97.28% <100.00%> (+39.59%)
:arrow_up:

xoptest/testlogger.go
98.80% <100.00%> (+33.33%)
:arrow_up:

xopjson/jsonlogger.go
76.16% <0.00%> (+0.77%)
:arrow_up:

basegroup.go
92.16% <0.00%> (+5.52%)
:arrow_up:

span.go
79.66% <0.00%> (+15.25%)
:arrow_up:

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

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


Fix the profiling data finished time is greater than task duration

The rover uses the scratch mechanism to get data from the eBPF runner with intervals, but the profiling task duration is fixed. So the end time of the profiling data could be out of the profiling task duration.
When the duration of the profiling task is the same as the time that OAP can analyze, it may cause the failure to analyze.

Closing this, @mrproliu please make sure lint is placed before the release.


LDK init error: channel_manager_constructor init Failed

My Bluewallet LDK stopped working after opening a new channel.
It alerts on startup:
LDK init error: channel_manager_constructor init Failed

looks channels state is borked. i can take a look and try to recover if you send me ldk wallet backup to<EMAIL_ADDRESS>

Done, thanks in advance

hi, same issue here, do I send the backup to the same email?

UPDATE:
I recovered the wallet successfully on an Android, the issue seems to be only on iOS.

Why is this issue closed? I'm still struggling with this in iOS


Adds descriptions for create data frame analytics job API

This PR adds some more descriptions based on the create data frame analytics job API docs. It also sorts some existing properties alphabetically.

Thanks! Can you try to run make contrib again?

I rebased too and that seems to have done the trick, thanks!


Add OAuth2 HTTP handler

Adding support for OAuth2 handler will enable us to support all these backends : https://github.com/golang/oauth2
The handler should simply perform:
token := oauth2.Token{AccessToken: string(token)}
token.SetAuthHeader(r)

Note: this could potentially be built using the generic HTTP connector or possibly even written via config.


Improve css

styling of container, flexboxes
font-display: block for large-numbers

Duplicate of #6


Building 2.2 preview 3 using tarball fails on Fedora 29

I am on Fedora 29.
I am on 2.2 preview3:
$ git branch -v
* (HEAD detached at v2.2.0-preview3) 1bfe7fc Apply UseStableVersions to CLI (#824)

I can build this online using ./build-source-tarball.sh but not offline using the created tarball.
In particular vstest fails:
    Restoring packages for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj...
    Restore completed in 19.45 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.CrossPlatEngine/Microsoft.TestPlatform.CrossPlatEngine.csproj.
    Restore completed in 18.54 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.ObjectModel/Microsoft.TestPlatform.ObjectModel.csproj.
    Restore completed in 18.54 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.PlatformAbstractions/Microsoft.TestPlatform.PlatformAbstractions.csproj.
    Restore completed in 19.45 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.CommunicationUtilities/Microsoft.TestPlatform.CommunicationUtilities.csproj.
    Restore completed in 18.54 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.Utilities/Microsoft.TestPlatform.Utilities.csproj.
    Restore completed in 19.45 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.Common/Microsoft.TestPlatform.Common.csproj.
    Restore completed in 18.54 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/Microsoft.TestPlatform.CoreUtilities/Microsoft.TestPlatform.CoreUtilities.csproj.
    Installing runtime.win7.System.Private.Uri 4.0.2.
    Installing runtime.win7-x64.Microsoft.NETCore.DotNetHost 1.0.1.
    Installing runtime.win7-x64.Microsoft.NETCore.Windows.ApiSets 1.0.1.
    Installing runtime.win7-x64.Microsoft.NETCore.Jit 1.0.7.
    Installing runtime.win7-x64.Microsoft.NETCore.DotNetHostResolver 1.0.1.
    Installing runtime.win7-x64.Microsoft.NETCore.Runtime.CoreCLR 1.0.7.
    Installing runtime.win7-x64.Microsoft.NETCore.DotNetHostPolicy 1.0.5.
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.CommunicationUtilities is not compatible with net451 (.NETFramework,Version=v4.5.1). Project Microsoft.TestPlatform.CommunicationUtilities supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.ObjectModel is not compatible with net451 (.NETFramework,Version=v4.5.1). Project Microsoft.TestPlatform.ObjectModel supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.CrossPlatEngine is not compatible with net451 (.NETFramework,Version=v4.5.1). Project Microsoft.TestPlatform.CrossPlatEngine supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.CoreUtilities is not compatible with net451 (.NETFramework,Version=v4.5.1). Project Microsoft.TestPlatform.CoreUtilities supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.VisualStudio.TestPlatform.Common is not compatible with net451 (.NETFramework,Version=v4.5.1). Project Microsoft.VisualStudio.TestPlatform.Common supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.CommunicationUtilities is not compatible with net451 (.NETFramework,Version=v4.5.1) / win7-x64. Project Microsoft.TestPlatform.CommunicationUtilities supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.ObjectModel is not compatible with net451 (.NETFramework,Version=v4.5.1) / win7-x64. Project Microsoft.TestPlatform.ObjectModel supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.CrossPlatEngine is not compatible with net451 (.NETFramework,Version=v4.5.1) / win7-x64. Project Microsoft.TestPlatform.CrossPlatEngine supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.TestPlatform.CoreUtilities is not compatible with net451 (.NETFramework,Version=v4.5.1) / win7-x64. Project Microsoft.TestPlatform.CoreUtilities supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj : error NU1201: Project Microsoft.VisualStudio.TestPlatform.Common is not compatible with net451 (.NETFramework,Version=v4.5.1) / win7-x64. Project Microsoft.VisualStudio.TestPlatform.Common supports: netstandard1.4 (.NETStandard,Version=v1.4) [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]
    Generating MSBuild file /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/obj/datacollector.csproj.nuget.g.props.
    Generating MSBuild file /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/obj/datacollector.csproj.nuget.g.targets.
    Restore failed in 928.04 ms for /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/src/datacollector/datacollector.csproj.
  cp: cannot stat 'src/testhost/bin/Release/net451/win7-x64/*': No such file or directory
  cp: cannot stat 'src/testhost.x86/bin/Release/net451/win7-x86/*': No such file or directory
  ^[[0;32m... .. Package: Publish testhost.csproj^[[0m
  Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core
  Copyright (C) Microsoft Corporation. All rights reserved.

Our latest release/2.2 build on Red Hat had the same messages in the vstest build log but continued and succeeded:
https://ci.dot.net/job/dotnet_source-build/job/release_2.2/job/RHEL7.2_Unshared_Release_Portable/9/
https://ci.dot.net/job/dotnet_source-build/job/release_2.2/job/RHEL7.2_Unshared_Release_Portable/9/artifact/tarball-output/bin/logs/vstest.log/*view*/
I kicked off a build of that commit on the microsoft/dotnet-buildtools-prereqs:fedora-29-2f0798a-20181105183801 image (we'll be adding this to release/2.2 CI soon) to repro and look deeper.

Weird. I know something in vstest fails. The build log says:
/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/dir.targets(242,5): error MSB3073: The command "/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/src/vstest/build.sh -DotNetBuildFromSource -DotNetCoreSdkDir /home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/Tools/dotnetcli/ -c Release -r fedora.29-x64 -v 15.9.0 -vs preview-20180807-05  " exited with code -1. [/home/omajid/fedora-git/dotnet-2-2-build/dotnet-2.2.0-preview3/repos/vstest.proj]

If it's not those lines, I am not sure what it is.

My build still got the error lines, but didn't repro the -1 exit code or build halt. 😕 Just to make sure, are there any more lines in the vstest log after the ones you pasted?
The vstest repo's build script has very little logging... my next suggestions would be to add set -x to src/vstest/scripts/build.sh to get some visibility, and /bl:SomeUniqueName.binlog for each of the dotnet commands.
Something else very general that comes to mind is the environment affecting the build... the way I do things in Docker gives me a fresh HOME (among other things) every time, and I don't think we've ever been very confident in our build's ability to handle anything other than a pristine machine. If that's the case, hopefully we can tell in logs (and maybe even fix it).

I tried to reproduce this in a clean environment. Turns out I can do this in an online build too. All I need to do for the build to fail is
./build.sh /p:MinimalConsoleLogOutput=false

I am now trying to figure out the actual issue.

That would do it... Exec does some "standard" parsing of the output:
https://docs.microsoft.com/en-us/visualstudio/msbuild/exec-task?view=vs-2015
See IgnoreStandardErrorWarningFormat
About the format:
https://blogs.msdn.microsoft.com/msbuild/2006/11/02/msbuild-visual-studio-aware-error-messages-and-message-formats/
Without the redirect to file, I bet Exec is spotting that MSBuild error and failing. Adding IgnoreStandardErrorWarningFormat="true" sounds like the fix to me.

Well, and/or fixing the vstest issue causing error output, but adding IgnoreStandardErrorWarningFormat seems more stable because it will remove this difference between MinimalConsoleLogOutput true/false.

I merged a change into release/2.2 that should fix this, could you give it a try?

Works great for me now. Thanks!

Sweet, thanks for verifying. 🙂 Closing as resolved.


Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore is needed to follow guide

Using VS 2022 and following instructions but got:
Error	CS1061	'IServiceCollection' does not contain a definition for 'AddDatabaseDeveloperPageExceptionFilter' and no accessible extension method 'AddDatabaseDeveloperPageExceptionFilter' accepting a first argument of type 'IServiceCollection' could be found (are you missing a using directive or an assembly reference?)
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore was missing.
Sauce:
https://stackoverflow.com/questions/65007086/services-adddatabasedeveloperpageexceptionfilter-error-code-cs1061

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: ab408035-6313-a183-9940-32de00e0e977
Version Independent ID: ab408035-6313-a183-9940-32de00e0e977
Content: Tutorial: Create a minimal web API with ASP.NET Core
Content Source: aspnetcore/tutorials/min-web-api.md
Product: aspnet-core
Technology: aspnetcore-tutorials
GitHub Login: @Rick-Anderson
Microsoft Alias: riande

@p1k4x ... I'm going close this now because my suggestion has visibility for a possible inclusion on an existing PR for this topic. It's best if we avoid self-inflicted 😈 merge conflicts 😈 where we can. 😄

fixed with #27353.

This was important to fix and happened to be already underway for a couple of topics, including this one.  Thanks #p1k4x for taking the time to identify the issue.  Really appreciate your commitment to the community.


Fix glTexImage3D

internalformat parameter is a GLenum, but the function pointer expects a GLint.

As per commit message, OpenGL registry has special enums with special tag 'type', which should override the default GLenum. This is now fixed.


Long table names can be truncated on Postgres (at least) silently

Describe the bug
Long table names appear to be truncated by Postgres, but this behavior could also be present on other databases. This was just reproduced with a temp table suffix in a Snapshot query on Postgres, but I imagine this could just happen with exceptionally long table names:

The truncation will cause lots of problems across dbt, but the proximate issue here is that a subsequent information schema query will return zero rows (it's looking for the wrong identifier) which bricks a snapshot run. The quick user-space fix is to shrink the "base" name of the table, but we should also take action here to:

Reduce the length of the table suffix appended by dbt
Show a warning (or probably an error!) if a table is created with a name long enough for PG to truncate

More info on this PG constraint here.
Example informations schema query
      select
          column_name,
          data_type,
          character_maximum_length,
          numeric_precision,
          numeric_scale

      from information_schema.columns
      where table_name = 'github_issues_linked_to_open_pull_requests__dbt_tmp20200311221237629328'
      order by ordinal_position

> Returns 0 rows

System information
Which database are you using dbt with?

[x] postgres
[?] redshift
[?] bigquery
[?] snowflake

The output of dbt --version:
Reproduced on 0.14.3

Add a runtime error to create table as that checks for relation identifier length


Address TCPIngress and UDPIngress collision

What this PR does / why we need it:

Add a test for a TCPIngress and UDPIngress that point to the same integer port (but different protocols) on the same Service.
Add a map to de-duplicate upstreams by name. Upstreams use names of the form "...svc". Kong upstreams do not differentiate by protocol (despite, yes, the fact that including a port implies that they probably should) and thus TCP and UDP Service ports with the same port number should indeed both generate the same upstream.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged):
fixes #1446
Special notes for your reviewer:
The new tests also add locks to the TCP and UDP tests. This ensures that the tests can still run parallelized, just not specifically concurrently with one another. They cannot run concurrently due to limited port availability; running them concurrently would create overlapping routes or prevent cleanup confirmation from working.
This avoids creating additional port listens on the KTF side while still retaining most of the parallel testing speed benefits. Full parallelization requires a unique port for each test, so if we were to add additional TCP/UDP tests in the future, we'd probably still end up needing locks with multiple ports available unless we keep adding new ports each time.
PR Readiness Checklist:
Complete these before marking the PR as ready to review:

[ ] the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

@rainest, please allow me some time to also comment on this PR before merging, I have some thoughts regarding usage of a map. I've seen this PR briefly on my phone on this Friday night and I'll have time for a proper review first thing on Monday.
Thanks!

@rainest, please allow me some time to also comment on this PR before merging, I have some thoughts regarding usage of a map. I've seen this PR briefly on my phone on this Friday night and I'll have time for a proper review first thing on Monday.
Thanks!

@mflendrich  do you still want a "proper review" ? If yes, kindly request change, and ignore my approvement.


Add BaseModel class to help auto generate attribute accessors

The BaseModel class is borrowed from our armrest gem. It automatically converts all hash attributes to instance methods. It can preserve named list of hash attribute from being converted. So far I don't know which attributes need to remain as hash.
With this work module InstanceMethods is no longer needed.
Note:
Group#inventory_id now is Group#inventory
Host#inventory_id now is Host#inventory

@bdunne @syncrou Please review.

:+1:  LGTM - Except in regards to the removed inventory_id attribute for Group, Host - I thought the app was expecting a return on that method. If not - I'm set.

@syncrou If inventory_id is already used in manageiq app, then we need to update manageiq also. Or we can add back inventory_id method.

@bzwei Should we extract MiqHashStruct to more_core_extensions and use it as a superclass for BaseModel?  I think that would simplify the code in BaseModel.

@bzwei I'm still stuck on AnsibleTowerClient::Host#inventory.class returning Integer rather than AnsibleTowerClient::Inventory.

@bdunne @syncrou Update: attributes that appear in the related field will be treated as ids. So job_template, inventory, cloud_credential, project etc will be automatically appended with _id.

@bdunne @syncrou please review and merge.

@bzwei - :+1:

@bzwei I think this PR is getting much closer.  I still think we should split BaseModel into:

BaseModel with an initialize method that filters what attribute methods should be defined and
its underlying ReadOnlyHashStruct

Does anyone else have an opinion? @Fryguy @gmcculloug @syncrou

Also, If BaseModel is split, the ReadOnlyHashStruct can do something very similar to MiqHashStruct using method_missing and respond_to_missing? to hit:[].  I think that will simplify the code a lot and remove the need for the instance_eval and define_method lines.

@bdunne the nice thing with this implementation is that it is more like a real class. You can call #methods(false) to get all new methods it added based on the hash.


Added italian translation

Hello @potatoru,
i'm Alessandro from Italy. I took the liberty of adding the entire Italian translation via JSON, bypassing Weblate. I also added the correct flag (country-flag-icons) and included the it entry for pointing in the LocaleArray array. Have a nice day! :)

Nice nice nice! Thanks!


[BUGFIX] Don't add condition as post_filter

When displaying product streams with a custom selected set of articles, always all available filters show up in frontend, not only the matching for the current result.
The ES documentation says about post_filters:
"The post_filter is applied to the search hits at the very end of a search request, after aggregations have already been calculated"
When the ProductStream Query is build, the CategoryId gets overwritten by the shop root category. In this case the Query can result all articles of the current shop. To only show selected articles in productstream the post_filter was added with the selected set of article numbers.
So ists better here to add the condition as "base condition" and not as "normal" condition.

Thanks for your PR @oliver-schulz.
This issue has already been fixed with commit 4bc22936cc1497065ca41177c6c6ae13086a6a1c.


Bugfix - Fixed getCompleteNamespace being too greedy.

Hello
getCompleteNamespace in FileParser was being too greedy and also matching use statements that ended in the class searched for. For example:
namespace SomeNamespace;

use \MyMailer;

class Mailer
{
    /**
      * @return Mailer
      */
   public function foo()
   {
        // ...
   }
}

Here, when alt-clicking the foo method for an instance of Mailer, AutocompleteProvider would return MyMailer because it analyzes the end of the use statement, ignoring whether it is only part of the name or the complete name. This adds a simple check that assumes if the part matched is not preceded by a backslash or a space, then it is not the entire name.
Hope this helps.

In fact, sorry

No problem, bugs happen all the time (I probably also produced some with my pull requests)!


Fixes from Dialyzer

Great! But the changes of no_reply to ok I don't think are right...

You're right. Let me fix those.

It is based on these type specs: https://github.com/tsloughter/gen_leader_zk/blob/master/src/gen_leader.erl#L61-L76


Only load PE imports if they are not already loaded

In the PE loader, add a routine that checks the PEB to look for the base address of imported modules to see if they are already loaded. If they are, use the copy in memory and avoid every calling LoadLibrary for them. This creates the possibility of avoiding generating image load / modload events for each import.

Maybe we would event want to hook LoadLibrary in the PE module so that it performs this logic too when dynamically loading modules?

An option to manually map those dependencies may also be nice. Definitely not something everyone would want, but would ensure you get 0 new modload events as a result of loading a PE. The manual mapping logic already exists in Donut.
Using Module Overloading / phantom DLL hollowing would take that a step further. Though at that point you do get modload events, just for decoy files rather than what you are actually loading. If we did this, the decoy module should be chosen from the list of already loaded modules. So that it looks like LoadLibrary was called on existing modules and doesn't generate any modload events for anomalous modules that the host process has never loaded before.

Keep in mind that if you never call LoadLibrary the reference count of the module will not be incremented and if FreeLibrary happens to get called on it.

@TheWover a simpler solution is just to query the module list everytime you are thinking about doing a load and if the module is already loaded call LdrAddRefDll. You could also potentially manually increment LDR_DATA_TABLE_ENTRY->ReferenceCount which should prevent FreeLibrary from unloading the DLL, however, the loader adds references to the LDR_DDAG (dependency graph) so I'm not sure if this would be 100% stable.

Update: The original idea has been implemented in dev for v1.0. I may implement Dewera's comment and use LdrAddRefDLL. This is a note to myself to try this out before v1.0 release.


Make Zip Builder temp dirs sortable and understandable with timestamp

#no-changelog

Please format before submitting:
ZipBuilder/Sources/ZipBuilder/FileManager+Utils.swift needs formatting.


Failed node pool creates leave behind non-deleteable resources

Describe the bug
When a node pool create fails, the cloudformation stack stucks in an error state and it cannot be deleted with node pool delete. As a result, the same node pool name cannot be reused.
Steps to reproduce the issue:

Create a new node pool with an AMI from a different region
Let it fail.
Try to delete the node pool

Expected behavior
Deleting a failed node pool should succeed.
Additional context
We have no information about how deleting a failed node pool fails.
In the future, we should probably clean up the failed resources. We should decide whether we wait until the process log becomes GA or go ahead and implement the clean up logic. The important thing is to get the error.

There are 3 different sub-issues connected to this problem:

The Create-/DeleteNodePool operations don't propagate their errors up to the cluster status level - this is an oversight in the error handling logic.
The failed CreateNodePool operation fails fast and loud at a point before the node pool would be registered in the Pipeline's domain. Also the failed creation does no cleanup afterwards.
The DeleteNodePool operation on such a failed-to-create node pool is never executed, a 204 No Content response is returned, because the DeleteNodePool operation finds no corresponding node pools to delete in the Pipeline's domain and assumes the node pool was deleted beforehand successfully and thus returns a success indicator without actually doing anything.

Example creation error: (reproducible with an out-of-region AMI ID)
client error: waiting for CF stack create operation to complete failed: stack pipeline-eks-nodepool-pregnor-local-200728-pipeline-3031-2-node-pool-10
pipeline-eks-nodepool-pregnor-local-200728-pipeline-3031-2-node-pool-10 CREATE_FAILED The following resource(s) failed to create: [NodeGroup].
NodeGroup CREATE_FAILED You must use a valid fully-formed launch template. The image id '[ami-064fd810d76e41b31]' does not exist (Service: AmazonAutoScaling; Status Code: 400; Error Code: ValidationError; Request ID: fa5ee299-af41-4edd-ad35-fddab97c7f6a)

Example create retry error: (reproducible with a valid node pool request using the node pool name of a failed-to-create node pool)
could not create 'pipeline-eks-nodepool-pregnor-local-200728-pipeline-3031-2-node-pool-10' CF stack: TokenAlreadyExistsException: The client request token d9e96024-65c7-4c5d-b135-4e3e3c684825-eks-create-asg has already been used for this stack. Retry the request with a different client request token
        status code: 400, request id: 61f4db33-c1c1-41b2-a537-579dfbcdd969

Solution proposal:

The error propagation logic needs to be fixed.
Note: this should also be incorporated into other similar operations where the cluster status error is set similarly.

& 3.
a, either the creation operation has to be made atomic and thus it has to clean up after itself,
- This is also easier if b, is implemented on a lower level - e.g. the operation steps have their inverse operation step defined including failed state handling. 🙂
- Every step of the operation has to handle an error by undoing the previously executed operation steps - at least for steps mutating any resources persisting throughout the parent cluster's lifecycle and beyond.
b, the creation&deletion operation pair has to be made the exact inverse of each other so a (creation + deletion) operation chain is an idempotent operation on the cluster level - for all cases including intermediate failures.
- The deletion should rely on information available from creation start to determine whether any resource deletion is required which can be achieved with an earlier Pipeline domain registration step or it should try deleting resources regardless of their local domain status and should check their existence in other domains or alternatively allow deletion failures due to the underlying resources actually not existing.

The node pool creation should use a client request token which is unique to the operation such as the operation ID.
Note: this should also be incorporated into other similar operations where a client request token is used.
Also the solution for 2.&3. should resolve the second half of this issue.

We discussed this and came to the conclusion that short-term-wise we want to record the failed-to-create node pools as well internally and do the deletion based on that with skip-if-not-exist approach to all node pool resources during deletion of such a failed-to-create node pool.


force list on cors_rule.*.allowed_origins

I seemed to encounter an issue when attempting to pass in a list of allowed origins, this seemed to resolve it.

@osterman @aknysh @goruha can I get this reviewed please?

thanks @renegaderyu
if it is still actual to fix this for TF 0.11, then mention me here and I will create a TF 0.11 branch so you will be able to create a PR agains it. This PR could not be merged to master as it became TF 0.12 now.


SystemError: bad argument to internal function

I'm trying to run pg.leiden() on a matrix with these dimensions:
AnnData object with n_obs × n_vars = 2565988 × 33567

So, about 2.5 million cells.
Here's the error. Do you know what might be wrong? Do you think this might go away if I update pegasus to a newer version?
pg.__version__
'0.17.1'

2020-10-29 10:14:30,081 - pegasus - INFO - Time spent on 'get_neighbors' = 2448.03s.
2020-10-29 10:49:24,745 - pegasus - INFO - Time spent on 'calculate_affinity_matrix' = 2094.64s.
---------------------------------------------------------------------------
SystemError                               Traceback (most recent call last)
<ipython-input-36-39a9c00654b5> in <module>
      7     resolution  = 1.5,            # higher resolution finds more clusters
      8     n_iter      = 5,             # iterate until convergence
----> 9     class_label = "leiden_labels" # store result in data.obs[class_label]
     10 )
     11 adata.obs["leiden_labels"].value_counts()

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasus/tools/clustering.py in leiden(data, rep, resolution, n_iter, random_state, class_label)
    144     W = data.uns[rep_key]
    145
--> 146     G = construct_graph(W)
    147     partition_type = leidenalg.RBConfigurationVertexPartition
    148     partition = leidenalg.find_partition(

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasus/utils/decorators.py in _do(*args, **kwargs)
     37
     38             start = time.perf_counter()
---> 39             res = function(*args, **kwargs)
     40             end = time.perf_counter()
     41

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasus/tools/graph_operations.py in construct_graph(W, directed, adjust_weights)
     41     G.add_vertices(W.shape[0])
     42     G.add_edges(zip(s, t))
---> 43     G.es["weight"] = w
     44
     45     return G

SystemError: /tmp/build/80754af9/python_1565725737370/work/Objects/listobject.c:150: bad argument to internal function

I updated to pegasus 1.0.0 and got the same error.
It seems that Leiden clustering does not work for datasets with too many cells.
Do you know how to work around this? For now, I'll try to see if pg.louvain() is working.
2020-10-29 19:05:32,563 - pegasus.tools.nearest_neighbors - INFO - Function 'get_neighbors' finished in 1964.55s.
2020-10-29 19:44:45,140 - pegasus.tools.nearest_neighbors - INFO - Function 'calculate_affinity_matrix' finished in 2352.58s.
---------------------------------------------------------------------------
SystemError                               Traceback (most recent call last)
~/work/github.com/slowkow/covid/scripts/analysis.py in <module>
    137 )
    138
--> 139 # Nearest neighbors (40 seconds)
    140 ########################################################################
    141 n_knn = int(np.round(np.sqrt(adata.obs.shape[0])))

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasusio/decorators.py in wrapper_timer(*args, **kwargs)
     10                 def wrapper_timer(*args, **kwargs):
     11                         start = time.perf_counter()
---> 12                         result = func(*args, **kwargs)
     13                         end = time.perf_counter()
     14                         message = f"Function '{func.__name__}' finished in {{:.{precision}f}}s.".format(end - start)

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasus/tools/clustering.py in leiden(data, rep, resolution, n_iter, random_state, class_label)
    133     W = data.uns[rep_key]
    134
--> 135     G = construct_graph(W)
    136     partition_type = leidenalg.RBConfigurationVertexPartition
    137     partition = leidenalg.find_partition(

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasusio/decorators.py in wrapper_timer(*args, **kwargs)
     10                 def wrapper_timer(*args, **kwargs):
     11                         start = time.perf_counter()
---> 12                         result = func(*args, **kwargs)
     13                         end = time.perf_counter()
     14                         message = f"Function '{func.__name__}' finished in {{:.{precision}f}}s.".format(end - start)

/projects/kamil/miniconda3/lib/python3.7/site-packages/pegasus/tools/graph_operations.py in construct_graph(W, directed, adjust_weights)
     42     G.add_vertices(W.shape[0])
     43     G.add_edges(zip(s, t))
---> 44     G.es["weight"] = w
     45
     46     return G

SystemError: /tmp/build/80754af9/python_1565725737370/work/Objects/listobject.c:150: bad argument to internal function

I get the same error with pg.louvain()
I can see now that this error is independent of Louvain or Leiden, and it is actually caused by construct_graph() in pegasus/tools/graph_operations.py on line 44.
I'll let you know if I find any way to work around this.
Meanwhile could I ask if you might have any tips?

It turns out that igraph does not support graphs with more than 2 billion edges.
The quickest way to work around this issue is to reduce the number of edges in the graph (e.g. choose a smaller k for the KNN network).

Hi Kamil,
Thanks a lot for your feedback!
Best,
Bo
Bo Li, Ph.D.
Assistant Professor of Medicine, Harvard Medical School
Director, Bioinformatics and Computational Biology Program, Center for
Immunology and Inflammatory Diseases, Massachusetts General Hospital
Associate Member, Broad Institute of MIT & Harvard
149 13th Street, Room 8214, Charlestown, MA 02129
On Wed, Nov 11, 2020 at 12:33 PM Kamil Slowikowski<EMAIL_ADDRESS>wrote:

It turns out that igraph does not support graphs with more than 2 billion
edges.
The quickest way to work around this issue is to reduce the number of
edges in the graph (e.g. choose a smaller k for the KNN network).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/klarman-cell-observatory/pegasus/issues/114#issuecomment-725558202,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACPHRF6ZA6LLS3PBX6AYGLDSPLDGZANCNFSM4TEELRDQ
.

@slowkow , I'll close this issue since it is not a pegasus problem.

@slowkow , I'll close this issue since it is not a pegasus problem.


When returning a call which contains "ETAG" JSON is not parsed correctly

I recently came across an issue where the getResult method parsed the wrong index since it contained an ETAG property in the return. So instead of index[7] it needed to parse index[8]. I check for the existence of [7] then parse [8] otherwise. Not sure if there is a better way to do this, but I figured I should log a ticket.
case "200":                     if (!this.parseJSON(response[7])) {                         return this.parseJSON(response[8])                     }                     else {                         return this.parseJSON(response[7])                     }

Can you give me some detail on what operation you were doing to get the ETAG in the return. I then reproduce it and see if I can come up with a better solution.

This is the call in batch request that actually returns ETAG:
GET https:///_api/SP.AppContextSite(@target)/web/lists(guid'')/items()?$select=<LookupEntityPropertyFullName 1>/Id,<LookupEntityPropertyFullName 1>/Title,<LookupEntityPropertyFullName 2>/Id,<LookupEntityPropertyFullName 2>/Title,/Title,/EMail&$expand=<LookupEntityPropertyFullName 1>,<LookupEntityPropertyFullName 2>,&@target='' HTTP/1.1
Accept: application/json; odata=nometadata


[nrf fromlist] drivers: ieee802154: nrf5: Fix DRX_ADJUST workaround

This PR introduces a fix for DRX window being triggered to early during
CSL. Fixes were also introduced in the nrf 802154 radio
driver, so removed the unneeded DRX_ADJUST constant.
Upstream PR:
https://github.com/zephyrproject-rtos/zephyr/pull/46198
Signed-off-by: Artur Hadasz<EMAIL_ADDRESS>

The following west manifest projects have been modified in this Pull Request:

Name
Old Revision
New Revision
Diff

hal_nordic
https://github.com/zephyrproject-rtos/hal_nordic/commit/a85bb3676d61d1ae202088e0d3fec556056b2c9e (master)
https://github.com/zephyrproject-rtos/hal_nordic/pull/115
zephyrproject-rtos/hal_nordic#115/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

@lmaciejonczyk I've added the change you mentioned on the upstream PR


Always an error when I try to install

I try to install Crest on my laptop for local testing.
I'm running on an Ubuntu 13.10 machine.
I get this error:
# sudo npm install crest -g
.........
npm http 304 https://registry.npmjs.org/extsprintf/1.0.0

><EMAIL_ADDRESS>install /usr/local/lib/node_modules/crest/node_modules/restify/node_modules/dtrace-provider
> node-gyp rebuild

make: Entering directory `/usr/local/lib/node_modules/crest/node_modules/restify/node_modules/dtrace-provider/build'
  TOUCH Release/obj.target/DTraceProviderStub.stamp
make: Leaving directory `/usr/local/lib/node_modules/crest/node_modules/restify/node_modules/dtrace-provider/build'
npm ERR! Error: ENOENT, chmod '/usr/local/lib/node_modules/crest/bin/server'
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR!     <http://github.com/npm/npm/issues>

npm ERR! System Linux 3.13.5-031305-generic
npm ERR! command "/usr/local/bin/node" "/usr/local/bin/npm" "install" "crest" "-g"
npm ERR! cwd /home/artheus
npm ERR! node -v v0.10.26
npm ERR! npm -v 1.4.3
npm ERR! path /usr/local/lib/node_modules/crest/bin/server
npm ERR! code ENOENT
npm ERR! errno 34
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!     /home/artheus/npm-debug.log
npm ERR! not ok code 0

Seems like the crest/bin/server is not even created. I have tried running as root, with sudo and in a local project folder. Same error every time.

Has this issue been resolved ?

Before you execute npm install -g, change in the file package.json:
"server": "./bin/server" to "server": "./bin/crest".
Regards!


Add comments to core transport layer

Many of these files are quite dense with few comments.

I already added a few comments. I am taking this one since I am planning to add more comments


[4.0.0] Elevator model invisible and not interactable.

Expected Behavior
The elevator model would appear.
Actual Behavior
The elevator model was invisible.
Reproduction Steps
Steps to reproduce the behavior:

Make a elevator track.
Create elevator using the Refresher.
Elevator does not show up. Nor is interactable. (It still allows you to configure it.)

Environment

Minecraft Version: 1.20.4
Installed Mods: 4.0.0 MTR Preview Modpack.

I think this is now resolved, can you please verify?

Should be resolved as of latest beta release


gccgo: gccgo 5.0 bin/go does not download transitive dependencies

lucky(~/devel/build) % /opt/gccgo/bin/go version
go version gccgo (GCC) 5.0.0 20150116 (experimental) linux/amd64
lucky(~/devel/build) % /opt/gccgo/bin/gccgo -v
Using built-in specs.
COLLECT_GCC=/opt/gccgo/bin/gccgo
COLLECT_LTO_WRAPPER=/opt/gccgo/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/branches/gccgo/configure --prefix=/opt/gccgo --enable-languages=c,c++,go --disable-bootstrap
Thread model: posix
gcc version 5.0.0 20150116 (experimental) (GCC)

Using a freshly compile version of the go tool packaged with gccgo 5.0, it fails to download transitive dependencies
env GOPATH=/tmp/gopath /opt/gccgo/bin/go get -v github.com/juju/juju/...
github.com/juju/juju (download)
github.com/juju/juju
github.com/juju/juju/api/base
github.com/juju/juju/juju/arch
github.com/juju/juju/network
# github.com/juju/juju/api/base
/tmp/gopath/src/github.com/juju/juju/api/base/caller.go:7:23: error: import file ‘github.com/juju/names’ not found
  "github.com/juju/names"
                       ^
/tmp/gopath/src/github.com/juju/juju/api/base/caller.go:23:21: error: expected package
  EnvironTag() (names.EnvironTag, error)
                     ^
/tmp/gopath/src/github.com/juju/juju/api/base/caller.go:23:16: error: invalid named/anonymous mix
  EnvironTag() (names.EnvironTag, error)
                ^
github.com/juju/juju/rpc/rpcreflect
github.com/juju/juju/cert
# github.com/juju/juju/cert
/tmp/gopath/src/github.com/juju/juju/cert/cert.go:19:24: error: import file ‘github.com/juju/errors’ not found
  "github.com/juju/errors"
                        ^
/tmp/gopath/src/github.com/juju/juju/cert/cert.go:38:14: error: reference to undefined name ‘errors’
  return nil, errors.New("no certificates found")

... lots more output

These failures are because other packages in other repos have not been downloaded recursively as part of the go get process.

lucky(~/devel/build) % /opt/gccgo/bin/go version
go version gccgo (GCC) 5.0.0 20150116 (experimental) linux/amd64

not so lucky. please could you recheck with a recent version? I assume anything past the Go 1.4.2 import on 20150306 would help.

oh dear, I used the branches/gccgo version. Which branch / revision / tag /
unicorn should I try ?
On Mon, Mar 23, 2015 at 9:08 PM, doko42<EMAIL_ADDRESS>wrote:

lucky(~/devel/build) % /opt/gccgo/bin/go version
go version gccgo (GCC) 5.0.0 20150116 (experimental) linux/amd64
not so lucky. please could you recheck with a recent version? I assume
anything past the Go 1.4.2 import on 20150306 would help.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/10217#issuecomment-84927280.

just trunk, or use the package in vivid.
On 03/23/2015 11:16 AM, Dave Cheney wrote:

oh dear, I used the branches/gccgo version. Which branch / revision / tag /
unicorn should I try ?
On Mon, Mar 23, 2015 at 9:08 PM, doko42<EMAIL_ADDRESS>wrote:

lucky(~/devel/build) % /opt/gccgo/bin/go version
go version gccgo (GCC) 5.0.0 20150116 (experimental) linux/amd64
not so lucky. please could you recheck with a recent version? I assume
anything past the Go 1.4.2 import on 20150306 would help.
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/10217#issuecomment-84927280.

Reply to this email directly or view it on GitHub:
https://github.com/golang/go/issues/10217#issuecomment-84931123

I've confirmed the problem still exists on gcc/trunk
lucky(~/devel/build) % env LD_LIBRARY_PATH=/opt/gccgo/lib64 GOPATH=/tmp/gopath /opt/gccgo/bin/go version
go version go1.4.2 gccgo (GCC) 5.0.0 20150324 (experimental) linux/amd64
lucky(~/devel/build) % env LD_LIBRARY_PATH=/opt/gccgo/lib64 GOPATH=/tmp/gopath /opt/gccgo/bin/gccgo -v
Using built-in specs.
COLLECT_GCC=/opt/gccgo/bin/gccgo
COLLECT_LTO_WRAPPER=/opt/gccgo/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/trunk/configure --prefix=/opt/gccgo --enable-languages=c,c++,go --disable-bootstrap
Thread model: posix
gcc version 5.0.0 20150324 (experimental) (GCC)

I just committed Lynn's patch to trunk (
https://codereview.appspot.com/213570043/).  See if you still the problem.
Thanks.
Ian
On Mon, Mar 23, 2015 at 8:16 PM, Dave Cheney<EMAIL_ADDRESS>wrote:

I've confirmed the problem still exists on gcc/trunk
lucky(~/devel/build) % env LD_LIBRARY_PATH=/opt/gccgo/lib64 GOPATH=/tmp/gopath /opt/gccgo/bin/go version
go version go1.4.2 gccgo (GCC) 5.0.0 20150324 (experimental) linux/amd64
lucky(~/devel/build) % env LD_LIBRARY_PATH=/opt/gccgo/lib64 GOPATH=/tmp/gopath /opt/gccgo/bin/gccgo -v
Using built-in specs.
COLLECT_GCC=/opt/gccgo/bin/gccgo
COLLECT_LTO_WRAPPER=/opt/gccgo/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/trunk/configure --prefix=/opt/gccgo --enable-languages=c,c++,go --disable-bootstrap
Thread model: posix
gcc version 5.0.0 20150324 (experimental) (GCC)
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/10217#issuecomment-85320888.

Thanks Ian. I've confirmed that Lynn's fix addresses the go get problem I
was seeing.
Do you think Lynn's fix should be merged into golang/go ?
On Wed, Mar 25, 2015 at 6:51 AM, Ian Lance Taylor<EMAIL_ADDRESS>wrote:

I just committed Lynn's patch to trunk (
https://codereview.appspot.com/213570043/). See if you still the problem.
Thanks.
Ian
On Mon, Mar 23, 2015 at 8:16 PM, Dave Cheney<EMAIL_ADDRESS>wrote:

I've confirmed the problem still exists on gcc/trunk
lucky(~/devel/build) % env LD_LIBRARY_PATH=/opt/gccgo/lib64
GOPATH=/tmp/gopath /opt/gccgo/bin/go version
go version go1.4.2 gccgo (GCC) 5.0.0 20150324 (experimental) linux/amd64
lucky(~/devel/build) % env LD_LIBRARY_PATH=/opt/gccgo/lib64
GOPATH=/tmp/gopath /opt/gccgo/bin/gccgo -v
Using built-in specs.
COLLECT_GCC=/opt/gccgo/bin/gccgo

COLLECT_LTO_WRAPPER=/opt/gccgo/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper

Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/trunk/configure --prefix=/opt/gccgo
--enable-languages=c,c++,go --disable-bootstrap
Thread model: posix
gcc version 5.0.0 20150324 (experimental) (GCC)
—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/10217#issuecomment-85320888.

—
Reply to this email directly or view it on GitHub
https://github.com/golang/go/issues/10217#issuecomment-85666508.

Is there anything left to do here? Seems like it can be closed.


What is the technical foundation of this limitation of the Blender Plugin integration ?

Hardware:
Runs on both GPUs and CPUs. OpenCL 1.2 required for GPUs
AMD graphics cards are recommended
For non-AMD OpenCL 1.2 cards, Windows 10 is required

Hey there.  If you're looking for blender plugin specific questions it might be best to post them here:  http://support.radeonprorender.com/support/home
What OS are you on?

Closing the issue (use Blender forum for Blender-related questions)


⚠ Bofrost.at has degraded performance

In 9b02039, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 2566 ms

Resolved: Bofrost.at performance has improved in 57eafd1 after 10 minutes.


fix for LOCAL_ENGINE_ADDR env var which engine PRs are using for F/E tests

https://github.com/KittyCAD/modeling-app/compare/fix-auth-test-in-engine?expand=1

I fixed this in engine so we no longer need it

Oh thanks!


spring-integration and spring-cloud-stream Greenwich.SR2+ => MessageHandlingException: nested exception is java.lang.ClassCastException: java.util.LinkedHashMap

Context
We are using spring-integration for 2 different instances, a producer and a consumer, and spring-cloud-stream is between them.
We use a single exchange topic (in the broker) to send different payload object types between the two instances.
We experienced the issue when we tried to upgrade from Greenwich.SR1 to SR2/SR3.
2019-10-25 16:15:01.198  INFO 88619 --- [           main] o.s.i.h.s.MessagingMethodInvokerHelper   : Overriding default instance of MessageHandlerMethodFactory with provided one.
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.532 s <<< FAILURE! - in com.skow.common.test.integration.ProducerToConsumerTest
[ERROR] test(com.skow.common.test.integration.ProducerToConsumerTest)  Time elapsed: 0.313 s  <<< ERROR!
org.springframework.integration.transformer.MessageTransformationException: Failed to transform Message; nested exception is org.springframework.messaging.MessageHandlingException: nested exception is java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to com.skow.common.module.model.DTO, failedMessage=GenericMessage [payload={name=name, property={property=property}}, headers={replyChannel=transform.channel, id=346999f9-ee12-4185-211d-a3a74178d77e, REDO_BEAN=replayTransformer, contentType=application/json, REDO_PAYLOAD={name=name, property={property=property}}, timestamp=1572012901198}]
        at com.skow.common.test.integration.ProducerToConsumerTest.test(ProducerToConsumerTest.java:9)
Caused by: org.springframework.messaging.MessageHandlingException: nested exception is java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to com.skow.common.module.model.DTO
        at com.skow.common.test.integration.ProducerToConsumerTest.test(ProducerToConsumerTest.java:9)
Caused by: java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to com.skow.common.module.model.DTO
        at com.skow.common.test.integration.ProducerToConsumerTest.test(ProducerToConsumerTest.java:9)

After analyzing code history, we found the below commit is responsible
diff --git a/spring-cloud-stream/src/main/java/org/springframework/cloud/stream/config/BinderFactoryConfiguration.java b/spring-cloud-stream/src/main/java/org/springframework/cloud/stream/config/BinderFactoryConfiguration.java
index f76535aa..47acf7c4 100644

-       @Bean
+       @Bean(IntegrationContextUtils.MESSAGE_HANDLER_FACTORY_BEAN_NAME)
        public static MessageHandlerMethodFactory messageHandlerMethodFactory(
                        CompositeMessageConverterFactory compositeMessageConverterFactory,
                        @Qualifier(IntegrationContextUtils.ARGUMENT_RESOLVERS_BEAN_NAME) HandlerMethodArgumentResolversHolder ahmar,

Sample project demoing the issue
git clone https://gitlab.com/n3ur0ns/spring-cloud-stream-integration.git
cd spring-cloud-stream-integration
./mvnw clean verify -P IT -fn

We found a trick as shown in submodule greenwich-sr3-trick
@Component
public class OnStartup implements ApplicationListener<ContextRefreshedEvent> {

    private final DefaultListableBeanFactory context;

    @Autowired
    public OnStartup(DefaultListableBeanFactory context) {
        this.context = context;
    }

    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        if (context != null && context
            .containsBean(IntegrationContextUtils.MESSAGE_HANDLER_FACTORY_BEAN_NAME)) {
            context.removeBeanDefinition(IntegrationContextUtils.MESSAGE_HANDLER_FACTORY_BEAN_NAME);
        }
    }
}

@guilloume: Thank you for the thorough write-up and the reproducible sample! I can locally also see this breaking, as well. I'm going to request @olegz to have a look at the change when he's back from the PTO next week.
In the meantime, perhaps you could switch to Hoxton/Horsham RC1 (RC2 later this week, even).  Please give it a go on this release baseline, and let us know what you find out.

I would suggest to try it with 3.0.0.RC2 as I believe that has been addressed albeit indirectly.

Closing this due to no activity.

@sabbyanandan I have a similar issue using Hoxton.SR8(3.0.8.RELEASE)
I have 2 instances and one is a producer, another is a consumer.
I'm using EmiiterProcess<Message<?>> to send a message like below in the producer
    @Override
    public Product createProduct(Product body) {
        LOG.debug(" Sending create product message for product {}", body.getProductId());
        Message<?> message = MessageBuilder.withPayload(new Event(CREATE, body.getProductId(), body)).setHeader(HEADER_DESTINATION, QUEUE_PRODUCT).build();
        processor.onNext(message);
        return body;
    }

In the consumer instance, I'm using the following code to process the message.  The code is broken at the comment line.
@Bean
    public Function<Event<String, Product>, String> handleProductMessage(){
        return message -> {
            LOG.info("Process product message created at {}...", message.getEventCreatedAt());
            switch (message.getEventType()) {

                case CREATE:
                    Product product  = message.getData(); // <--the code is broken here. I can see message.getData is a LinkedHashMap with debugger. It's not a type of Product? why???
                    LOG.info("Create product with ID: {}", product.getProductId());
                    productService.createProduct(product);
                    break;

                case DELETE:
                    String productId = message.getKey();
                    LOG.info("Delete product with ProductID: {}", productId);
                    productService.deleteProduct(productId);
                    break;

                default:
                    String errorMessage = "Incorrect event type: " + message.getEventType() + ", expected a CREATE or DELETE event";
                    LOG.warn(errorMessage);
                    throw new EventProcessingException(errorMessage);
            }

            LOG.info("Message product processing done!");
            return message.getKey();
        };
    }

This issue is closed (almost a year ago). If you believe you have a problem, create new issue providing all the necessary details


AM PM

What is format to add AM/PM ?

Not sure I follow? Durations are periods of time, not particular times that could be annotated as before or after noon. 11 hours, not 11:00 AM. Moment already has extensive date formatting options... check out the docs.


Geotiff String Data Issue

This provides a temporary fix for #236.  We need to bump our node environment because the TextDecoder API apparently does not exist on 10 (12 is the same as geotiff and 13 doesn't have some gl package).

Tested locally, all demos work. Is the tonsil demo expected to look like this? I did not see the tonsil image on the http://viv.vitessce.io/ demo to be able to quickly compare

@keller-mark Yes.  It's an old bioformats pyramid so the edges are a bit wonky.


Update astro version to latest

A new version of astro came out recently. This updates the dependencies to include v5. I played around with this locally and it worked but I'm not sure the best way to test this overall.

Thanks for the PR!


pySBOL remove() method causes Python to crash

It seems like remove() method is crashing Python. Python unittest tests remove functions by executing something like
doc.sequences.remove(0)
and assert an error to be raised when the object is assessed. Has there been any changes to the function making the above expression invalid?

Yes, I introduced the bug.  It's trying to delete a pointer twice.  I'll look into it.

The error occurs only in Python, not libSBOL, and is introduced in libsbol.i line 174.  This is one of those annoying SWIG memory management issues, and will take some time to sort out.  For now I've commented the line out (see 4884ff50d), and the test should pass.  (It will result in a memory leak when calling the remove method, however.)

Related to #140


Wrong risk status after HTTP 901 error

Avoid duplicates

[X] Bug is not mentioned in the FAQ
[X] Bug is specific for Android only, for general issues / questions that apply to iOS and Android please raise them in the documentation repository
[X] Bug is not already reported in another issue

Describe the bug
After HTTP 901 error occurred, risk status was shown as "Unknown Risk" with the detail text "Since you have not activated logging for long enough, we could not calculate your risk of infection".
Detailed error message:
Something went wrong.
Cause:
de.rki.coronawarnapp.exception.http.CwaUnknownHostException: error during web request, http status 901
Expected behaviour
If a network error occurs then the risk status should revert to the previously calculated status if exposure logging has been active long enough.
The risk status should not say that logging has not been activated long enough when in fact logging has been active for more than 14 days.
Steps to reproduce the issue
This may be difficult to reproduce, since it occurred whilst I had a poor quality HSPA+ mobile network connection.

Open CWA with mobile device connected to poor quality HSPA+ mobile network connection
HTTP 901 error was shown followed by status
"Unknown Risk" with the detail text "Since you have not activated logging for long enough, we could not calculate your risk of infection".
Close CWA.
Open CWA with mobile device connected to good WiFi
"Low Risk" with detail sections "No exposure up to now", "Exposure logging permanently active" & "Updated: Today, 03:12"

Technical details

Mobile device: Galaxy A50 SM-A505FN
Android version: 10
CWA: 1.3.0

Internal Tracking ID: EXPOSUREAPP-2587

Hey @MikeMcC399
Thank you very much for your detailed bug description. I double-checked and I found some similar issues related to HTTP 901 but nothing in a manner like you described here.
I have created a Jira ticket and assigned it to the development team.
Internal Tracking ID: EXPOSUREAPP-2587
Best regards,
SG
Corona-Warn-App Open Source Team

Thank you @svengabr !
I have added the following to the original issue, since I managed to reproduce the issue again today and I was able to make a screen shot of the detailed stack trace.

Detailed error message:
Something went wrong.
Cause:
de.rki.coronawarnapp.exception.http.CwaUnknownHostException: error during web request, http status 901

Hey @MikeMcC399 ,
could you please update to the latest version and test again? In case it is obsolete please let me know.
Thank you very much!

Hi @svengabr
I can't simulate the bad network connection at the moment. There was one particular place out in the country at a lake where the mobile data reception was unreliable and I could reproduce the problem at will. Due to lockdown I won't be at that place anytime soon again unfortunately 😞. I am currently in the city and I have perfect WiFi and mobile network connection here, so no chance to reproduce.
I will close the issue to give priority to other issues with reports from multiple users. If I see the issue happening again with a current CWA version I will re-open.

Hi,
afaik the error could occur again for other users anytime when DNS is (temporarily) not available, and iirc CWA still handles this situation only by throwing an exception.
@BMItter , is this something you could take care about in your planned work (error handling)?

@vaubaehn
It would be great if you could reproduce this.
I tried by setting the DNS server on my mobile connection to the loopback address <IP_ADDRESS>. I also tried disconnecting the WiFi router from the remote network.
I could only get the situation where the CWA log waited first, then went to the risk screen after a delay, or where everything worked without delay and without an error message. I couldn't force the error.

@MikeMcC399
It can make a difference if you set DNS to loopback or take wifi off internet, as the hardware would return a 'target not available' immediately.
In case of a bad connection or a firewall (depending on how firewall handles it) the packets containing the DNS request just get 'lost'. The 901 error might solve itself with a bad connection due to the prolongued timeouts in newer CWA versions, but still might be relevant  where time for timeout is not long enough or using a firewall (#785).
Tonight I'm too tired to set up anything, maybe end of next week.


Cannot contribute on fresh clone

I followeed the exact instructions for contributing, but when I run "npm run dev", I get the following:
[!] Error: Unexpected token (Note that you need plugins to import files that are not JavaScript)
[0] client/craft/index.tsx (16:4)
[0] 14: const ContentProviderBase: React.FC = ({ data, standaloneServer }) => {
[0] 15:   return (
[0] 16:
[0]         ^
[0] 17:
[0] 18:
Also, I get the following on the server afterwards:
bundles server/index.ts → build/server...
[0] created build/server in 4s
[1] node:internal/crypto/hash:71
[1]   this[kHandle] = new _Hash(algorithm, xofLen);
[1]                   ^
[1]
[1] Error: error:0308010C:digital envelope routines::unsupported
[1]     at new Hash (node:internal/crypto/hash:71:19)
[1]     at Object.createHash (node:crypto:140:10)

It seems there could be something broken with imports. It works on my system atm but I'll be trying a clean install in a bit to verify.
There's also a failing build that I missed https://github.com/LiveDuo/destack/actions/runs/4317946271/jobs/7535646291.

@kronos-999 Update: After a clean install I get the error the first time. Then after running the command again the error goes away.
What seems to happen:

The Next.js example project needs the Destack editor CSS to function
The CSS is dynamically generated with rollup and the tailwindcss plugin and does not exists at first
The example project the first time it started could not found the CSS and throws that error

@kronos-999 In the master branch the ArrowUpTrayIcon looks commented out Header.tsx#L73, if you see an error something maybe rollup is ignoring the comments or you checked out on a different branch. Lmk whether the case to look it up.
When you run npm run dev twice it should compile. That's with either npm or nnpm (I haven't tested pnpm though), at least on my machine it does, the first time fails to load the CSS and the second it compiles sucessfully.

It seems that the example projects that are used for dev are not importing destack correctly.
Looking into them I noticed that destack is not imported at all in their package.json files. This I guess depends on how npm workspaces work and I'd like to look into it somehow but I can't reproduce it on my machine.
Maybe if destack is imported in the example projects it will work.
ie. in ./dev/nextjs-project/package.json
"dependencies": {
+    "destack": "file:../../lib/",
    "next": "^10.2.3",
    "react": "^17.0.2",
    "react-dom": "^17.0.2"
  },

Hey @kronos-999,
Glad that it works now. We spend quite some time ironing out bugs over the last few weeks.
I've reproduced the issue locally. For more context, I was aware that something was off with text-transparent Tailwind class but didn't notice that component.
Maybe create another Github issue specifically for this bug?


chore(ecopass-kit): added dpp-tutorial  & dpp-verification to the KIT adoption view

Description
There was missing the DPP Tutorial to be linked to the KIT. It was presented in the Second Tractus-X Community Days and it is really valuable for easing the adoption of the KIT.
I also added the dpp-verification documentation so that people can easily read more about the concept in the Digital Product Pass Verification Add-on Section.
Pre-review checks
Please ensure to do as many of the following checks as possible, before asking for committer review:

[X] DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
[X] Copyright and license header are present on all affected files

Sorry @danielmiehle and @catroest but I need your approval again...

LGTM but since the content was changed an adaptation of the change log might be needed

Ok i will also add the change log


feat: external connection and clusters

@mcollina I'm not able to test clusters right now. Could this be enought anyway?

I would rebese this


[BUG-python/deployment] remove listeners from  required dependencies argilla[listeners]

Describe the bug
The requirements file contain listeners as a required extra for argilla. https://github.com/argilla-io/argilla/blob/develop/argilla/pyproject.toml
Stacktrace and Code to create the bug
N.A.
Expected behavior
N.A.
Environment:

Argilla Version [e.g. 1.0.0]: 2.0.0rc1
ElasticSearch Version [e.g. 7.10.2]: NA
Docker Image (optional) [e.g. argilla:v1.0.0]: 2.0.0rc1

Additional context
NA

@burtenshaw, what are your thoughts here? For me, it is weird to enforce all extras of 1.x

or bump typer dependency

relates to the listeners relying on CLI, which requires typer https://github.com/argilla-io/argilla/issues/5104

@frascuchon @davidberenstein1957 I agree that pip install argilla[v1] seems to solve most the problems and frees up the new SDK in the short term.
However, over the coming releases, I would also be in favour of deprecating v1 modules. Which would also reduce this problem if we deprecated their dependencies too. For example, training or listening.