check_copyright.py is broken for existing files

The general guidance I've always received from lawyers (and from places like http://www.copyright.gov/eco/help-publication.html) is that if you're updating a source file, don't increase the year of copyright notices, since the copyright applies to when the source file was first committed, and doesn't refresh/extend just because some minor change is made to it (which would permit indefinite copyright extension!).
check_copyright.py is demanding that copyright years cover the current year (e.g. #5041). It's fine for the year of the notice to be extended (e.g. 2015 -> 2015-2016), but it's unnecessary, and leads people to change instead of extend it (e.g. 2015 -> 2016), which is wrong.
@ejona86 @dberlin @ctiller

@dsymonds: have you verified that the tool does not catch mistakenly-changed-instead-of-extended bugs? If it lets such mistakes slip by, it certainly shouldn't and that's a bug that should be fixed no matter what the policy on extension is determined to be.

It didn't stop me at the time and I don't think we have any reason to believe it has been fixed. That actually seems harder for the tool to implement since it has to compare history.

Here's the short version:
Unless you plan on people using this code in 100+ years (literally), and
you want to sue someone in 100 years over it, don't worry about updating
the copyright years.
On Wed, Feb 3, 2016 at 3:39 PM, David Symonds<EMAIL_ADDRESS>wrote:

The general guidance I've always received from lawyers (and from places
like http://www.copyright.gov/eco/help-publication.html) is that if
you're updating a source file, don't increase the year of copyright
notices, since the copyright applies to when the source file was first
committed, and doesn't refresh/extend just because some minor change is
made to it (which would permit indefinite copyright extension!).
check_copyright.py is demanding that copyright years cover the current
year (e.g. #5041 https://github.com/grpc/grpc/pull/5041). It's fine for
the year of the notice to be extended (e.g. 2015 -> 2015-2016), but it's
unnecessary, and leads people to change instead of extend it (e.g. 2015
-> 2016), which is wrong.
@ejona86 https://github.com/ejona86 @dberlin
https://github.com/dberlin @ctiller https://github.com/ctiller
—
Reply to this email directly or view it on GitHub
https://github.com/grpc/grpc/issues/5051.


Add search field or typeahead on the main page

@IvdL22  @PixlTracer  Here I'm adding the new idea which came up during the meeting today:
On the main page, where the overview of all the courses is listed, a search field or typeahead could be added to make it easier for users to search for a course and improve the user experience.

Searchbar

Searchbar with results

yes!! 🥳
looking forward to this feature!!

@PixlTracer  @IvdL22
Can you please fix the name of this course: https://dhcr.clarin-dariah.eu/courses/view/389
The name contains the character "  which causes the course to be shown on top of search results instead of sorted after other courses, which start with B
Please write a line when it's fixed.

@IvdL22 I have fixed it but forgot to do it in production. Does that pose a major problem?

@IvdL22 It doesn't cause a problem. It just means you have to do it again ;) (now in production), because:

Production is what is shown to the public
Production DB is leading, which means it's copied from time to time to test and dev and the data there will be overwritten.

Can you write a line here when it's fixed?

(the course name specified above is fixed)

The required unique on course name and institution have been implemented.
Development finished.
Implemented in 2023-04.
@IvdL22  @PixlTracer  Can you review this new feature?
Note: Before releasing this version into production, we need to solve all the conflicts in the production database, as addressed here: https://github.com/acdh-oeaw/dhcr-main/issues/59#issuecomment-1538053009

@patrickakk Tested the feature and it seems fine.

Waiting for the conflicts of course names to be solved (see above), then this issue can be closed.

commented in issue 59; for consistency I am pasting my thought on the search bar here again:
when using the search bar, a user is entering certain keywords - why not output a list (similar to when applying filters) of all the courses that match the keyword? so we don't need to check the course-names for their uniqueness...
very much looking forward to the deployment of the new feature!

@PixlTracer

when using the search bar, a user is entering certain keywords - why not output a list (similar to when applying filters) of all the courses that match the keyword? so we don't need to check the course-names for their uniqueness...

I'm not sure which part of the application you mean. Is it the main page where the new search bar is visible? Here: https://test-dhcr.clarin-dariah.eu/
Currently the you can search in both course name and institution name or a part of it. Can you explain what you mean?

@IvdL22 @PixlTracer
All conflicting course names are changed/solved. As well I've added the course type to the searchbar, because there are courses with identical course name and institution name, that only can be distinguished by having the course type added.
The result can be found here:
https://test-dhcr.clarin-dariah.eu/
A nice test case could be to search for "Digital Humanities - Universität Basel", since this didn't work before.
Can you review this and change the label to Done if satisfied?

@patrickakk It works fine, much appreciated!

Implemented in 2023-04.


rapidjson missing from tarball

Hi,
just found out about this project and immediately wanted to try it. (NB: the wiki links to github.com/jacobdufault/cquery instead of this repo for building cquery, is this on purpose?)
Anyhow, I downloaded the 20180203 tarball and unpacked it. Then I did:
$ ./waf configure --prefix=$HOME/software/cquery/20180203
#all green stuff
'configure' finished successfully (37.134s)

However the build step failed as rapidjson was not found:
$ ./waf build --prefix=/home/steinbac/software/cquery/20180203
Waf: Entering directory `/scratch/steinbac/software/cquery/cquery-20180203/build/release'
[ 1/77] Compiling src/queue_manager.cc
[ 2/77] Compiling src/messages/cquery_vars.cc
[ 3/77] Compiling src/include_complete.cc
[ 4/77] Compiling src/clang_utils.cc
#...
In file included from ../../src/include_complete.cc:1:
In file included from ../../src/include_complete.h:3:
In file included from ../../src/language_server_api.h:6:
../../src/serializers/json.h:5:10: fatal error: 'rapidjson/document.h' file not found
#include <rapidjson/document.h>
         ^~~~~~~~~~~~~~~~~~~~~~
1 error generated.

I didn't see it listed as an dependency here. So I am wondering if it was not included in the tarball.
Looking forward to trying this project.

I see now that jacobdufault/cquery contains the dependencies as submodules. Then I suggest to make a note in the Build wiki about this or create a project like cquery-pack under cquery-project which is the single point of access.

Can you please update the wiki? src Tarbell is created by github releases
and it requires git submodule update --init
On Feb 7, 2018 00:15, "Peter Steinbach"<EMAIL_ADDRESS>wrote:

I see now that jacobdufault/cquery
https://github.com/jacobdufault/cquery contains the dependencies as
submodules. Then I suggest to make a note in the Build wiki about this or
create a project like cquery-pack under cquery-project which is the single
point of access.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/cquery-project/cquery/issues/433#issuecomment-363690438,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZaQjy69PGitpO9SgxjTaDK1tbmUXmoks5tSVujgaJpZM4R8TDm
.

submodules are not included in github releases tarballs and I don't know how to delete "Source code" on the release page. If you do want to use the github releases tarball,
git clone  https://github.com/miloyip/rapidjson third_party/rapidjson
git clone ...... ......
.......


Add installation assets for macos in release note

Summary

Current release note have just linux binary. So in the macos, we need to clone the git and build it.
It is very difficult in non-developer.
What if we provide the ability to create deb packages that can be installed on macos?
Problem Definition

Proposal

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

I'll change the way to support macos binary.
I think it would be nice to make single binary as using static libwasmvm library.
So I tried about building wasmvm static library and find the way, So I register the PR as https://github.com/Finschia/wasmvm/pull/115.
And then, I'll try removing the libsodium since we will not use libsodium through https://github.com/Finschia/ostracon/pull/652.
And then, finally, I'll try building single binary as using static libraries.


Submit Button does not take to next Challenge.

Challenge http://freecodecamp.com/challenges/waypoint-use-hex-code-to-color-elements-white has an issue. Please describe how to reproduce it, and include links to screenshots if possible.
After completing the challenge, the 'Submit Button' does not take user to the next Challenge

Unable to reproduce: http://screencast.com/t/5vsPIym3W

Usually reloading the page, or clicking on the button multiple times fixes the issue.

I've noticed that it usually takes a few seconds before the "submit" button works.

Yes, we've had a bunch of issues filed for this.  It seems that you currently need to hit the button twice, but it does work.
Closing this, but please reopen if this is not resolved for you.


bug: React component types created with createControllerComponent and createOverlayComponent don't support refs.

Bug Report
Ionic version:

[x] 4.11.4
Current behavior:

For any of the component types created with createControllerComponent or createOverlayComponent, the typing is such that you cannot pass them a ref. As an example, the following code:
const alertRef = createRef<HTMLIonAlertElement>();
<IonAlert ref={alertRef} />

Produces an error like this when compiled by Typescript:
Type 'RefObject<HTMLIonAlertElement>' is not assignable to type 'string | ((instance: { overlay?: HTMLIonAlertElement | undefined; isUnmounted: boolean; componentDidMount(): Promise<void>; componentWillUnmount(): void; ... 8 more ...; refs: { ...; }; } | null) => void) | RefObject<...> | null | undefined'.
  Type 'RefObject<HTMLIonAlertElement>' is not assignable to type 'RefObject<{ overlay?: HTMLIonAlertElement | undefined; isUnmounted: boolean; componentDidMount(): Promise<void>; componentWillUnmount(): void; componentDidUpdate(prevProps: AlertOptions & ReactControllerProps): Promise<...>; ... 7 more ...; refs: { ...; }; }>'.
    Type 'HTMLIonAlertElement' is missing the following properties from type '{ overlay?: HTMLIonAlertElement | undefined; isUnmounted: boolean; componentDidMount(): Promise<void>; componentWillUnmount(): void; componentDidUpdate(prevProps: AlertOptions & ReactControllerProps): Promise<...>; ... 7 more ...; refs: { ...; }; }': isUnmounted, componentDidMount, componentWillUnmount, componentDidUpdate, and 6 more.  TS2322

Expected behavior:
These components should accept a ref.
Steps to reproduce:
See the code above.
Related code:
The createComponent function is used to make most of the React components, and it returns the result of a call to createForwardRef based on the class it has defined.
The createOverlayComponent and createControllerComponent functions return the component class directly. I am definitely not an expert, but it seems like they should be changed to work the way createComponent does w.r.t. the ref.

insert short code snippets here

Other information:

Ionic info:

Ionic:

   Ionic CLI       : 5.4.4 (/usr/local/lib/node_modules/ionic)
   Ionic Framework : @ionic/react 4.11.5

Capacitor:

   Capacitor CLI   : 1.3.0
   @capacitor/core : 1.3.0

Utility:

   cordova-res : not installed
   native-run  : not installed

System:

   NodeJS : v12.12.0 (/usr/local/Cellar/node/12.12.0/bin/node)
   npm    : 6.11.3
   OS     : macOS Catalina

fixed in 4.11.6


Quality Categories deserves its own file - not in Developer Guide

This section is quite long and not really on the same topic as the rest of the developer guide. I think this is a good candidate to be Quality Categories Guide page in addition, in the contribution section.

@SteveMacenski you're right, that section doesn't belong in the developer guide, it's just there until the associated REP is released, which will be in a week or two.
This PR will get rid of it


Use different formatter for different currency

Fixes #424 , #1204  .
Before, the Calculator will use CurrencyFormatter per system locale for all currencies.
So, users cannot input USD with fraction digits in Japanese locale, because JPY doesn't allow fraction digits.
Description of the changes:

Allow to use different formatter for different currency

By adding m_currencyFormatter1, m_currencyFormatter2

How changes were validated:

Functional UI tests added

Seems I cannot add currency functional test because it only has "Jupiter - Gas Money" in ComboBox in CI

Seems I cannot add currency functional test because it only has a fake currency in CI.
Any suggestions?

Seems in CI the Calculator doesn't have full currency list?


Enter the workspace container: aliases.sh syntax error

Description:
When I enter to the workspace container, I get this error:
$ winpty docker-compose exec workspace bash
bash: $'\r': command not found
bash: $'\r': command not found
bash: /root/aliases.sh: line 119: syntax error near unexpected token `$'{\r''
'ash: /root/aliases.sh: line 119: `function mkd() {

Expected Behavior:
No error :-)
Context information:
Output of git rev-parse HEAD
89c9cfe09941bead05d63ec3c0fe9b9173ce0526

Output of docker version
Client: Docker Engine - Community
 Cloud integration  0.1.18
 Version:           19.03.13
 API version:       1.40
 Go version:        go1.13.15
 Git commit:        4484c46d9d
 Built:             Wed Sep 16 17:00:27 2020
 OS/Arch:           windows/amd64
 Experimental:      false

Server: Docker Engine - Community
 Engine:
  Version:          19.03.13
  API version:      1.40 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       4484c46d9d
  Built:            Wed Sep 16 17:07:04 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          v1.3.7
  GitCommit:        8fba4e9a7d01810a393d5d25a3621dc101981175
 runc:
  Version:          1.0.0-rc10
  GitCommit:        dc9208a3303feef5b3839f4323d9beb36df0a9dd
 docker-init:
  Version:          0.18.0
  GitCommit:        fec3683

Output of docker-compose version
docker-compose version 1.27.4, build 40524192
docker-py version: 4.3.1
CPython version: 3.7.4
OpenSSL version: OpenSSL 1.1.1c  28 May 2019

System info: Mac, Windows or Linux. Include which disto/version
Windows 10 Pro, build 19041.572

Steps to reproduce the issue:

docker-compose up -d nginx mysql workspace phpmyadmin
 winpty docker-compose exec workspace bash

Stacktrace & Additional info:
All files are unmodified.

Have the same issue. This is somehow related to windows line endings (CRLF) in aliases.sh. After manually changing CRLF to LF in aliases.sh and rebuilding and restarting the workspace container, the issue disappeared. CRLF in *.sh files is never a good thing. Why don't we add a .gitattributes file to the repo, so we could control that all *.sh files are checked out with LF, regardless of the local settings on user side. Following configuration could the trick:
*.sh		text eol=lf

@xsepption Thanks! It's worked for me.


Update prerequisites.md

Added M365 Business premium as well to the document

@JohanFreelancer9 Please copy review

issue#https://github.com/MicrosoftDocs/microsoft-365-docs/issues/2237

@jaimeo Please merge this PR. Thanks.

I'll be glad to once I have review/signoff from a Microsoft Managed Desktop SME.

SME advises this is incorrect.


OpenTracing / Context propagation support

As suggested by @jeffschoner-stripe and @drewhoskins-stripe, I am creating a github issue to discuss the topic of context propagation for the Ruby SDK.
Tracing Proposal
Why
Distributed applications are more difficult to measure and debug due
to the distributed nature of their processing. One cannot simply
attach to the running process with a debugger and capture state
since that state may be spread across multiple processes or systems.
Temporal, by its nature, is distributed. Any application written using
Temporal will also be distributed. In order to trace through the
behavior of the business logic implemented as workflow(s) and
activit(ies) we should provide support for OpenTracing and other
related tracing mechanisms.
The Java, Go, and Typescript SDKs all support OpenTracing today via
context propagation. The Ruby SDK can support Tracing today without
any changes merely by allowing the programmer to pass the Tracing
context as an argument to every workflow and activity. This is sloppy
and error prone, so we should mimic the facilities exposed by the
aforementioned SDKs and allow the context to propagate automatically
using the Temporal headers.
What
This defines the interface for passing in OpenTracing contexts to
the Temporal system. Upon configuration, the propagation of this
information should be automatic and transparent to the programmer.
Aside from initial configuration, methods should be exposed on
the workflow and activity that allow for adding to the existing
(if any) context.
Workflow Configuration
Will fill this out in next edit... thinking about it.

Related issue:
https://community.temporal.io/t/opentracing-integration/3771


[gdal] Fix tiff & zstd

try fixing regressions in #27928

I don't like what I see in gdal. For some reason gdal is not doing its own find_package(ZSTD)
opened https://github.com/OSGeo/gdal/issues/7040

Upstream GDAL accepted the alternative patch which is in #28839.


Bump Dependencies #1323781082

Bumps dependencies for product-is. Link : https://github.com/wso2/product-is/actions/runs/1323781082

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.jenkins-is-staging seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Swap PWM channel argument to pass by reference

Swap PWM channel arguments to be passed by reference to alleviate need for cloning / reconstructing channel objects per #244

r? @therealprof
(rust_highfive has picked a reviewer for you, use r? to override)

yeah absolutely, just figured i'd get the ball rolling on this one

This PR changes the channel arguments into shared references, not mutable ones. I think this is a mistake.
The only method where taking a shared reference makes sense, in my opinion, is try_get_duty. All others make changes to the channel, at least semantically speaking (enabling/disabling it or setting its duty cycle). I think accepting a shared reference for these is wrong for the following reasons:

Only having a shared reference might be inconvenient when implementing this method. An implementation might want to call methods on the PwmPin implementation that require a mutable reference.
It could restrict how implementations can use borrowing to express valid/invalid use of the API. Usually having a shared reference to something means that something can't be modified elsewhere. If I want my HAL API to work like that, there's no way to enforce this, if my Pwm implementation allows users to do everything to a PWM channel using a shared reference.
It is not in line with other traits in this crate, which use mutable references to express what semantically changes the referenced type, and what doesn't.

The only method where taking a shared reference makes sense, in my opinion, is try_get_duty. All others make changes to the channel, at least semantically speaking (enabling/disabling it or setting its duty cycle). I think accepting a shared reference for these is wrong for the following reasons:

i would pose the argument that the associated channel types are only index into the pwm peripheral, and that it's not the channel that is being mutated but the peripheral. This is where the state resides, the peripheral is a singleton where the channel indexes are not, and this is already specified in the API with &self and &mut self on the peripheral?
fn try_disable(&mut self, _: &Channel) -> Result<(), Self::Error> { unimplemented!() }
/// #     fn try_enable(&mut self, _: Channel) -> Result<(), Self::Error> { unimplemented!() }
/// #     fn try_enable(&mut self, _: &Channel) -> Result<(), Self::Error> { unimplemented!() }
/// #     fn try_get_duty(&self, _: Channel) -> Result<u16, Self::Error> { unimplemented!() }
/// #     fn try_get_duty(&self, _: &Channel) -> Result<u16, Self::Error> { unimplemented!() }

i would pose the argument that the associated channel types are only index into the pwm peripheral, and that it's not the channel that is being mutated but the peripheral.

I would totally agree with that reasoning, if Pwm was the only trait here. But we also have PwmPin, and while the relationship is not explicit, it makes sense to implement PwmPin for the type that is also used for Pwm::Channel. If that's the case, then you'd need a mutable reference to the PwmPin implementation to set the duty cycle via PwmPin::try_set_duty, but only a shared reference to the PwmPin impl to set it via Pwm::set_duty_cycle.
You don't have to do it that way, of course. Pwm::Channel and PwmPin could be totally different types. But that doesn't make a whole lot of sense to me. My interpretation from the previous paragraph is the only one that does make full sense to me right now: Pwm is a timer that can generate PWM signals. It can have multiple channels with different duty cycles, that all run on the same period (as defined by the timer). HALs can decide to implement PwmPin for these channels, to make it possible to set the duty cycle for each channel from different locations.

Now that I've written all of this, I'm thinking that the whole design may be sub-optimal. It's likely I'll provide a more detailed proposal later, but for now, how about this idea:

Remove PwmPin
Split Pwm into separate traits: pwm::EnableChannel, pwm::Period, pwm::DutyCycle
Keep the Pwm trait as a supertrait that only defines Self::Channel

Then implementations can mix and match, to suit the hardware capabilities and their own design. They can implement all those traits for a single timer type, or additionally decide to provide the applicable implementations for each channel type too (with Self::Channel being set to () in that case).

You don't have to do it that way, of course. Pwm::Channel and PwmPin could be totally different types.

all good points! i think the split PwmPin case is interesting, it seems to me that to get PwmPin objects you would need to .split() a Pwm into types that contain a reference back to the initial Pwm (which the Channels cannot really contain)? otherwise you have both a Pwm implementation that can set outputs, and non-primitive Channel objects that can also do this but cannot easily be constructed or thrown around (something like Pwm::set_duty_cycle(Channel::A, ...) becomes, difficult, as does genericising over Channel = u8 or similar).
i am unsure about dropping PwmPin but your suggestions seem reasonable to me. i do wonder whether the Pwm case would be better represented with a channel index and an associated constant for the number of available channels because, the arbitrary channel type is going to make abstracting over a PWM instance much more difficult for a hypothetical PWM consumer.

all good points! i think the split PwmPin case is interesting, it seems to me that to get PwmPin objects you would need to .split() a Pwm into types that contain a reference back to the initial Pwm (which the Channels cannot really contain)? otherwise you have both a Pwm implementation that can set outputs, and non-primitive Channel objects that can also do this but cannot easily be constructed or thrown around (something like Pwm::set_duty_cycle(Channel::A, ...) becomes, difficult, as does genericising over Channel = u8 or similar).

First, a quick note: You'd typically want to implement such splitting by consuming the PwmPin impl and using unsafe register access internally in the Pwm impl (protected by critical sections, if necessary). A reference will make you very unhappy as soon as you want to move anything to another context (whether through RTIC or a plain static), so I strongly recommend against it.
Otherwise, I do agree with that paragraph, except that it made me realize another weirdness: If acquiring the PwmPin impls consumes the Pwm impl (or makes it inaccessible through references), then you can no longer use its methods (of course). But you also can't use its methods before that, because you don't have the PwmPin implementations yet.
Maybe I'm just not seeing how this API is meant to be implemented, but the more I think about it, the more I believe it needs a thorough redesign.

i am unsure about dropping PwmPin but your suggestions seem reasonable to me. i do wonder whether the Pwm case would be better represented with a channel index and an associated constant for the number of available channels because, the arbitrary channel type is going to make abstracting over a PWM instance much more difficult for a hypothetical PWM consumer.

Yes, good point. Maybe it would be best to just drop Channel completely. That would remove some flexibility in how to implement these traits, but that would probably a good thing.
I have an ongoing project that will need PWM traits soon (soon being relative; it's a side project and I'm busy with paying work). I'm currently thinking that, if I can't make the current traits work for my needs, it might be best if I create an embedded-pwm crate to replace the traits in embedded-hal. That would allow for some rapid iteration and eventually, everything could be merged back into embedded-hal.

I now believe that most of what I said has been wrong. I've summarized my insights for everyone who's interested, but as far as this PR is concerned, I now believe this should be merged as-is (and ideally released as alpha.3 soon).
@therealprof To be clear, by "converted example" you're referring to a HAL implementation that is updated to use these modified traits?

i had a quick go at modifying @eldruin's pwm-pca9685-rs but, this doesn't currently use the pwm traits, it's p difficult to map them to the operation of this particular device, and patching to e-h 1.0.0-alpha.2 causes a bug in cargo 🙃

Yeah, sorry about that. I have been meaning to implement the pwm traits in the pwm-pca9685-rs crate but did not find time yet.

I implemented the modified trait in LPC8xx HAL: https://github.com/lpc-rs/lpc8xx-hal/pull/292
Implementations (very ugly, for reasons unrelated to this PR): https://github.com/braun-embedded/lpc8xx-hal/blob/pwm-ryankurte/src/ctimer/peripheral.rs#L569-L768
Usage example: https://github.com/braun-embedded/lpc8xx-hal/blob/pwm-ryankurte/examples/ctimer_blink.rs#L55-L84
I don't have a generic driver that uses these traits yet, and won't have for at least a few weeks.

ahhh also i wonder whether it important that we're eliding phase at the moment? often you setup a PWM with a specific on and off count (across multiple channels), rather than just a period, for things like BLDC control

Setting the phase is actually the way to configure the PWM for the PCA9685. There you just configure for each channel channel when it goes on and when it goes off with numbers in the range of [0-4096] (4095 + full on, actually).

Good point about the phase. I suggest handling that in a follow-up PR though. This one already is a clear improvement as-is and I'd like to see it merged rather sooner than later.

@therealprof are you happy with @hannobraun's implementations of this? worth note that we've gone for a shared reference rather than a mutable one (following a bunch of discussion on #256)

I haven't checked. I trust @eldruin expertise here.

Ach, @ryankurte could you run rustfmt?


[core] reduce large history memory consumption by dereferencing...

...commit info objects as early as we can

This will be resolved globally for all search requests in a new PR for the next minor release.


Error building examples: requirements not found

Fresh clone on Darwin MacBookPro.local 19.6.0 Darwin Kernel Version 19.6.0: Tue Nov 10 00:10:30 PST 2020; root:xnu-6153.141.10~1/RELEASE_X86_64 x86_64, receiving the error when running
$ ./build-examples.sh
##
# Building examples
##

- header-and-footer
./build-examples.sh: line 16: pdftoppm: command not found

Would be great if you could add pdftoppm as necessary requirement (or dev-requirement). In fact, it is poppler that packages pdftoppm for macOS.
How to satisfy the requirements should be then easy to figure out by everyone e.g., sudo port install poppler or brew install poppler
Then later, after installing poppler, there's a new unmet requirement:
Could not find executable pandoc-latex-environment

So, to the rescue comes
$ pip install pandoc-latex-environment

and then everything works. Luckily

The documentation definitely needs some improvement regarding on how to build everything yourself.


Add erase_send_sync_owner to create Erased + Send + Sync references

I ended up needing this when adding thread safety to rustc. I'm not sure why the IntoErased trait is unsafe, so it would be a good idea to check that I didn't break any invariants here.

Did you check whether Erased impls Any? That's the only potential unsafety I noticed.

@Storyyeller dyn (Erased + Sync + Send) cannot impl Any.


feat: addition of Redis as cache implementation

this Implement doesn't covert all the methods.
A ValueMapper interface has been added to let the cache user define how to convert the value object as a String managed by Redis.
NOTE: For some reason the reactive client is not working inside the plugin and lead to a NoClassDefFoundException on the Redis client whereas the non reactive "RedisClient" is working.
related-to AM-3476

Gravitee.io Automatic Deployment
🚀 A prerelease version of this package has been published on Gravitee's private artifactory, you can:

use it directly by updating your project with version: 6.1.0-am-3476-redis-cache-SNAPSHOT
download it from Artifactory here

:tada: This PR is included in version 6.2.0 :tada:
The release is available on:

6.2.0
GitHub release

Your semantic-release bot :package::rocket:


Fix TM2 cache states to removed deleted caches

Fixes /publish/CacheStates endpoint to not return cache states which
are in the history, but have been removed from the CRConfig (and
hence from localstates and peerstates).

This also fixed Traffic Ops' rascalstatus, which pulls from CacheStates without regard for CrStates, and hence will get duplicate, old data for any caches moved from one CDN to another.


[Discussion][Data Complement] Data complement and workflow execution type combos make users confused

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description

Currently in DolphinScheduler, there are four different  process execution types and two different data complement mode. Therefore, there will be 4 * 2 = 8 different combos when it comes to workflow data complement, which could be confusing for users.
We could remove useless combos and elaborate the different behaviors of each combo in docs.

Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

haha, good catch for you


Breaking change in Microsoft.Common.targets (UseSymboliclinksIfPossible)

This is introduced in #742. We (community contribution!) added support for symbolic links on the Copy task. I just happened to be looking into an issue with Xamarin targets and stumbled upon an issue.
In Microsoft.Common.CurrentVersion.targets we now call Copy like:
<Copy
    SourceFiles = "@(_SourceItemsToCopyToOutputDirectory)"
    DestinationFiles = "@(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')"
    OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
    Retries="$(CopyRetryCount)"
    RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
    UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
    UseSymboliclinksIfPossible="$(CreateSymbolicLinksForAdditionalFilesIfPossible)"

I don't see any problem with this in general. However, the Xamarin targets (specifically iOS are the targets I'm looking at) add <UsingTask TaskName="Microsoft.Build.Tasks.Copy" AssemblyFile="Xamarin.iOS.Tasks.dll"/>. This causes all Copy tasks to use the one from Xamarin.iOS.Tasks.dll rather than the builtin. Unfortunetely, this Copy task derives from Microsoft.Build.Tasks.v4.0.dll which does not have the new UseSymboliclinksIfPossible property.
It seems like we have a few options. 1) Fix Xamarin targets to bind to a more recent version of MSBuild (Microsoft.Build.Tasks.Core). This would have implications as to what version the target could run on (MSBuild 14+) but would be preferable if that's ok. 2) Modify the targets to not specify the property unless it's set. This seems like it could be pretty ugly. Or 3) find a way to turn on this feature in a backwards compatible way?
@kzu do you have any input on this? Is option 1 something you could do?

Another option would be to add a property with this name to the Xamarin override. It could be ignored--it just has to exist. That would be backward compatible since you can always add an optional property and it'll just get a default value.

Yes, but the problem with that @rainersigwald is that the local-side of the build would not have this new feature, since we'd continue to inherit from the 4.0 task.
We can implement a mix of option 1 and 3:

Move the tasks that override the built-in ones to two assemblies: Xamarin.Build.Tasks and Xamarin.Build.Tasks.Core, with the latter inheriting from the 14+ ones.
Conditionally declare the Using depending on the MSBuildToolsVersion being >= than 14
Declare the property in the pre-14 Tasks assembly so that they are no-op and "just work" (do nothing) on pre-14 builds (i.e. xbuild)

How about we change the common targets to something like this, to allow old and new behaviour. Xamarin msbuild code can make sure CreateSymbolicLinksForAdditionalFilesIfPossible is turned to false
<Copy Condition="'$(CreateSymbolicLinksForAdditionalFilesIfPossible)' == 'true'"
    SourceFiles = "@(_SourceItemsToCopyToOutputDirectory)"
    DestinationFiles = "@(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')"
    OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
    Retries="$(CopyRetryCount)"
    RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
    UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"
    UseSymboliclinksIfPossible="$(CreateSymbolicLinksForAdditionalFilesIfPossible)"

<Copy
    SourceFiles = "@(_SourceItemsToCopyToOutputDirectory)"
    DestinationFiles = "@(_SourceItemsToCopyToOutputDirectory->'$(OutDir)%(TargetPath)')"
    OverwriteReadOnlyFiles="$(OverwriteReadOnlyFiles)"
    Retries="$(CopyRetryCount)"
    RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)"
    UseHardlinksIfPossible="$(CreateHardLinksForAdditionalFilesIfPossible)"

@cdmihai that was option 2 and is super ugly as there are quite a few call sites to consider. I don't think that's a very reasonable option :(.
@rainersigwald suggestion seems good. Xamarin task can have that property (public bool UseSymboliclinksIfPossible { get; set; } that does nothing. This would solve the issue completely and is probably the least impactful. The task could still inherit from 4.0 and be fine since it will technically have the property. You could also have the set throw if set to true so if someone expected to use it they would know they could not. @kzu this seems like it could be the option that would have the least impact on mono msbuild as well since it would still be the v4.0 dll.

@AndyGerlicher my concern is that we'd be breaking symlink behavior on Xamarin projects so people won't be able to leverage it at all, even for targets that don't involve remotely building on the Mac (i.e. you can still use Copy on Windows only if you add a Condition=" '$(BuildSessionId)' == '' " for example. But maybe it's too much of a corner case.
We can fix it with the given suggestion, and wait for users to ask for the additional support if needed.

PRs on their way at https://github.com/xamarin/xamarin-macios/pull/648 (master) and https://github.com/xamarin/xamarin-macios/pull/649 (cycle8 / next dev15 drop)

@kzu is there a build I could try and verify the fix?

@AndyGerlicher not yet, likely tonight or early tomorrow


Jenkinsfile updates

Please have a look at the individual commit messages for the details.

Reminder, should be merged after #2847.

Actually, this can (and should, in its current state) be merged before #2847. That's because the evaluator is the only build step for which this adds "UNSTABLE" support, and the evaluator already returns status code 2 for unstable. PR #2847 just extends that idea also to the analyzer and scanner CLI tools, but this PR does not support "UNSTABLE" for the analyzer or scanner build steps.


Handle OGG audio files

Looks good.
Was ogg support needed because of the format recorded on wrathspriter?

Precisely!


Streamtime module

Adds a !streamtime command to Wololobot that displays a countdown to the next stream.
Times for the streams are fetched from a Schedule panel in the stream description. It is identified by either having the title 'Schedule' or an image (identified by the schedImage option passed to the module).
The output of !streamtime can also be overwritten by mods:

!streamtime overwrite <msg>: The output is overwritten with <msg>. If <msg> contains the string $iftime{...}, the part ... is output if there is a stream scheduled. If <msg> contains $time, that is replaced with a countdown to the next stream.
!streamtime overwrite_time YYYY-MM-DD hh:mm [AM|PM] [timezone]: Overwrites the time of the next stream.
!streamtime overwrite_discard: Discards any overwrites (messages and times)

By default, the streamtimes are updated every 5 minutes. An update can be forced with !streamtime update.

Sweet :eyes:


refactor code to ease maintenance

Is there any part of the code that this PR tries to improve that I'm missing? Would you like to share upfront the reasons for the refactors, so I might be able to see the same as you.

Well, while unifying the lexers, I duplicated many functions. For example consume_whitespace_ from consume_whitespac, consume_url_ from consume_url. This PR eliminates such duplication and it is a subtask to integrate the get_next_token and consume functions which I find share more or less the same logic.

sad, but I will rebuild it better in the future when resources are adequate.


fix azure stale vmp and add ci tests

Description
This PR fixes stale vmp issue on Azure when VMs are deleted from the cloud, VM CRs are deleted, or EE CRs are deleted. This PR also adds CI tests to check stale vmp removal.
Changes

Generate correct vm name when removing stale member.
CI test to check vmp removal after vm selection changes.

Signed-off-by: Alexander Liu<EMAIL_ADDRESS>

/nephe-test-e2e-all

/nephe-test-e2e-eks
/nephe-test-e2e-azure
Retry due to test setup failure

/nephe-test-e2e-azure

/nephe-test-e2e-kind, /nephe-test-e2e-eks


Generic button interface

I've put a generic button interface type in place of our attempts at a generic button implementation since it was not adding anything. This way we can define higher order components that you can plugin any component that fits the button interface to.


GCJ-02 coordinates

Do you have plans to adapt/augment the system to handle cases where WSG-84 is not permitted in the local jurisdiction, such as China (which uses GCJ-02 coordinates)?
Reference: https://en.wikipedia.org/wiki/Restrictions_on_geographic_data_in_China#Coordinate_systems

No, no plans.
As long as the input values are between -90 to 90 and -180 to 180, then you could use any coordinate system - as long as it is agreed between whoever is encoding the location and whoever is decoding the location.
But our recommendation is that a plus code should be based on WGS-84, since it is vastly more likely that any system you use a plus code with is going to assume the decoded values are WGS-84.


Fix steps reading on Windows

cat is not available, so use type which does the same thing.
r? @larsbergstrom
I spent about ~10 seconds searching for this, but it looks like it'll work...

This change is

@bors-servo r+

:pushpin: Commit 7be34e6 has been approved by larsbergstrom

Cool, I'll roll it out and push to the servers and retry something after this. No queue to speak of right now, so not creating a huge backlog yet :-)

:hourglass: Testing commit 7be34e6 with merge be66cf9...

This passed Travis. Merging so I can roll it out.


Add a man page

Lagrange should come with a Unix manual page that explains CLI usage, including descriptions of the options.
This could be partially merged with the built-in Help document.

8c36de3d076f35a6f78bd89f5b312dd92950e0bc adds a Pandoc-generated man page.


Niivue + ONNX clientside

Goal:
The clientside enables users to perform image preprocessing using niimath (output as NVImage for other computation) and execute a segmentation model (output drawings). Users can refine and improve ROI labels for model training.
Features
Navbar

File : Upload images, Download drawing/image in the current canvas
View: Clip plane, Radiological, Crosshair, Show colorbar, Colormap
Opacity and Intensity range stay more explicit for their frequent use.

Canvas:
I find multiplanar view more useful but having them all in one canvas seems to be difficult to get the slice coordinates.
Computing

Preprocessing: niimath takes DT_UNSIGNED_CHAR for the datatype of input array (I checked an example in niimath repo, it says to support dataypes 2,4,16. I didn't get 4 and 16 to work but I dont think it's an issue https://github.com/rordenlab/niimath/blob/f644a9738ed1f014acd39818dae153f7a6f225e3/src/niimath.js#L91)
Pretrained Model (WIP): SAM encoder takes Float32 dims array, the decoder takes Float32 + click coord + few more inputs and output Float32 array.
If possible, when user selects axial view, it gets all the slices in that view and passes to the encoder (might be very laggy as the encoder is 10 times larger than the decoder). It seems possible to have efficient multiple computations using web worker. To get the model output in the canvas as drawing for refining, when clicking on the canvas, the decoder then get the mask for all the slices (so we have 3d output).
I have some issues that need your advice @neurolabusc or others in the team:

I think @shrutivarade has a smart solution to get 2d image data from canvas context so the coordinates from mousedown event makes sense. But can we somehow use the mouse coordinate to get the image slice? I think there might be something like that for draw function.
The model needs row major order array but it seems that NVImage buffer is column major array?

Potential UI

@stebo85 @haehn

@iishiishii , Thanks for opening this issue. I think I understand what you're after. I don't think it makes sense to bundle all of this into NiiVue (I'm not sure if you were suggesting that, but just thought I'd share the thought).
NiiVue is a library for parsing and viewing medical imaging data in modern browsers using webgl2.0. We have a focus on brain imaging since that's the field many of the developers work in.
As you point out, NiiVue can be extended to work with our WASM niimath module for preprocessing, but that module is not bundled in by default. The two modules are peers, but one does not depend on the other.
I think we should use that same approach when thinking of interacting with ONNX models. We can probably add features to NiiVue that make it easier to interact with user specified ONNX models, but the "glue" that connects NiiVue to the model could be handled by the developers that import NiiVue into their projects.
I think a first pass at getting NiiVue to interact with an ONNX model like the one you describe would be to add some helper functions that allow sending and receiving slice data to/from the model code.
Perhaps when interacting with segmentation models like this, developers can activate an empty drawing by default, and then as the model outputs new data, the relevant slices in the drawing can be updated to display results overlaid on the background image.
Does your proposed model accept 3D inputs, or only 2D?

@iishiishii  these are great points, and I think your mock up looks great. I would suggest:

We add core functions and call backs that make reading and writing data to NiiVue simpler and more interactive with mouse gestures. I can take the lead on this.
I would suggest you develop a modular component for ONNX that wraps NiiVue, in the same way that we have an example of niimath WASM linking with NiiVue. I have invited you to be a member of the NiiVue team, and would invite you to make a new project in the NiiVue tree (though you can keep it in your own organization if you prefer).
I think it would be great if we could work with @haehn and @FarfallaHu, @Mmasoud1  and @sergeyplis of the brainchop with their impressive Papaya-based livedemo. It would be nice if we could come up with a clean API for a lot of these interactions.
I do hope we can provide the correct hooks and interactions to do everything as one WebGL2 canvas. This will require less resources and make it easier to auto-adapt to different screen sizes like computers and phones.

Thanks for starting this discussion! We suggest enabling the following 3 core functionalities in niivue:

Data Read Access

to retrieve image (+segmentation) data as chunks similar to numpy slicing
if possible, different data types and array order should be supported but i think it is fine if not since this could be done outside of niivue

Interaction Access

especially placement of seeds/selection of ROI by easily enabling the built-in widgets

Data Write Access

to add image and segmentation layers back to the niivue scene with proper re-drawing etc.
this could later be expanded to fibers, mesh overlays etc.

Such a generic API would allow processing independently of ONNX.js or any other framework (Tensorflow.js...) and enable flexibility for developing external plugins.

@haehn thanks for creating a concrete set of features and milestones. I am happy to work on the NiiVue side of this, and create minimal live demo examples that your team and the neurodesk team can exploit.

Hello! Regarding the previous discussion about the API and new requested features, we have a JSdoc as an overview of the functionality:
/**
 * @param x1 {int, null} the bbox start x coordinate, if null, set to 0
 * @param x2 {int, null} the bbox end x coordinate, if null, set to volume dimension
 * @param y1 {int, null} the bbox start y coordinate, if null, set to 0
 * @param y2 {int, null} the bbox end y coordinate, if null, set to volume dimension
 * @param z1 {int, null} the bbox start z coordinate, if null, set to 0
 * @param z2 {int, null} the bbox end z coordinate, if null, set to volume dimension
 * @param normalized {bool} to return original voxel range or 0..1
 * @param datatype {Uint8Array, Float16Array…, null} the encoding of the voxels, if null, the original encoding
 * @param orientation {String, null} if ‘RAS’ or ‘LPS’ honor this or return niivue ‘RAS’ standard if null
 * @returns {Array} The subvolume data within a range of specified coordinates.
 */
nv.get_volume_data ( x1, x2, y1, y2, z1, z2, normalized, datatype, orientation )

 /**
 * @param x1 {int, null} the bbox start x coordinate, if null, set to 0
 * @param x2 {int, null} the bbox end x coordinate, if null, set to volume dimension
 * @param y1 {int, null} the bbox start y coordinate, if null, set to 0
 * @param y2 {int, null} the bbox end y coordinate, if null, set to volume dimension
 * @param z1 {int, null} the bbox start z coordinate, if null, set to 0
 * @param z2 {int, null} the bbox end z coordinate, if null, set to volume dimension
 * @returns {Array} The label data for the specified subvolume as an array.
 */
nv.get_label_data(x1, x2, y1, y2, z1, z2)

These functions will allow for retrieving both volume data and label data. Thanks for being open to integrating the new functionalities.

It seems like normalized as a bool is too limited. Consider a 16-bit image based on a 12-bit ADC where voxels have intensity range of 0..4095, but the user has adjusted the cal_min and cal_max to be 24..1024 (e.g. window center = 524, window width = 1000). It seems like the options are:

raw (0..4095)
rawNormalized (0..4095 -> 0..1)
rawWindowed (24..1024 -> 0..1)

When the user chooses normalized, the output is the full dynamic range of the datatype, or the full positive dynamic range. Consider the user wants the values normalized but with null (native) datatype where the data was INT16 (full dynamic range -32768..32767) - is the expectation that the result scales 0..1 to 0..32767 (positive 15 bits) or the full 16-bit -32768..32767?

We would suggest using the full range but are happy to listen to the community here.

@gaiborjosue, do you expect that niivue will be responsible for any resizing prior to inputting the extracted subvolumes into a model? Perhaps we should leave that up to model creators, or have it as a processing step outside of niivue.
For example, if a subvolume has dimensions 512, 512, 1 (a single slice from a CT head image loaded in NiiVue), but the model expects 2D slices with dimensions 128, 128, 1, where will the resize operation happen? Model? or as an extra step? does that make sense? or is it a non-problem?

Hello @hanayik, in our opinion, it should be up to the model creators. Thanks!

The NiiVue live demo page now includes a "Machine Learning and AI helper functions" section with three live demos:

label voxel clusters identifies connected components which is useful for cleaning up machine learning labelling. It uses the createConnectedLabelImage() function.
The conform live demo ports the FreeSurfer/FastSurfer conform function to pure JavaScript. It uses the new conform() function.
The slab selection demo is most relevant to this issue. This demonstrates howw to clone an existing volume or create a new volume from scratch. It shows how one can read and write either all or parts (slabs) of a voxel based volume. The key new functions are getVolumeData and setVolumeData.

The getVolumeData() and setVolumeData() provide an easy way to read and write slabs of voxels. The X,Y,Z coordinates for selecting the row, columns and slices are always specificied in RAS coordinates, regardless of the order of data as stored on disk.
Happy to get any feedback on these new experimental features. Since we are open to feedback, do be aware that these new function calls may be changed in upcoming stable releases.


[ci] Create canaries in Azure Artifacts

Creates a downloadable tarball for @material-ui/core. It's more of a maintainer gimmick to check out PR builds.

Wanted to include the link in the mui-pr-bot comment but Azure has no API to get a link to an Artifact file. Only the whole Artifact is available and then only in zip format and guess what: yarn doesn't support zip.
Ultimate goal was to create a codesandbox with the latest build on a PR but that is blocked by https://github.com/codesandbox/codesandbox-client/issues/1570

Got an idea.


Elemental lords missing units

https://www.hiveworkshop.com/threads/firestarter.203949/

one of these for tidal lord, tidal lord model goes to neptulon
https://www.hiveworkshop.com/threads/ancient-elemental.154825/
https://www.hiveworkshop.com/threads/great-elementals.306956/


Add capability to server static web content from Observer

As discussed offline, we need a way to serve static web
content (e.g., an html page with some js and css files)
for the prototype in the WebView of Talk37.
Running a separate Python server would be a little awkward.
Using the existing Observer application is a convenient
solution.
The newly created StaticWebServer.cs is a simple server that
serves static content from a fixed local directory
(${USER_HOME}/speakfaster-webui).

Fixes #90

Per side discussion, going to move to a gcloud static site.


[Feature] Shampoo optimizer

Problem (Why?)
need Shampoo optimizer
Solution (What/How?)

[x] implement Shampoo optimizer
[x] implement matrix_power() with new API

Other changes (bug fixes, small refactors)
nope
Notes
version to 0.5.0

Codecov Report

Merging #55 (dd81eb5) into main (51fdbce) will increase coverage by 0.16%.
The diff coverage is 98.34%.

@@            Coverage Diff             @@
##             main      #55      +/-   ##
==========================================
+ Coverage   93.63%   93.79%   +0.16%
==========================================
  Files          27       28       +1
  Lines        1884     1950      +66
==========================================
+ Hits         1764     1829      +65
- Misses        120      121       +1

Impacted Files
Coverage Δ

pytorch_optimizer/version.py
0.00% <0.00%> (ø)

pytorch_optimizer/base_optimizer.py
95.77% <75.00%> (-1.33%)
:arrow_down:

pytorch_optimizer/__init__.py
100.00% <100.00%> (ø)

pytorch_optimizer/adabelief.py
96.22% <100.00%> (-0.07%)
:arrow_down:

pytorch_optimizer/optimizers.py
100.00% <100.00%> (ø)

pytorch_optimizer/shampoo.py
100.00% <100.00%> (ø)

pytorch_optimizer/utils.py
95.34% <100.00%> (+0.28%)
:arrow_up:

pytorch_optimizer/adahessian.py
58.06% <0.00%> (-0.45%)
:arrow_down:

pytorch_optimizer/sam.py
94.44% <0.00%> (-0.11%)
:arrow_down:

... and 15 more

Continue to review full report at Codecov.

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


Minor fix in the Customize the look-and-feel documentation

Hey, I just made a Pull Request!

Just a tiny fix in the following page: https://backstage.io/docs/getting-started/app-custom-theme#using-your-custom-theme.
"Note that your list of custom themes overrides the default themes. If you still want to use the default themes, they are exported as themes.light and themes.lightdark from @backstage/theme."

:heavy_check_mark: Checklist

[ ] A changeset describing the change and affected packages. (more info)
[x] Added or updated documentation
[ ] Tests for new functionality and regression tests for bug fixes
[ ] Screenshots attached (for UI changes)
[x] All your commits have a Signed-off-by line in the message. (more info)

Thanks!


DnD addon: specify a resizing step distinct from the calendar step

Clear and concise description of the problem
We wish to be able to resize events with a small step, such as 5 minutes. However, when setting the step prop to such a value, the table gets too large to fit properly on a screen, even when using the min and max props to trim empty space.
Suggested solution
We propose adding a resizingStep prop to DnD calendars, which would override the step prop for resizing when set.
Alternative
No response
Additional context
We are considering the adoption of react-big-calendar in Indico to replace the current legacy timetable.
Validations

[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

Would you like to open a PR for this feature?

[X] I'm willing to open a PR

Closing this because we realized that using timeslots in conjunction with step allows us to acheive this


Application works on Ubuntu, but errors on MAC & WINDOWS

My application uses socket.io. I created the package using pkg .
During packaging, i got below warning
Warning Cannot include native addon into executable.
  /apps/pinger/web/node_modules/raw-socket/build/Release/raw.node
  The addon file must be distributed with executable.

After the package is created, I got 3 executables create (one each for Linux, Windows, MacOS).
Executable works great on Linux (Ubuntu 14.04). But fails to run on Windows & MacOS. I get below error.
buffer.js:821
    throw new RangeError('Index out of range');
          ^

RangeError: Index out of range
    at checkOffset (buffer.js:821:11)
    at Buffer.readInt16LE (buffer.js:956:5)
    at evalmachine.<anonymous>:0
    at Object.Module._extensions..node (evalmachine.<anonymous>:0)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.require (module.js:497:17)
    at Module.require (evalmachine.<anonymous>:0)
    at require (internal/module.js:20:19)

Hi! Please read https://github.com/zeit/pkg/issues/104


FancyZones stops working at system boot up until its disabled and re-enabled again

Microsoft PowerToys version
0.45.0
Running as admin

[X] Yes

Area(s) with issue?
FancyZones, FancyZones Editor
Steps to reproduce
Everytime system boots up, FancyZones even though its enabled doesnt work anymore. i.e, if I hold Shift, and move a window, zones are not activated. I have to disable FancyZones, then re-enable it again. At that point, the layout goes back to default settings. I then have to use Layout Editor to set the layouts I want again
PowerToysReport_2021-09-20-07-23-27.zip
.
✔ Expected Behavior
Zone activation should work at system bootup without having to disable, re-enable FancyZones.
❌ Actual Behavior
Zone activation does not work at system bootup without having to disable and then re-enable FancyZones.
Other Software
OS is Windows 10 1909 build 18363.1734

Looks like this is a duplicate of #13069

Thank you for reporting!
I'll close the issue as a duplicate of https://github.com/microsoft/PowerToys/issues/13069.


Remove windows v1 runtime

Closes #3094
Signed-off-by: Michael Crosby<EMAIL_ADDRESS>

@crosbymichael - You will have to disable CI for now I think

Ok, I"ll keep working on this and get it into a good shape

@jterry75 is there any other way to get this running without disabling the tests?

Codecov Report

Merging #3439 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #3439   +/-   ##
=======================================
  Coverage   44.11%   44.11%
=======================================
  Files         124      124
  Lines       13760    13760
=======================================
  Hits         6070     6070
  Misses       6759     6759
  Partials      931      931

Flag
Coverage Δ

#linux
47.87% <ø> (ø)
:arrow_up:

#windows
39.76% <ø> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

What needs to happen to re-enable the integration tests on Windows CI? Is that something we would plan to have in place by 1.3?

I think to do that we have to start using the containerd-shim-runhcs-v1.exe from hcsshim. This is the only runtime that is actually supported moving forward. I think I am fine with disabling for now knowing that we will get this shim released

@dmcgowan - Done deal.


Enhancement: Allow local forks to use docker to run dynamodb-local

Morning @mobsense, and wow, thanks for this awesome library, I really enjoyed reading the docs and seeing the approach.
Your check-list for dynamoDB has gone straight onto my list of tools in notion :pray:
Description

Adds docker support for running tests; this boots docker instead of a local dynamo-db for people without Java
Adds a .prettierrc which enforces the documented coding standard in CONTRIBUTING.md

Make sure your code style matches existing code. Soft tabs=4, no trailing spaces etc.

Adds directions for install, build, test, and lint for contributors.

Please, let me know any feedback, and thanks for this tool :+1:
Demonstration

Setup a watcher to see what docker spawns
Run tests
Show docker spinning down afterward

Thanks for the pull request. Let me look it over and get back here.

Overall looks pretty good. Can you think about passing in the DOCKER command line via the env.
AND: sorry to be a pain, could you split the prettyrc into a separate pull request. We try to have each pull request focus on a single feature.

You may need to update to fix the package-lock issue before I can merge.

Yeah, I will pull and rebase onto master, then push :+1:

Thank you!!  I need to build my docker skills and explore deploying using docker vs zip for serverless.  So much to do ... so little time.  Thanks.


Add mc-sgx-dcap-ql crate

Current dependencies on/for this PR:

main

PR #147   👈

This comment was auto-generated by Graphite.


Migrate Advisor plugins to configurable plugin API

Migrate the advisor plugins to use the configurable plugin API. See the commit messages for details.
Breaking change:
The configuration of advice providers has changed, see the diff of reference.yml for examples.
Breaking API change:
The API of the AdviceProviderFactory has changed.

Merged as failing GoModFunTest is unrelated to the change.

Once again this is a breaking change that breaks our plugins. Please add the corresponding tags to the PR.

Once again this is a breaking change that breaks our plugins. Please add the corresponding tags to the PR.

@nnobelis Conventional commits and release notes now supersede PR labels in this regard. Please take a look at the "Breaking Changes" section for a release instead (this time it was not forgotten to mark commits accordingly).

Ah yes true my mistake.
Could we, as a convention, put also something in the PR title so we can have a quick oversight when browsing the Github notifications ?

put also something in the PR title

I'm not a fan of this as it's prone to typos etc., and we already have release notes, PR labels, and a note in the PR's top post; we can't put it just everywhere.


Sol-platform: Remove the '"' and ''' characters from the locale v4

Changes since v3:

Properly unescape the locale string

Ederson, your example should be possible, yes. As well as "I'm good", given that you have the outter quotes.
@cabelitos would you check that?

#1575


Fix up term:[X] term referencing and formatting function

This is the same code as #255 + lower casing as implemented by @opoudjis . (I've reverted them from master)
This functionality is current broken:
Word:

HTML:

PDF:

@w00lf please remember to test functionality on REAL DOCUMENTS when marking a PR ready to merge. As we remember from yaml2text, having specs do not necessarily demonstrate whether things work in real life.

@w00lf for the test sample I ran, see https://github.com/metanorma/iso-34000/pull/1 .

@ronaldtse @opoudjis tested with iso-34000:


Downloading app state should not be possible while disconnected

Steps to Reproduce

Go to https://lightclient.raiden.network/
Click on identicon
Click on Back up state
Click on Download State

Expected Result
Nothing happens, it should be disabled because there is no web3 provider
Maybe a hint/tooltip why downloading state is disabled
Actual Result
Warning modal, which after confirm downloads a state file that contains undefined

Disable download button, if not connected

I just want to add a reminder to also edit the description on the screen for downloading/uploading the state while working on this issue.


Allow statement emphasis to be configured (default: enabled)

I'd like to propose making statement emphasis configurable, since at least in TypeScript (but not JavaScript) it leads to  a lot of emphasis on the screen at once. This may be a language-specific issue outside of the scope of your library, since many tokens that aren't statements are being colored as such (vim colorschemes are foreign to me, so this is the most straightforward way I could find to address the issue. If you know of a better fix I'd love to hear it).
Regardless, this option may still be welcomed by users who wish to avoid emphasis altogether. I briefly considered a broader option to disable all emphasis so that the options don't spiral out of control, but discarded that idea because it is valuable to see emphasized TODO's, which would mean you'd end up with an inverse option to re-enable that.
let g:xcodedark_emph_statements=1 (default)

let g:xcodedark_emph_statements=0

Thanks again for this awesome color scheme. This is my first time using vim-colortemplate, so please let me know if I missed anything, or if you'd prefer another approach; I'd be happy to correct it.

I’ve never used TypeScript, but that highlighting definitely doesn’t look ideal! Could you please tell me what the generally accepted TS plugin is so I can play around with the highlight groups?
I wouldn’t be opposed to adding an option to de-emphasise statements, but there is one problem with your implementation.

You added the code for statement emphasis to _emph
The WWDC colourscheme recently gained support for emphasis settings (meaning it also includes _emph)
The WWDC colourscheme doesn’t have bold statements (i.e. there is nothing to deemphasise)

If you had recompiled the WWDC colourscheme it would have ended up with an unused g:xcodewwdc_emph_statements variable and a meaningless entry in its documentation because emph_statements doesn’t apply to it. I think the only way to solve this is to separate out the code for emphasisation into _emph_funcs, _emph_idents, _emph_types, and finally _emph_statements.

Oh dang, sorry about the WWDC color scheme. I had looked at it in the past and hadn't seen any bold, and so naively assumed it still didn't. My mistake.
As far as plugins go, I think I've stumbled upon the source of the issue: vim-polyglot includes https://github.com/HerringtonDarkholme/yats.vim, which sets let g:yats_host_keyword = 1 by default. Disabling that produces the desired highlighting.
With that, you're free to close this PR unless you still think this option is valuable, in which case I can make the necessary updates.

hadn't seen any bold, and so naively assumed it still didn't

No, your assumption was correct! The only problem is that the statement emphasisation code doesn’t apply to the WWDC colourscheme (specifically because it doesn’t have bold).

Disabling that produces the desired highlighting

Thank you so much for finding this. Initially I disabled it too, but I’ve realised that it is possible to make use of the extra highlighting that let g:yats_host_keyword = 1 provides without highlighting everything as keywords, so now I don’t think there is a need to set that to zero any more. I’ve just pushed some changes that hopefully make TypeScript highlighting more like the languages I’ve specifically added support for.

you're free to close this PR unless you still think this option is valuable

If you would still like to use the deemphasisation even with the new highlighting then feel free to update the PR, but otherwise I don’t think there is much of a need for it, especially since it’s so easy to add custom colourscheme modifications in your vimdrc:
augroup customColors
    autocmd!
    autocmd ColorScheme * hi Statement gui=NONE cterm=NONE
augroup END

If you would still like to use the deemphasisation even with the new highlighting then feel free to update the PR, but otherwise I don’t think there is much of a need for it, especially since it’s so easy to add custom colourscheme modifications in your vimrrc:

The snippet you posted will do just fin, so I'll go ahead and close this. The updated TypeScript support is much better out of the box now anyways; thank you for that :).

Glad I could help :)


Add MarkEdit app

Project URL
https://github.com/MarkEdit-app/MarkEdit
Category
markdown
Description
MarkEdit is a free and open-source Markdown editor, for macOS. It's just like TextEdit on Mac but dedicated to Markdown.
Checklist

[x] Edit applications.json instead of README.md.
[x] Only one project/change is in this pull request
[x] Screenshots(s) added if any
[x] Has a commit from less than 2 years ago
[x] Has a clear README in English

@pahnev Thanks!


Fix bug validating dispute contracts

Will this fix contracts already in effect?

Coverage remained the same at 27.465% when pulling 102d2d972f1f70e9f5da7bb40dcaee9cafd3c6de on dispute into 39851c8f8b8f015ec44cc9d98a06d28914d2df99 on master.

Coverage decreased (-0.002%) to 27.463% when pulling 102d2d972f1f70e9f5da7bb40dcaee9cafd3c6de on dispute into 39851c8f8b8f015ec44cc9d98a06d28914d2df99 on master.


Remove or rename config/initializers/fix_mailer_on_rails_2.3.4.rb

From @benjaminwood on April 10, 2018 21:5
Appears to be a monkeypatch for Rails 2.3.4. Likely not relevant anymore.
Copied from original issue: hintmedia/rigse#18

@emilywatkins can you try removing this file and pushing so CI runs? If the tests pass then we can consider what other validation is needed.

@benjaminwood CI passes!

Cool, thanks for researching this.
@scytacki can you shed any light on what this is/was for? Do you know if it is still relevant/used? If you're unsure we can investigate further.


Refactors the Historical Plugin to Make Use of New Utils Library in Plugin SDK

What this PR does / why we need it

Refactors the Historical Plugin to Make Use of New Utils Library in Plugin SDK
Which issue(s) this PR fixes

Fixes: #
Describe testing done for PR

Special notes for your reviewer

Builds and tested!


Add a Vue frontend framework example

Is your feature request related to a problem? Please describe.
Only have a React example, it would be great (for me at least :)) to have a Vue example
Describe the solution you'd like
Add a Vue.js example to the frameworks page
Describe alternatives you've considered
NA
Implementation ideas
Unfortunately I don't know Vue so need somebody else to do the work
Additional context
NA

This is a fine idea. I am a beginner at both python and Vue and a simple app showing Bocadillo with Vue frontend would be really sweet. It could be as simple as  just hello app or even something like to do list combined with authentication and sqlite DB.
So far I really love the documentation, but I miss that authentication part with multiple possible roles or something that can restrict route access.
Anyway, Bocadillo is something that I really like and love following and reading through on my spare time even though I don't program much. Keep up the good job. Thanks for your hard work.

Very good idea!
I’m not sure there’s any specificity to using Vue/React with Bocadillo (assuming Bocadillo is used to provide a REST API of some sort), but I think just having these examples available for showcase/template is a pretty sensible idea.
I’m a Vue user myself and should have a bit of time available to give this a shot. Might as well turn this into a « Build a todo app with Bocadillo and Vue » blog post aimed at beginners at any of these technologies. :)
Also thanks for the kind words @AkumaBugs! I appreciate it a lot. :) Authentication and permissions are in the roadmap (#100).

So, I've already got a very basic setup over https://github.com/bocadilloproject/vue-example.
I listed a few things I think would be interesting to tackle in the ROADMAP.md file. :+1:

 URL Shortener tutorial (Bocadillo + Vue)

The Vue example repo now features a full-blown URL shortener app including an SQLite DB for storing link hashes! https://github.com/bocadilloproject/vue-example
Demo gif:

It's been added to the frontend guide as well: https://bocadilloproject.github.io/discussions/frontend.html
Let me know what you think, and whether this addresses the initial need. If so, we can mark this a resolved! :tada:

Looks good, thanks for the quick response.  You are spoiling us :smile:


[Snyk] Upgrade org.jetbrains.kotlin:kotlin-stdlib-jdk8 from 1.8.0 to 1.8.10

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade org.jetbrains.kotlin:kotlin-stdlib-jdk8 from 1.8.0 to 1.8.10.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 1 version ahead of your current version.
The recommended version was released 2 months ago, on 2023-02-02.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Superseded as we are already using 1.8.21


Enable e2e tests on helm charts

This PR will enable e2e tests on the helm charts. It will setup kube-prometheus and prometheus-operator and wait until all the pods/containers are in ready state.

Took a loooong time to figure out how to run all this test on helm. I hope the kubernetes charts team provide the helm container image to test ASAP.
I guess this e2e tests are acceptable for now, at least helm will not break after PR.

@gianrubio we're currently in the process of removing the migration(-tests) as they are not necessary anymore as TPRs have entirely been removed from the Kubernetes API in 1.8, so the failure you're seeing won't be occurring anymore.

I thought the error was caused by my changes, I'll wait until the changes are merged :)

Thanks for your patience! We fixed everything, you should be able to rebase and resolve the conflicts and everything should work. As we did a lot of changes I'll keep an eye on the failures here as well though. Also feel free to ping me if you think anything seems fishy.

Code is rebased and everything looks fine!

Nice! Thanks a lot! lgtm


Support spark-compatible bitwise_and & bitwise_or functions

For these two functions, spark expects to use left input type as the result type. But for presto, int64 is always the result type, regardless of input type. So in this PR, we are proposing spark-compatible bitwise_and & bitwise_or functions, with few code changes based on the impl. for presto.

Would you run the fuzzer to make sure this function is well tested?
spark_expression_fuzzer_test --duration_sec 60 --only bitwise_and,bitwise_or
spark_expression_fuzzer_test --duration_sec 600

Just tried. But it seems the test was not truly executed. See below printed info. Let me check further.
velox/_build/release/velox/expression/tests/spark_expression_fuzzer_test --duration_sec 60 --only bitwise_and,bitwise_or
[==========] Running 0 tests from 0 test suites.
[==========] 0 tests from 0 test suites ran. (0 ms total)
[  PASSED  ] 0 tests.

In a follow-up PR, it would be nice to add documentation for Spark functions. See velox/docs/functions.rst

We prefer to have a bulk update on the document in another PR. Thanks!

Just tried. But it seems the test was not truly executed. See below printed info. Let me check further.

Try --logtostderr

Try --logtostderr

With this option, we got massive log. No error was reported. Here is a piece:
I1118 21:09:11.453949 1204181 ExpressionVerifier.cpp:42] 12 vectors as input:
I1118 21:09:11.453953 1204181 ExpressionVerifier.cpp:44] 	[DICTIONARY SMALLINT: 100 elements, 9 nulls], [FLAT SMALLINT: 100 elements, 12 nulls]
I1118 21:09:11.453959 1204181 ExpressionVerifier.cpp:44] 	[FLAT SMALLINT: 100 elements, 9 nulls]
I1118 21:09:11.453966 1204181 ExpressionVerifier.cpp:44] 	[DICTIONARY SMALLINT: 100 elements, 9 nulls], [FLAT SMALLINT: 100 elements, 14 nulls]
I1118 21:09:11.453974 1204181 ExpressionVerifier.cpp:44] 	[CONSTANT SMALLINT: 100 elements, null]
I1118 21:09:11.453980 1204181 ExpressionVerifier.cpp:44] 	[DICTIONARY SMALLINT: 100 elements, 8 nulls], [FLAT SMALLINT: 100 elements, 9 nulls]
I1118 21:09:11.453986 1204181 ExpressionVerifier.cpp:44] 	[CONSTANT SMALLINT: 100 elements, 24567]
I1118 21:09:11.453994 1204181 ExpressionVerifier.cpp:44] 	[CONSTANT SMALLINT: 100 elements, 27284]
I1118 21:09:11.454000 1204181 ExpressionVerifier.cpp:44] 	[CONSTANT SMALLINT: 100 elements, 11909]
I1118 21:09:11.454006 1204181 ExpressionVerifier.cpp:44] 	[DICTIONARY SMALLINT: 100 elements, 7 nulls], [DICTIONARY SMALLINT: 100 elements, 11 nulls], [DICTIONARY SMALLINT: 100 elements, 9 nulls], [FLAT SMALLINT: 100 elements, 8 nulls]
I1118 21:09:11.454015 1204181 ExpressionVerifier.cpp:44] 	[CONSTANT SMALLINT: 100 elements, null]
I1118 21:09:11.454022 1204181 ExpressionVerifier.cpp:44] 	[DICTIONARY SMALLINT: 100 elements, 10 nulls], [FLAT SMALLINT: 100 elements, 7 nulls]
I1118 21:09:11.454030 1204181 ExpressionVerifier.cpp:44] 	[FLAT SMALLINT: 100 elements, 13 nulls]
I1118 21:09:11.454452 1204181 ExpressionVerifier.cpp:79] All results match.
I1118 21:09:11.454459 1204181 ExpressionFuzzer.cpp:704] ==============================> Done with iteration 173073


requests removed from botocore.vendored

PR to resolve Issue #5
Description of changes:
As per blog post.  Vendored version of requests has been removed from botocore.  This PR switches to using the standalone python library of requests.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Thx for fixing! Will push a new version to PyPI.


Fix distance for empty routes

distance used to return 0.0 for empty routes (what the route funcitons return when they can't find any route), but I accidentally made it an error during the switch to use Geodesy.jl.
I've got it set to Inf, because it matches what the route functions return for distance/time, but I'd be happy to switch it back to 0.0 if that's preferable.

It looks like some of these Travis failures are going to persust until nolta/Winston.jl#236 gets into a tagged release.
If there are remaining failures then, following Winston's (.travis.yml) lead on sudo: require and/or xvfb-run may be required.

I'm sorry I'm just seeing this, Sean. I missed the notification.
I like the idea of using Inf, that seems to make sense. 0.0 could be misleading.

Can you walk me through a couple of the travis changes you made?
First, is "julianightlies" no longer a thing? Or does Travis now support Julia as a language and so the repositories are already available?
And did you remove all the installs because they should be coming through now as Winston's dependencies? (This makes a lot of sense, there must have been a reason I was doing this originally.)
I'm worried this is going to break on Travis' new container-based build system, which doesn't give sudo access. This script won't tell Travis that sudo is needed to install some of the dependencies, so it won't run on the legacy build system. (scratch that -- looks like it's still on the legacy system).

Ah, I see. "Julia for Travis-CI is not officially supported, but is community maintained." Cool!
Ok, I understand all the changes now. Disregard my previous comment.

Hi Ted,
I've added an explicit sudo requirement in case the default environment changes. And the previous failures from calling xvfb on the new osx builds have been resolved. Now there's just the segfault on 0.4, which I want to say "seems unrelated" but those words get eaten too often, so when I have time, I'll see if the current repo state triggers the same segfault.
Nightlies are still a thing, but 0.5 is changing so quickly that I don't imagine most packages supporting it for a couple months or so, and with our dependencies it would be tough to keep pushing support upstream for now.

I moved the incomplete travis config update commit to #77, so this PR should be an uncontroversial improvement now.

Thanks, Sean! I've been out of town the last few days, sorry about going silent.

No problem, Ted. I was on the road myself for the last few days and didn't notice.


macOS support

Hello,
I'm trying to use the frames-ios checkout sdk in MacOS, but this dependency of frames-ios doesn't support macOS in Package.swift. Can it be updated to support it?

Hi, sorry there has been ages since you asked this. If you still need this, can you please elaborate on the use case so we can have an internal discussion about it?

Closing this stale issue. Feel free to re-open or open a new one ✌


Change "message" in Get-Credential to mandatory

Revert change from PR #1904

Set "message" to optional is not best practice, from https://msdn.microsoft.com/en-us/library/dd878348(v=vs.85).aspx :
•Each parameter set must have at least one unique parameter. If possible, make this parameter a mandatory parameter.
Set both "message" and "title" to optional open a way to "anonymous" request of credential. That is bad. This provokes writing bad code.

Set "message" to optional also breaks backward compatibility: script running in version 6 will not work in the previous versions if "message" is empty.

Hi @iSazonov, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by Microsoft and real humans are currently evaluating your PR.
TTYL, MSBOT;

Hmm.. I don't understand why tests failed. Please help me.

@lzybkr Please take a look. I think you have been dealing with the iterations of this issue.

I tested these changes in an interactive session and it does not fix #2306, so it seems we assumed incorrectly that making -Message optional introduced that problem.
Did you want to investigate a fix for #2306 before we accept this PR?

Never mind about fixing #2306 - the fix is/will be in #2330.

Clear about #2306. I removed Close #2306.

Did you want to investigate a fix for #2306 before we accept this PR?

Yes, because in #2330 already added test for "It "Get-Credential without parameters" { " - it is unnecessary work.

@lzybkr  I can confirm that changing "message" to mandatory fix #2306!

compile FullCRL with mandatory=true (my fix) - no second prompt
compile FullCRL  with mandatory=false (w/o my fix) - second prompt appear

I tried the changes made by @daxian-dbw - I think it provides exactly the experience we want without making -Message mandatory.
Having a mandatory parameter in a parameter set is a guideline, not a requirement. In this specific case, there are benefits to not making -Message mandatory - one can pass a custom -Title and use the default localized message.
And correct me if I'm wrong, but are there really compatibility issues?  All previous versions of PowerShell support calling Get-Credential with no parameters, #2330 just improves the user experience.

I revoke "compatibility" statement. In previous versions, an user only receives one more question, but a script will work.

Having a mandatory parameter in a parameter set is a guideline, not a requirement

Yes, it is not a requirement but the guide says about best practice for script writer that comes from the best user experience.
But!  I was very conservative. I modeled various combinations of parameters (default and non-default, localized and non-localized) and think that as best practice the script writers will have to specify the message and title in a pair without the requirement that message is mandatory.
So you can dicard the PR. @lzybkr  thanks for great discussion!

Thanks @iSazonov - I really appreciate your attention to details like this, hopefully we'll see more contributions from you in the future.


Trailer header name

Hi, @ioquatix.
Just confused by the usage of trailer headers. RFC names it singular "Trailer" while the constant TRAILER here and TRAILERS here are assigned with plural 'trailers'.
Shouldn't it be "trailer"?

Haha, this is great, it looks like I misread something somewhere. You do appear to be completely correct. Thanks for bringing the issue to my attention. It's kind of odd though because I did test this in Chrome at least it seemed to be working!? Maybe I was just seeing what I wanted.
This is an easy fix to I'll push it now.

Okay, this was fixed across all the gems. Released in async-http v0.56.0 and falcon v0.38.0.


Added plugin system to DC/OS Go CLI.

Based on Brian's PR #1249, this adds Windows support and fixes regarding the architecture of the plugin package.
One thing we have noticed during the tests of this plugin system: the output of the logs on Windows is not the same as on macOS. This is due to Logrus and not our code thus we have not fixed the problem in this PR.

@bamarni We thought about adding the feature now and having @br-lewis adding tests during the rest of the sprint in an upcoming PR. Does it sound OK?

@ArmandGrillet : Sounds good, as long as we consider this as a first prototype which will help us designing and experimenting with the feature. I mean we should still be fine with adjusting the plugin schema / implementation.

I don't think moving the plugin to cobra.Command conversion outside of plugin makes the code better.
The plugin code is somewhat independent of cobra but I think it makes more sense for the code to convert a plugin to a command to belong to the code that's concerned with plugins since plugins aren't really useful except for their ability to be converted into a command, whether cobra or not and it should really be up to the plugin to know how it maps to a command.

@br-lewis : having it in our package means we expose a public method returning instances of cobra commands, cobra becomes part of our API. On the other hand if it's in cmd, cobra isn't exposed, it remains an implementation detail which we can change in the future without worrying of breaking users code.
While I agree that the current state of the code is not optimal (there is probably some shell-out logic which can be moved to the plugin package, so that the cobra commands content stays tiny), it at least doesn't have the aforementioned drawback.

Now squashed, ready for merge 🚀.


refactor: add some type annotations to the stdlib

improves the documentation, imho. I'm not sure the ones for index or rindex are good, but Int? was rejected by the compiler.

Sorry, I vote no against this PR. One of the nicest things about Crystal, what makes it unique, is that you can omit types if you want to. This PR makes things more strict, possibly leading to backwards incompatibility, and in other cases it makes method signatures long and verbose, similar to those of Java and Rust in some cases (like Hash fetch)

Ah, too bad :slightly_frowning_face:
To me types also act as additional documentation.

@asterite  I agree to your argument, but only where it applies. Most of the changes neither are overly verbose or break anything. They just document behaviour. And that's a good thing. Even as an experienced Crystal developer, you might not always recall the exact return types of each method. But sometimes it's important to know them (for example for declaring ivars, or simply debugging).

Let's keep them then, but only when we are sure of the types. For example I would remove the return of Indexable#index

Aiming to annotate all return types isn't good. If you're not sure, or it's complex, leave it off.
This should be documentation of existing implicit types, not restricting them more.

Also it restricts types that might not need to be restricted.

@c-cube Are you still up to continue with this PR? It needs some fixing and conflict resolution.
Otherwise let us know and someone else can take over.

I wasn't aware this was still on the table, but by all means, please, take over :)


XRefsTarget should render components with editing disabled

E.g., FigureTargets expose editable properties, which need to be disabled.

Fixed via #39


Cannot retrieve sub-components of components in graphql?

I have a basic component called SEO, that I have added to a collection called post(s).
Inside this SEO component I also have another component called image, which contains an image field and a text field for specifying alt text. I added this under the key sharedImage
In the admin, I can create a post just fine, and populate all this data. In the gatsby graphql playground, I can obtain my posts, my direct SEO data fields ( metaTitle, metaDescription ) but sharedImage is no-where to be found.
I've cleared gatsby cache with gatsby clean and restarted both strapi and gatsby 10's of times now, and this data is simply not populating. Is there a known issue / limitation with this?

Hi Liam,
Did you deep populate the images in your gatsby-config.js?
Like so, in the gatsby-source-strapi plugin in gatsby-config.js:
... populate: { sharedImage: "*", Testimonial: { populate: "*", }, ... Save and restart Gatsby. Hope it helps.
Cheers, Jacco

Using both:
queryParams: {
    populate: {
        seo: {
            socialImage: "*"
        }
    }
}

queryParams: {
    populate: {
        seo: {
            socialImage: {
                populate: "*"
	    }
        }
    }
}

and:
Removes all the socialimage field from my graphql entirely. (I changed the name from shareImage to socialImage in hopes of kicking it up the arse a bit.

@bureauberg This seems to only be an issue with the fact that my image is a sub component. If I remove the component and add an image field directly to the seo component it works perfectly fine.

Have you tried:
queryParams: {
    populate: {
        seo: {
          populate: {
            socialImage: "*"
          }
       }
    }
}

It is possible. I have components in components in DZ's. Its just mind boggling to write the populate queries...
You can try to "debug" it by calling the REST API yourself with the populate fields. You can see what endpoint is being called by Gatsby when you run develop. Copy/Paste that URL and try to change it to work.

Maybe it's this:
queryParams: {
    populate: {
        // probably you need to put `image: *` here as well if you have an image directly on the post. The default `populate: *` gets removed by using this feature
        seo: {
          populate: 'socialImage'
       }
    }
}

Maybe it's this:
queryParams: {
    populate: {
        // probably you need to put `image: *` here as well if you have an image directly on the post. The default `populate: *` gets removed by using this feature
        seo: {
          populate: 'socialImage'
       }
    }
}

populate: "socialImage" appears to be the solution.
Do you mind sharing how you came to this conclusion, because I couldn't find anything about this in the docs?

Thats a very good question...
I guess I just fiddled around long enough with all the options laid out in:
https://docs.strapi.io/developer-docs/latest/developer-resources/database-apis-reference/rest/populating-fields.html#relation-media-fields
and
https://docs.strapi.io/developer-docs/latest/developer-resources/database-apis-reference/rest/populating-fields.html#component-dynamic-zones
it's a hot mess to get the correct combination going.

Huff finally: https://market.strapi.io/plugins/strapi-plugin-populate-deep

Unfortunately we've since moved to sanity!
On Fri, 16 Dec 2022, 18:03 Charanjit Singh, @.***>
wrote:

Huff finally: https://market.strapi.io/plugins/strapi-plugin-populate-deep
—
Reply to this email directly, view it on GitHub
https://github.com/strapi/gatsby-source-strapi/issues/354#issuecomment-1355329293,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AH2X4DNAHFL76RTD3BDKHZDWNSVF5ANCNFSM6AAAAAARZLPBXE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Thanks for your interest in this project. This plugin is moving into the Gatsby User Collective and this repo will be archived. Please open an issue in that repository, submit a PR if you'd like to see this implemented, or join us on Discord if you have questions!


camelCase to kebab-case

Allow the use of camelCase for css props in js code, and auto-translate to kebab-case where necessary before pushing to the native side.
See https://github.com/nick-thompson/blueprint/issues/13

Yessss! Love it, this is excellent, will merge right away.
Thanks @olidacombe I think people will appreciate this one quite a bit

Now available in<EMAIL_ADDRESS>on npm


Fastpath/pipeline: investigate missing Psiphon msmts

Our batch pipeline is not able to access measurements that have names which are not "good names". There were several parts of the batch pipeline codebase which did not behave well when input was missing.
@bassosimone changed the way in which measurements are made in order to ensure they have the requirements.

It's unclear what this issue is about, we are closing it due to lack of information.


Backport 2.7: Documentation error in mbedtls_ssl_get_session

Description
Backport of #927 to mbedtls-2.7
Status
READY

Ported latest commit in the main PR
cc @sbutcher-arm @andresag01 @mpg

@RonEld: The main PR has not been approved. As there are some change requests there, I will wait until after that is resolved before reviewing this PR.

@andresag01 The main PR is now approved, and I have pushed the latest commit

@gilles-peskine-arm I fixed the issue in the ChangeLog. It was caused by an erronous cherry-pick which I have missed
cc @mazimkhan


drivers/serial/serial.c: adapt to the iovec-based api

Summary
drivers/serial/serial.c: adapt to the iovec-based api
This would fix readv/writev issues mentioned in
https://github.com/apache/nuttx/pull/12674.
(only for this specific driver though. with this approach,
we basically have to fix every single drivers and
filesystems.)
Impact
Testing
Lightly tested on the serial console, using micropython REPL
on toywasm with esp32s3-devkit:toywasm, which used to be
suffered by the readv issue.

[Experimental Bot, please feedback here]
Fill In The Commit Message: This PR contains a Commit with an Empty Commit Message. Please fill in the Commit Message with the PR Summary.
No, this PR does not fully meet the NuttX requirements.  While it provides a summary and mentions testing, it lacks crucial details.
Here's a breakdown of missing information:

Summary: While the "what" is explained, the "how" is missing.  The summary should explain precisely how serial.c is adapted to the iovec-based API. What code changes were made?  What functions were modified?
Impact:  This section is entirely empty.  All impact points need to be addressed, even if the answer is "NO".  For example, if no user impact is expected, explicitly state "Impact on user: NO".  The developer needs to consider and document every potential impact.  Given that this PR mentions fixing a bug, there's likely impact on compatibility (fixing a bug improves compatibility, arguably).
Testing: The testing description is insufficient. "Lightly tested" is vague.  What specific tests were run? What commands were issued?  The provided information about the platform is good, but the actual logs are missing.  Empty code blocks are provided for "Testing logs before change" and "Testing logs after change" - these must be populated with actual output.

Specifically, the author needs to:

Elaborate on the implementation details in the summary.
Complete the Impact section, addressing each point individually.
Provide concrete testing details and include the actual logs before and after the change.


Fixed lve_pipeline.hpp

Fixed error about missing constructor PipelineConfigInfo::PipelineConfigInfo

Thanks for taking the time to submit this, I've decide to just update all the tutorials since tutorial 5 with this fix!
https://github.com/blurrypiano/littleVulkanEngine/commit/843af1aa811d5e445d015f3bb26da253018016ec


Add python3 and future lib to allow prepping for Python2 EOL

With Python2 aiming to EOL on Jan 1, 2020 (https://github.com/python/devguide/pull/344), we need to start prepping for Python3 conversion.
The future module allows uplifting Python2 code to be mostly compatible with Python3, allowing for incremental conversions.

Yeah, I guess this probably makes sense!


Monk level-up issue

Solasta and Unfinished Business versions CURRENT as of March 17, 2023, 2:00AM.
UB version <IP_ADDRESS>
No other mods.
My main character is a Ranger/Rogue/Monk. Rest at the fire and attempt to level up: all three classes appear to be available for level 10, but Monk 2 is "blocked": upon attempting to take Monk 2, I see a blank level-up screen with no details about HP, proficiencies, feats, etc (just an image of the character: "Previous" and "Finish" are unresponsive). I must 'cancel' and return to choose Ranger or Rogue instead.
My guess is that Monk 2 contains a feat that conflicts with other feats on the character, but I can't think of what. I doubt it is because he is an old vanilla-made character who has suddenly introduced a new compatibility issue after 20+ hours of play, and only for one class, but you never know. Removing all equipment before leveling didn't help. This save follows an ambush battle, but I tested the issue at other fires and got the same result.
SolastaBugReport.zip

Tried with a brand new hero and couldn't reproduce. Please RESPEC this hero.

Thank you for the help!


Restart Postprocessing Properly

Allows differentiating between "restart" and "resume" postprocessing

@kobergj this is docs relevant, needs a change in: https://github.com/owncloud/ocis/tree/master/services/postprocessing#cli-commands
I also referenced the admin docs, beause we have a listing of changed CLI here too.

Allows differentiating between "restart" and "resume" postprocessing

Would the oCIS chart need have another CronJob next to ocis storage-users uploads sessions --restart --processing=true (https://github.com/owncloud/ocis-charts/blob/ce1b1c183b37bfda17f3114fce90b1f0f885da04/charts/ocis/templates/storageusers/jobs.yaml#L262C22-L262C95), that also calls the resume command?
I'm a little bit confused what actually needs to be run to cater all the different "postprocessing stuck" situations that can happen.

restart will restart post processing of an upload from the very beginning. This allows retrying otherwise stuck uploads.
resume will resume postprocessing from the last finished step. This will cost less resources but doesn't work in all cases.
You could always call restart or call resume in specific situations to save resources.

I'll prepare a hotfix once this is merged. This should enable us to get the files back.

@wkloucek should we merge this so I can proceed with the backport? Or you have additional suggestions?

tested during the Patch release 5.0.9
ocis/bin/ocis postprocessing resume - works
ocis/bin/ocis postprocessing restart - works
I understand diffirence between commands but couldn't find the way how to test it localy


Polyline Center

Hi,
Is there any way to automatically center the map on a polyline (without a user action)?
Thanks.

You must use the bounds facilities to center.