Compiler errors, test failures and memory problems in Cl2000 platform

Awkward to fix in a generic way that doesn't get into the way of more common platforms, time-consuming, and not sure that anyone is using this currently.
Can be fixed if anyone needs it; but decided not to fix it at this time.

I opened a new pull request to document the changes that would be needed to fix the cl2k build at this point. @basvodde didn't like some of the fixes, and I actually tend to agree with him, except I really don't know another way.
I am dropping support for this outdated compiler (it is not even the most current compiler for its platform anymore), so I suggest to close this issue.


Possible to keep undo history after closing vscode?

If i close vscode and open again i lose all undo history , is possible to keep it even closing the editor?

No

There's any extension that does it?

maynot be

Let's track in https://github.com/microsoft/vscode/issues/7536


Frameit title shrinks really small

New Issue Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Issue Description
When framing an screenshot the title text shrinks really small. This was working in the past until recently. I'm not sure if it's after updating to a newer version of Fastlane. I did roll back my branch to a known working commit and that now has the same issue, so i'm assuming it's something in my environment. See the image below:

Command executed
bundle exec fastlane frameit
Complete output when running fastlane, including the stack trace and command used

Sams-MacBook-Pro:screenshots sam.rowley$ bundle exec fastlane frameit
[✔] 🚀
[12:23:00]: Using device frames version 'latest'
[✔] Framing screenshot './en-GB/iPad Air 2-0JourneyList.png'
[12:23:16]: Added frame: '/pathToScreenshots/screenshots/en-GB/iPad Air 2-0JourneyList_framed.png'

Environment
🚫 fastlane environment 🚫
Stack

Key
Value

OS
10.15

Ruby
2.5.5

Bundler?
false

Git
git version 2.20.1 (Apple Git-117)

Installation Source
/usr/local/bin/fastlane

Host
Mac OS X 10.15 (19A582a)

Ruby Lib Dir
<EMAIL_ADDRESS>

OpenSSL Version
OpenSSL 1.1.1d  10 Sep 2019

Is contained
false

Is homebrew
false

Is installed via Fabric.app
false

Xcode Path
/Applications/Xcode.app/Contents/Developer/

Xcode Version
10.2

System Locale

Variable
Value

LANG
en_GB.UTF-8
✅

LC_ALL

LANGUAGE

fastlane files:
No Fastfile found
No Appfile found
fastlane gems

Gem
Version
Update-Status

fastlane
2.144.0
✅ Up-To-Date

Loaded fastlane plugins:

Plugin
Version
Update-Status

fastlane-plugin-appcenter
1.2.0
🚫 Update available

Loaded gems

Gem
Version

did_you_mean
1.2.0

slack-notifier
2.3.2

atomos
0.1.3

colored2
3.1.2

nanaimo
0.2.6

xcodeproj
1.15.0

rouge
2.0.7

xcpretty
0.3.0

terminal-notifier
2.0.0

terminal-table
1.8.0

multipart-post
2.0.0

word_wrap
1.0.0

public_suffix
2.0.5

colored
1.2

highline
1.7.10

commander-fastlane
4.4.6

http-cookie
1.0.3

faraday-cookie_jar
0.0.6

faraday
0.17.3

faraday_middleware
0.13.1

gh_inspector
1.1.3

mini_magick
4.10.1

multi_xml
0.6.0

rubyzip
1.3.0

security
0.1.3

xcpretty-travis-formatter
1.0.0

bundler
2.1.4

jwt
2.1.0

uber
0.1.0

declarative
0.0.10

declarative-option
0.1.0

representable
3.0.4

retriable
3.1.2

mini_mime
1.0.2

httpclient
2.8.3

google-api-client
0.36.4

jmespath
1.4.0

aws-partitions
1.293.0

aws-eventstream
1.0.3

aws-sigv4
1.1.1

aws-sdk-core
3.92.0

aws-sdk-kms
1.30.0

aws-sdk-s3
1.61.1

CFPropertyList
3.0.2

claide
1.0.3

unicode-display_width
1.7.0

plist
3.5.0

addressable
2.7.0

tty-screen
0.7.1

tty-cursor
0.7.1

tty-spinner
0.9.3

babosa
1.0.3

excon
0.73.0

unf_ext
<IP_ADDRESS>

unf
0.1.4

domain_name
0.5.20190701

fastimage
2.1.7

json
2.3.0

dotenv
2.7.5

naturally
2.2.0

simctl
1.6.8

multi_json
1.14.1

signet
0.13.2

os
1.1.0

memoist
0.16.2

googleauth
0.11.0

digest-crc
0.5.1

google-cloud-errors
1.0.0

google-cloud-env
1.3.1

google-cloud-core
1.5.0

google-cloud-storage
1.25.1

emoji_regex
1.0.1

fastlane-plugin-appcenter
1.2.0

generated on: 2020-04-03

Try using fastlane 2.142.0 as a quick fix
There was a change in 2.143.0 that affected it https://github.com/fastlane/fastlane/pull/14628

That's perfect for a quick fix for now. Thank you.


"Tab" behavior changed

After the commit 18ff44c the behavior when I press tab changes from expanding the string to the full snippet prefix to now expanding to the first line in the snippet's body.
I am trying to understand the intention behind that change, so that I can modify my workflow or perhaps change my snippet to work with this change.
The way I am using is to first expand to the full "name" of the snippet first and have another mapping to expand it to the full body. Perhaps the change is trying to do both at once but I can't find a way to set my snippet in such a way that it works.

No  update on this? I am having this problem for months but only now discovering to true source of the problem. Had to downgrade the plugin, the behavior defeats the purpose of having the vsnip on cmp.

wow I was on a old version of cmp-vsnip until I realized this.


[useScrollLock] overflow-y: scroll support no longer working

Steps to reproduce
Steps:

Go to https://master--base-ui.netlify.app/components/react-dialog/

https://github.com/user-attachments/assets/053553bc-4ca5-4fff-afcf-bac267437d67
Current behavior
Doesn't restore the value, it's overridden, so it introduces a layout shift.
Expected behavior
Correctly restore the previous values. For example https://github.com/mui/material-ui/blob/012c2e899b9a8977bb326746f43ef19a5f4f01a7/packages/mui-material/src/Modal/ModalManager.ts#L143 from https://mui.com/base-ui/react-modal/, it works.
Context
The support for overflow-y: scroll is needed to solve bugs like https://github.com/mui/material-ui/pull/40749, until we can rely on #79.

  Output from `npx @mui/envinfo` goes here.

Search keywords: -

Fixed in #604


[FLINK-26194][table-api] Deprecate unused options from TableConfig

What is the purpose of the change
Deprecate unused options from TableConfig and clean up code
Brief change log

[FLINK-26194] Deprecate nullCheck and decimalContext on TableConfig
[hotfix] Replace TableConfig ctor with getDefault().
[FLINK-26688] Remove usages of nullCheck
[FLINK-26689] Replace concrete TableConfig with ReadableConfig wherever possible to have a transparent reading of configuration options wihtout the need of calling specific methods on the TableConfig object.
[FLINK-26689] Add getLocalTimeZone() to TableConfigUtils to be able to retrieve the timezone from a ReadableConfig without the need of passing around TableConfig as method args.

Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:

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

Documentation

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

@twalthr Thanks! I've created separate tickets and adjust the commits accordingly.
The first 3 commits can be also backported to 1.15.

@twalthr Thank you, it's fine now, I've checked using ScalarFunctionTests, ScalarOperatorTests, etc. and the remaining ones are safe to use and the nullability check is based clearly on the same field that we introduce the nullTerm relevant code.

@flinkbot run azure

@flinkbot run azure


encoderd: enable

All functionality is in master, just have to make the tests pass for this.
encoderd is usually the process driving the rotation unless loggerd has not received any encoder packets in the last 500ms. The log will rotate once all 4 encoders have.
1200 frame based rotation logic remains the same, it's just now in encoderd. The rotate_cv has been replaced with a queue which enqueues the encoder messages for the next segment.

Test failure is real, will investigate tomorrow.

Woot, jenkins passes!

So this is now hitting the qcam size bug.
@adeebshihadeh can you look into this since it's happening on master also? I suspect it's what the fcamera is seeing, and the new devices see different things

Be aware, this changes behavior slightly since encoderd is the primary driver of log rotation now. It shouldn't matter in the car since loggerd is started before either encoderd or camerad (just one or the other, with camerad latency this shouldn't ever happen)
But if it does, the first segment won't contain 1200 frames. The first segment also won't contain 1200 frames when you start and kill the logger on the body.


I want to know 'JTAppleCalendar' can do it like this?

Because I've been using 'JTAppleCalendar' make half the work, I don't want to change into other components

let someSmallerDateCellValue = 20
calendarView.itemSize = someSmallerDateCellValue

Thank you for your answer. I wish you good luck.


Inconsistent User access behaviour

Checklist:

[x] I've searched in the docs and FAQ for my answer
[x] I've included steps to reproduce the bug.

Describe the bug
We have observed many inconsistencies in the User access section, details of which are added below.
Current behavior

Assigning direct permission to user fails.

I can assign a group to a user, even though I am not the manager of that group/project. Also, on updation it always gives Created user successfully message, even though the user already exists.

I can unassign a group from a user, even though I am not the manager of that group/project. Gets the same Created user successfully message here.

Even when I am a manager, I am not able to create groups (with lower permissions) for my own project.

Should be able to see the permissions of all groups (View only for non-managers of that group).

While adding a bunch of users, it gives User already exists error (if even one of the users already exists), but successfully creates other users. Which means the Add User operation is non-atomic.

Expected behavior
All the above inconsistencies should be resolved for a smoother user experience.

@strawhat5 issue 1, 4, 5 unable to reproduce, found works as expected.  issue 2 and 3 user message has been fixed, other will be fixed soon, created new ticket for that.
issue 6, User already exists on bulk creation has fixed in this PR.

@strawhat5 issue 1, 4, 5 unable to reproduce, found works as expected.  issue 2 and 3 user message has been fixed, other will be fixed soon, created new ticket for that.
issue 6, User already exists on bulk creation has fixed in this PR.

@strawhat5 issue 1, 4, 5 unable to reproduce, found works as expected.  issue 2 and 3 user message has been fixed, other will be fixed soon, created new ticket for that.
issue 6, User already exists on bulk creation has fixed in this PR.

@nishant-d Let's connect on this to see if 1, 4, 5 can be reproduced.


[unlimited:waifu2x] What is the purpose of alpha_border_padding?

I am wondering what the purpose is of alpha_border_padding, because it doesn't seem like it does anything (at least the ONNX version of it).
I thought it was doing color bleeding, but during the course of my (personal) rewrite, I checked the output of alpha_border_padding and it seems to be completely identical to the input, no matter which offset value I choose.
What is the purpose of this model?

Yes, it is for the same purpose you mention.
I posted descriptions and examples on https://github.com/nagadomi/nunif/issues/32#issuecomment-1537737645
And there still seems to be a problem.
The output of the Blender logo is as follows in unlimited:waifu2x.

There is a strange strong red line. (ignore reflection padding).
pytorch version output

Change script.js as follows to show the result of AlphaBorderPadding.
         // create temporary canvas for tile input
-        image_data = this.to_image_data(x.data, alpha3.data, x.dims[3], x.dims[2]);
+        image_data = this.to_image_data(x.data, null, x.dims[3], x.dims[2]);
         var input_canvas = document.createElement("canvas");
         input_canvas.width = w;
         input_canvas.height = h;
         var input_ctx = input_canvas.getContext("2d", {willReadFrequently: true});
         input_ctx.putImageData(image_data, 0, 0);
+        document.body.appendChild(input_canvas);
         var all_blocks = p.h_blocks * p.w_blocks;

         // tiled rendering

The output of the Blender logo is as follows in unlimited:waifu2x.

I am not sure what is wrong with your code, but in my rewritten version, it works fine.

Okay yeah, I can see that issue on my version too:

I plan to replace alpha border padding because of it sucking

Closing this issue because it has been answered


overwrite 'msbuild_toolset' only if 'toolset' is defined

node-gyp uses 'msbuild_toolset' in 'target_defaults' to specify what toolset should be used, according to what version of Visual Studio was detected.
Before this change, when 'toolset' was not specified, node-sqlite3 failed to compile with any version of Visual Studio after 2015, because gyp fails to detect the toolset correctly.
With this change 'toolset' is only used if defined, fixing compilation with node-gyp and recent VS versions.

Thanks @joaocgreis


sometimes it freeze for 5s

VSCode Version: Code 1.18.1 (929bacba01ef658b873545e26034d1a8067445e9, 2017-11-16T18:32:36.026Z)
OS Version: Windows_NT ia32 10.0.15063
Extensions:

Extension
Author (truncated)
Version

vscode-eslint
dba
1.4.3

code-beautifier
mic
1.7.2

material-icon-theme
PKi
3.0.0

Steps to Reproduce:

Reproduces without extensions: Yes/No

Please provide as many details as possible.


[docker] Let additional files be copied into the container

By placing additional files inside src/jreleaser/distributions/${name}/docker/assembly or the matching template directory of the docker packager.
Additional files must always be placed inside a directory named assembly.

Both native-image and single-jar distributions support this option since 0.2.0. It's missing on java-binary and jlink distributions.


Support for notifications

Support for notifications would be cool, when a new expense is added
https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Tutorials/js13kGames/Re-engageable_Notifications_Push

I'd argue this is pretty necessary if you're at all concerned about someone making incorrect changes to expenses in a group to reduce their own liability.  I know this is not an issue for most people as they are in groups with friends/family but that's not always the case.  Also, in Splitwise, I've caught many people accidentally making mistakes with expenses via the notifications...

1 up on this issue


[Bug Report] Form validation not working in defaultField rules

Element UI version
2.2.0
OS/Browsers version
Linux / Chrome v64
Vue version
2.5.13
Reproduction Link
https://jsfiddle.net/wfckkbya/20/
Steps to reproduce
Bind validation rules that use defaultField to validate array of multiple fields on el-form.
What is Expected?
Form validation is working.
As below, async-validator used in el-form is working well in this situation.
https://runkit.com/embed/m4y80n4lhvk0
What is actually happening?
Form validation is not working.

This should be done, any way I can help? I passed a lot of hours thinking I was doing something wrong with my el-form rules object.


Annotations

This pull request will add the ability to add an annotation to a class, indicating that that class should be incorporated into the Injector, if the injector is built with the fromProviders(String... scanSpecs) method.
This removes the need for manually listing all types that should be part of the injector. With the scanSpecs parameter, users can also note the scanners root-node. This allows the user to control which packages are scanned for @Provider annotations.
The test suit for this feature resides in the class InjectorAnnotationTest . The class is in large a copy of InjectorTest , but with one new method (for testing the setting of scanner root, and making sure we discover/don't discover the correct types), and with classes and interfaces added to the injector via annotations (instead of explicitly).
Worth discussing
Dependancy injection is a very useful tool for testing. I did consider adding a 2nd annotation, TestProvider, to let users separate which types should be injected when running tests. Instead, I went with the ability to control which packages are scanned for injectable types. Is this the correct choice?

I have merged the pull-request and also added a few tests in addition to yours.
Regarding TestProvider, I think you are right that it is better to let the user control which packages to scan rather than introducing a specific annotation. Usually I think it is better to run tests on the same annotations as the code you are testing. There is also a point in allowing the user to control which packages to scan since large code bases might have thousands or tens of thousands of files, in which case classpath scanning might become quite slow otherwise.
I do have one question regarding the name of the annotation. Wouldn't "Provided" be a better name than "Provider"? "Provider" for me sounds like a method that returns an implementation, which made me a bit confused at first. Another thing is that we could merge the two annotations and only have Inject since it is currently possible to put an @Inject on a class but it doesn't do anything.

Good points there.
I used Provider since I reasoned that "this class acts as a provider for these interfaces", but I can also see your argument about it being a bit confusing. If you prefer @Provided, I'd say go for it (Shall we change the Injector-method name too? Maybe call it byAnnotations?).
And we could probably combine it with the @Inject annotation too. Only concern I can see is that the @Inject annotation will serve several different purposes. Having different annotations does not risk confusing what they do, depending on where you put them. But maybe I am overestimating the complexity?

We can definitely keep it as two different annotations. And I think the method name is fine.


No label on inputs

Problem description
No label on inputs even though there's a label element in html?
Link to minimal working code that reproduces the issue
https://state0fmind.github.io/dashingsneed/#/login
Versions

Material-UI: v1 alpha 22

Can you share the source code and the accessibility tool you are using?

So, from what I can see in the React dev tools, we are not providing the htmlFor  to the InputLabel. I think that the TextField could have that logic 👍.

Hey accessibility tool is the lighthouse PWA testing tool that comes with chrome.
Source wiseI am using


Remove error logspew when workers shutdown

Description
Upon worker shutdown, we see
^CI, [2022-03-01T10:23:31.365933 #37552]  INFO -- temporal_client: Shutting down a workflow poller {}
I, [2022-03-01T10:23:31.366013 #37552]  INFO -- temporal_client: Shutting down a workflow poller {}
I, [2022-03-01T10:23:31.366046 #37552]  INFO -- temporal_client: Shutting down activity poller {"namespace":"ruby-samples","task_queue":"general"}
I, [2022-03-01T10:23:31.366069 #37552]  INFO -- temporal_client: Shutting down activity poller {"namespace":"ruby-samples","task_queue":"file-processing"}
E, [2022-03-01T10:23:32.371431 #37552] ERROR -- temporal_client: Unable to poll Workflow task queue {"namespace":"ruby-samples","task_queue":"general","error":"#<GRPC::Cancelled: 1:Cancelled. debug_error_string:{\"created\":\"@1646159012.369890000\",\"description\":\"Error received from peer ipv6:[::1]:7233\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1070,\"grpc_message\":\"Cancelled\",\"grpc_status\":1}>"}
E, [2022-03-01T10:23:32.371874 #37552] ERROR -- temporal_client: Unable to poll Workflow task queue {"namespace":"ruby-samples","task_queue":"file-processing","error":"#<GRPC::Cancelled: 1:Cancelled. debug_error_string:{\"created\":\"@1646159012.370120000\",\"description\":\"Error received from peer ipv6:[::1]:7233\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1070,\"grpc_message\":\"Cancelled\",\"grpc_status\":1}>"}
E, [2022-03-01T10:23:32.372262 #37552] ERROR -- temporal_client: Unable to poll activity task queue {"namespace":"ruby-samples","task_queue":"general","error":"#<GRPC::Cancelled: 1:Cancelled. debug_error_string:{\"created\":\"@1646159012.370372000\",\"description\":\"Error received from peer ipv6:[::1]:7233\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1070,\"grpc_message\":\"Cancelled\",\"grpc_status\":1}>"}
E, [2022-03-01T10:23:32.372556 #37552] ERROR -- temporal_client: Unable to poll activity task queue {"namespace":"ruby-samples","task_queue":"file-processing","error":"#<GRPC::Cancelled: 1:Cancelled. debug_error_string:{\"created\":\"@1646159012.370682000\",\"description\":\"Error received from peer ipv6:[::1]:7233\",\"file\":\"src/core/lib/surface/call.cc\",\"file_line\":1070,\"grpc_message\":\"Cancelled\",\"grpc_status\":1}>"}

At least 5 engineers have been confused by these errors on different occasions, thinking that they indicate a problem.  So I've removed them.  The shutdown now removes the errors
Test Plan
Ctrl+C the worker:
coinbase/temporal-ruby/examples $ ./bin/worker
D, [2022-03-01T10:42:32.442291 #42299] DEBUG -- metrics: workflow_poller.time_since_last_poll | timing | 0 | namespace:ruby-samples,task_queue:general
D, [2022-03-01T10:42:32.444093 #42299] DEBUG -- temporal_client: Polling workflow task queue {"namespace":"ruby-samples","task_queue":"general"}
D, [2022-03-01T10:42:32.442841 #42299] DEBUG -- metrics: activity_poller.time_since_last_poll | timing | 0 | namespace:ruby-samples,task_queue:general
D, [2022-03-01T10:42:32.450068 #42299] DEBUG -- temporal_client: Polling activity task queue {"namespace":"ruby-samples","task_queue":"general"}
D, [2022-03-01T10:42:32.443123 #42299] DEBUG -- metrics: workflow_poller.time_since_last_poll | timing | 0 | namespace:ruby-samples,task_queue:file-processing
D, [2022-03-01T10:42:32.454926 #42299] DEBUG -- temporal_client: Polling workflow task queue {"namespace":"ruby-samples","task_queue":"file-processing"}
D, [2022-03-01T10:42:32.443612 #42299] DEBUG -- metrics: activity_poller.time_since_last_poll | timing | 2 | namespace:ruby-samples,task_queue:file-processing
D, [2022-03-01T10:42:32.460494 #42299] DEBUG -- temporal_client: Polling activity task queue {"namespace":"ruby-samples","task_queue":"file-processing"}
^CI, [2022-03-01T10:42:33.811122 #42299]  INFO -- temporal_client: Shutting down a workflow poller {"namespace":"ruby-samples","task_queue":"general"}
I, [2022-03-01T10:42:33.811224 #42299]  INFO -- temporal_client: Shutting down a workflow poller {"namespace":"ruby-samples","task_queue":"file-processing"}
I, [2022-03-01T10:42:33.811266 #42299]  INFO -- temporal_client: Shutting down activity poller {"namespace":"ruby-samples","task_queue":"general"}
I, [2022-03-01T10:42:33.811293 #42299]  INFO -- temporal_client: Shutting down activity poller {"namespace":"ruby-samples","task_queue":"file-processing"}

Thanks @drewhoskins-stripe!


Not work in ie11 (Syntax error)

How I use
`
import StickySidebar from 'sticky-sidebar';
let a = new StickySidebar('.Sidebar__wrapper', {
topSpacing: 80,
resizeSensor: true,
minWidth: 980,
});`
I include polyfills into my projects? such us:
require('es6-promise').polyfill(); import 'core-js/fn/array/from'; import 'core-js/es6/symbol'; import 'core-js/fn/symbol/iterator';
Maybe I need any more polyfills?

aaaaallllllleeeeeeeeeeeeeeeeee, ik word hier wild!

Fix by yarn remove and adding it to my the source folder ¯_(ツ)_/¯

Or you can simply use dist version of stickysidebar such as:
import StickySidebar from 'sticky-sidebar/dist/sticky-sidebar';
Then it works in IE11 as well.


Ci improvements

If merging this please squash it as well

Ah so CI broke because I closed #8 because it was trying to merge into master

Why use cargo check and clippy separately? Since clippy also runs cargo check?
see: https://stackoverflow.com/questions/57449356/is-cargo-clippy-a-superset-of-cargo-check

Cargo check is basically a faster way to check if it actually compiles.

Why use cargo check and clippy separately? Since clippy also runs cargo check?
see: https://stackoverflow.com/questions/57449356/is-cargo-clippy-a-superset-of-cargo-check

Cargo check is basically a faster way to check if it actually compiles.

Ah okay, makes sense


Tabs for execute multiple queries

Already implemented in https://github.com/sqlectron/sqlectron-gui/commit/1be65a4fe636422bf03869c5460756332e8819d9.


Remove (most) embedded ext/ dependencies

This PR removes these embedded dependencies:

Expat
IlmBase (Half)
LCMS2
pystring
yaml-cpp

By default, the OCIO build now expects these packages to be available in the build environment. Respective CMake Find modules can either find them in standard locations, or reference package-specific CMake variables hinting at non-standard locations.
It was our goal however to also continue offering an easy way to pull and build dependent packages automatically, to maintain the ease of build that users of OCIO have had in the past. A new OCIO_INSTALL_EXT_PACKAGES option is introduced to do just that. Each CMake Find module will check this variable and determine if it should add a dependent install target to the imported target which pulls the source, builds, and statically links packages at build time.
There are options to install all dependencies (into ext/ for linking), or just those that are not found on the current system. Please read the new documentation in installation.rst (part of this PR) for a more detailed explanation.
This PR also addresses a number of doc build errors and compiler warnings related to external dependencies, and adds a weekly cron CI job to try building OCIO against the latest git tag of each of these projects (static analysis is also run in the same cron). Additional install .sh scripts are added to support those efforts.
I have tested this all quite extensively on Linux, but not at all on macOS or Windows, so chances are it will take some iteration to resolve various build issues in Azure on those platforms.
Another PR is coming shortly which adopts the OIIO unittest header, further cleaning up ext/. The remaining item to solve following that is sampleicc, which requires input from @hodoulp when he returns from vacation.
Legal question:
Now that these sources are out of our repo, am I right in thinking we can purge LICENSE.md of the licenses for these cleaned up dependencies?

The Windows build failure is due to IlmBase building Debug and trying to install Release. Working to sort that out...

Windows build is finally working. The bulk of the problems I was working through today were actually from Azure updating Python on our newer Windows build agents, which conflicted with our own install.
The docs now build without errors about PyOpenColorIO being undefined, which have been present in our CI builds for a long while. That involved further updating of PATH and PYTHONPATH prior to running Sphinx, to point at the just-built libs, which on Windows was complicated by proper escaping of ";" and "" through multiple levels of variable expansion.
The remaining work needed is to the cron "latest" builds, which are currently conflicting with an older Expat version installed on our CentOS image.

Ok, all builds are passing, including "latest" cron builds. I'm done touching this outside of changes from feedback/review. yaml-cpp is the only dependency that breaks the build with newer releases, and there are already multiple open issues around that.

Jeepers, I hope you squash those commits :)
I don't really have time to dig to deep into this, but your overview sounds reasonable. I'll approve on the assumption that I'll be blocking this otherwise. Assuming the rebase against master works.

I'll plan on merging this PR tomorrow if there is not additional feedback. Please have a look if you haven't yet but would like to.


feat: working towards supporting podman in wrapper script

what

Updates wrapper to use DOCKER_EXE to work towards supporting podman (I don't claim that this works correctly yet)

why

Docker is becoming more and more bloatware and can be a huge pain. Podman and others are starting to gain traction and supporting them is of interest on my team.

references

N/A

@Gowiem friendly ping. I'd love to see podman support in geodesic. The docker app is very slow in comparison.

@nitrocode yeah, I found that aliasing won't work as well. And you can build + run through podman, but I find a lot of the utility of Geodesic comes with the wrapper as it simplifies everything for non-Geodesic experts who need to run it.
We have some Makefile work that utilizes this code that I believe got podman working, but it was painful and I (obviously) dropped it. If you want to chat through that, I'm happy to show it to you, but it'd likely be more confusing if I just shared a bunch of Makefile code here.
I'll also add this draft PR to our open source board and we'll circle back around to cleaning this up at some point. I'm buying the new Macbooks once they launch for my FTE and myself -- we'll definitely come back around at that point because my ideal is that we don't even need to install Docker onto those machines at all 😁 🤞


The future of ModernDeck

Let's get this out of the way: After more than 8 years of development, development of new ModernDeck features is halted and Twitter will likely break your ability to use it in the near future. It's painful to have to put down something you've been developing on and off for the better part of a decade, but I cannot see any way forward for a variety of reasons that I'll get into. Many of these issues are shared with Better TweetDeck, and Better TweetDeck's demise was the last push I needed to clarify what the hell is going on. I cannot continue to put labor into a company that hates its developers and its users.
TweetDeck
Originally called TweetDeck Enhancer, ModernDeck started as a way for me to improve the look and feel of TweetDeck, and eventually add new features to it. First starting as a mod for the now-dead TweetDeck for Mac, it quickly emerged as a browser extension, and eventually, a dedicated desktop app built with Electron.
TweetDeck as it stands now is missing tons of features found on Twitter's more contemporary clients. Some of these features can and have been grafted in, such as a GIF picker, but other features such as managing threads prove far too difficult to try to graft in. This means ModernDeck will always be missing features present in the Twitter Web App and mobile apps, even though being based off of TweetDeck means we have privileged access to the API compared to traditional 3rd party apps.
TweetDeck Preview
To alleviate the lack of any features or development on TweetDeck, Twitter has been selectively testing a new preview version of TweetDeck that contains a lot of these features. This new version shares code with the Twitter Web App, which means it shares its feature set as well.
It also inherits large performance problems, because while the web app usually runs well enough with just a single thing on the screen at a time, with TweetDeck you can have several, even dozens of columns, meaning performance can be abysmal on lower end systems and even struggle on high end systems. This lack of any care makes this experience often even worse than old TweetDeck.
Second, it is extremely difficult to extend TweetDeck Preview like the old TweetDeck could. And it being a complete rewrite means total incompatibility with any mods built for TweetDeck. This would require a rewrite of everything at best, and at worse be just totally infeasible. So the death of ModernDeck has been on the timetable for a while, but now that Twitter is pushing out TDP to more people, it's inevitable they will kill the old TweetDeck that ModernDeck relies on to operate.
Twitter Blue
It's been speculated for a while that TweetDeck could become a paid product, and recently some code found in Twitter suggests Twitter Blue may one day be required to use it. As a product built on top of TweetDeck, that means if Twitter does this it would basically nuke the prospects of anyone not paying for Twitter Blue using ModernDeck, even if TweetDeck Classic still exists by then.
Twitter kills 3rd party apps and their API
Twitter has killed 3rd party apps such as Tweetbot, revoking their tokens and suddenly changing the developer agreement to explicitly ban 3rd party apps from using Twitter's public API.
Twitter has announced that by February 9, the Twitter API will become a paid product, with no explanation as to why, nor any pricing information.
ModernDeck is built off of TweetDeck, so it circumvents such API restrictions by being built on top of an official Twitter app (TweetDeck). However, it's clear that Twitter today hates the very developers that put in the work to make their platform what it is.
And who knows, they might randomly change their ToS to ban any modifications to Twitter's apps, putting ModernDeck and its users at risk in such a scenario. Twitter is unpredictable in their announcements, so moving forward with anything is a total minefield.
Difficult to maintain CSS
I literally learned CSS by building ModernDeck originally over 8 years ago, and it's poorly architected compared to the JavaScript/TypeScript, making refactoring it very difficult. This means it will be an uphill battle for anyone forking ModernDeck to keep it alive.
I've lost interest
Developing ModernDeck isn't as fun as it used to be, and I don't really use Twitter anymore, especially in the time since the Elon Musk shenanigans. Taking a break from social media has been necessary for my mental health. So I'm sorry to those who have waited patiently for new features and other updates that really haven't come in the past year.
Thank you for using ModernDeck all these years
I hope you found ModernDeck useful. I might still release some limited bugfix updates depending on platform, but don't expect anything big from now on.

💙

Thanks for the years of efforts in making the ModernDeck.

Thanks for the great work, Wolf. I hope you move on to better things.

just created this account to say ModernDeck has made twitter tolerable for me for a long time, so thank you for that.
this might be the reason for me to finally leave twitter

Thank you for all your work and effort during these years, Moderndeck was my main tool in order to keep away the noise and keep my feed tolerable for my job. It's a shame that the tantrum of a billionaire is ending with what made twitter useful in the first place :( MANY BLESSINGS FOR YOU

and its official now (https://twitter.com/TwitterSupport/status/1675990712297443330)

In 30 days, users must be Verified to access TweetDeck.


[WIP] feat/Support multiple email ids

…publicNames

Thanks for the pull request, and welcome! The MaidSafe team is excited to review your changes, and you should hear from @krishnaIndia (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see CONTRIBUTOR.md for more information.


Terminal color picker tweaks

The flyout wasn't very polished, so I did some adjustments. It's all visual changes, functionality should be the same.

made the flyout use OverlayCornerRadius and 16px padding (to match WinUI 2.6)
changed ColorPicker to muxc:ColorPicker for new styles (the color schemes picker too)
changed "Custom" Button into a ToggleButton

no longer needs ellipsis - localization files should be updated

OK button was moved to the right and uses accent color

why was it in all caps before? I think it should be consistent with the other buttons that's how it's spelled apparently

adjusted margins and padding
tweaked the color boxes to look like the ones in color schemes

(Thanks for this! We're a bit busy with the influx of new issues since we shipped 1.8/1.9, but we don't mean to ignore you. I'm shocked that we weren't using the right ColorPicker this whole time but WHATEVER
I hope we're using the right one in the settings editor :grin:)

Thanks for the response!
The settings ColorPicker wasn't the mux one either. Half of this PR is only for changing that one 😄

Thanks for the review!
I made the flyout have an effective 8px margin. The "more" button is included in the default ColorSpectrum, so it can't be easily updated.


chore: fix linting setup

Our linting setup was broken due to a mismatch in prettier versions used across the toolings. Linting also revealed a bunch of missing dev dependencies in features/keychain.
Testplan
Linting passes locally

thanks @sparten11740! i'll get this in tomorrow


feat(pod): allow passing an existing secret to dockerRegistryAuth (#1791)

Backport
This will backport the following commits from k8s-26/main to k8s-24/main:

feat(pod): allow passing an existing secret to dockerRegistryAuth (#1791)

Questions ?
Please refer to the Backport tool documentation

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1799

Questions ?
Please refer to the Backport tool documentation


[Feature] Support Models in dbutils.fs operations

Changes

Support files operations in WorkspaceClient.Files for Databricks UC Model artifacts so that user can use databricks sdk to download UC model artifacts.
This PR is part of the work to migrate mlflow client towards using databricks sdk for model artifacts download/upload operations for better security.

Tests

Existing tests in test_dbfs_mixins.py, similar to how _VolumesPath is tested
The following code works

from databricks.sdk import WorkspaceClient
w = WorkspaceClient()
resp = w.files.download("/Models/system/ai/dbrx_instruct/3/MLmodel")

[x] make test run locally
[x] make fmt applied
[x] relevant integration tests applied

jenkins merge

hey @mgyucht how you know how to merge this pr? not seeing anything on my UI for merging


Make scalismo work with Scala 3

This PR makes scalismo crosscompile for scala 3.0 and scala 2.13.

Seems good to me. Test passes locally for me and I've also checked that I can use the version for a project with both scala 3 and 2.13 main files.

@madsendennis Thanks for looking at it. In the meantime I fixed the formatting also found out what caused the tests to fail (sometimes). It was a problem with the initialization during object creation time. More precisely, I computed a matrix inverse to initialize a val in an object. As it is not determined when the values in the objects are created, this sometimes happened before netlib was properly initialized. Changing the corresponding val to a lazy val solved the problem.

@madsendennis Thanks for looking at it. In the meantime I fixed the formatting also found out what caused the tests to fail (sometimes). It was a problem with the initialization during object creation time. More precisely, I computed a matrix inverse to initialize a val in an object. As it is not determined when the values in the objects are created, this sometimes happened before netlib was properly initialized.


PWN-9042, PWN-9043, PWN-9057, PWN-9050, PWN-9046 - device share fixes

Jira Ticket
https://p2pvalidator.atlassian.net/browse/PWN-9042
https://p2pvalidator.atlassian.net/browse/PWN-9043
https://p2pvalidator.atlassian.net/browse/PWN-9057
https://p2pvalidator.atlassian.net/browse/PWN-9050
https://p2pvalidator.atlassian.net/browse/PWN-9046
Description of Work
PWN-9042 - set torusKeyTimestamp to 0 if torus key is null (on error cases)
PWN-9043 - text for incorrect account updated
PWN-9057 - errors handling fixed
PWN-9050 - backStack return fix
PWN-9046 - fix intercom on restore flow

thanks for naming all tickets in the PR' title!


test: mark flaky tests with flaky tag

Contains
Adding the flaky tag to the ExampleTest.testSendEvent and DelayManagerTest.delayedActionIsTriggeredTest tests.

@BenjaminAmos as discussed in today's reviver sync, I marked the sporadically failing tests flaky.
With this, they will be run in CI as part of the "flaky tests" stage instead of the "non-flaky tests" stage that they were part of so far.
This will hopefully improve the developer experience as less PRs are blocked by sporadic failures until we get to investigate these sporadics in depth.


codeunit 8 AccSchedManagement

https://github.com/microsoft/ALAppExtensions/issues/13469#event-5075139552
Would it then be possible to make a "Get" Pocedure?
procedure GetStartDateEndDate(OutputStartDate: Date; OutputEndDate: Date)
begin
    OutputStartDate := StartDate;
    OutputEndDate := EndDate;
end;

The parameters will need to be declared var for changes in them to propagate to the caller

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Player Skin

The player skin seems to get in the way in first person mode, any way to make it invisible?

I worked around this in my fork https://github.com/deathcap/voxel-player by hiding the player entirely in first-person mode https://github.com/deathcap/voxel-player/commit/c479bd1e1b6c89e525fb342001ac84bb007c5b69 https://github.com/deathcap/voxelmetaverse/issues/2 (downside is then you can't see your arms, but the arm object should probably be rendered separately in first-person perspective since the whole player model is not needed), but haven't PR'd it back to this original project, because voxel-player depends on three.js and hasn't been ported to the ndarray/stackgl branch (ref https://github.com/maxogden/voxel-engine/pull/103)

@deathcap Awesome! I was trying to achieve the same effect and didn't realize that you had a fork of the project. Once again this would be something to add to the "wiki" I mentioned in the other issue.


fix(modelgen-js): use string array for associateWith

Description of changes

Used string array instead of single string for associateWith in JS model schema file
Added foreign key of sort key field in associateWith

Issue #, if available

Description of how you validated changes
Checklist

[x] PR description included
[x] yarn test passes
[x] Tests are changed or added
[ ] Relevant documentation is changed or added (and PR referenced)
[ ] Breaking changes to existing customers are released behind a feature flag or major version update
[ ] Changes are tested using sample applications for all relevant platforms (iOS/android/flutter/Javascript) that use the feature added/modified

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #464 (9965319) into main (5c6c91c) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #464   +/-   ##
=======================================
  Coverage   85.88%   85.89%
=======================================
  Files         143      143
  Lines        7065     7068    +3
  Branches     1852     1854    +2
=======================================
+ Hits         6068     6071    +3
  Misses        906      906
  Partials       91       91

Impacted Files
Coverage Δ

...ugin/src/visitors/appsync-json-metadata-visitor.ts
95.74% <100.00%> (+0.14%)
:arrow_up:

:mega: Codecov can now indicate which changes are the most critical in Pull Requests. Learn more


Unable to flash TYWE3S Device Tower Fan TF4601TR-S

I'm trying to flash a Stirling Tower Fan purchased from Aldi in Australia. It appears to be the same as the fan listed here: https://templates.blakadder.com/sichler_NX4538-944.html
I opened up the fan to see what micro-controller was installed. It is a TYWE3S.
I'm attempting to flash using a raspberry pi 4.
Tuya convert times out with the following messages:
`Timed out while waiting for the device to (re)connect
Attempting to diagnose the issue...
No ESP82xx based devices connected according to your wifi log.
Here is a list of all the MAC addresses that connected:
72:16:cc:73:47:29
If you see your IoT device in this list, it is not an ESP82xx based device.
Otherwise, another issue may be preventing it from connecting`
I've previously captured the fan's MAC address and it is not the one listed above.
My log files are provided.
smarthack-mqtt.log
smarthack-psk.log
smarthack-udp.log
smarthack-web.log
smarthack-wifi.log
I'm hoping someone can shed some light on this. I'm keen to get it converted and don't mind resorting to using a soldering iron if necessary.

Same as https://github.com/ct-Open-Source/tuya-convert/issues/1007
I solved it by running Pi OS Lite - Debian Buster.

Same as #1007
I solved it by running Pi OS Lite - Debian Buster.

Thanks Lloyd, I tried that, same result unfortunately.


Flags are never cleared when there's a UART error

If there's a UART error (for example, it receives a byte when there's already a byte in the Receive Data Register), a sticky flag gets set. This flag causes read() to return an error, but the flag doesn't get cleared. So every subsequent read() also returns an error.
I propose you clear the flag by writing to the appropriate bit in icf just before the error is returned.

@thejpster Any chance you could test the PR? Having troubles creating errors here... ;)

The easiest way to generate an error is to write two characters to the UART, without reading the first one first. This will trigger a UART data overflow error.


Printf "database/sql" got panic under high qps pressure.

Please answer these questions before submitting your issue. Thanks!
The following package is not thread safe: "database/sql"
What version of Go are you using (go version)?
go version go1.7 linux/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/data/home/markgyang/project/video-content-platform/spcdp_cp"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build491876654=/tmp/go-build"
CXX="g++"
CGO_ENABLED="1"
What did you do?
I imported this package "database/sql", and got a object: db *sql.DB
Then I initialized it and printed it: fmt.Printf("%v", db)
What did you expect to see?
Print db structure as usual.
What did you see instead?
It printed the db structure as normal, but as long as I increased the frequency of calling fmt.Printf("%v", db), I got golang concurrent map read and map write error, then the program panic during runtime.

This looks like memory corruption. Have you tried running your program under the race detector? See https://blog.golang.org/race-detector .

The sql.DB contains several maps which should only be read or written to under locks.
Calling fmt.Printf("%v", &sql.DB{}) will attempt to read these map structures. This will cause a race condition the runtime can (and did) detect for you.

Don't do this.
What are you trying to do by printing out the sql.DB? Are you trying to get stats? Stats has been expanded greatly in Go1.11.


update to use skew binomial queue, global root, and bootstrapping

these performance improvements are described in the Brodal/Okasaki paper

After reading chapter 5 of Okasaki, I think I'll forego bootstrapping because it is intended to help with meld performance, which afaict is only needed as a part of deleteMinBy. If there's a good reason to add bootstrapping, I can do that in a separate issue.


[backport] Make too slow initializers' tests faster

Backport of #6792

[automatic post] Jenkins, test this please.

Jenkins CI test (for commit 54bd0177f441b6f3f14f3ea8c46688871afe18e1, target branch v6) failed with status FAILURE.


Fortran, cmake based formulae from source w/ Intel ifort installed causes problems

Please note:

I am not sure if a bug report or a feature request best describes the issue I'm experiencing; I used a bug report template and included all info below.
I know a simple work-around exists: Unlink Intel's ifort so it's not in the PATH when homebrew is performing builds; however, in the interest of avoiding future confusion with users and simplifying/unifying homebrew packages, formulae & maintenance I think it's worth filing a bug report/feature request.

TL;DR:
Please consider setting the FC environment variable to point to a brewed gfortran inside the build environment; without it CMake based builds can stupidly pick up ifort (and other compilers too, probably), happily building your Fortran formula, but then leading to much confusion down the road when you try to USE module_from_brewed_formula with brewed gfortran at a later date.
Requested bug report template info:

[X] are reporting a bug others will be able to reproduce and not asking a question. If you're not sure or want to ask a question do so on our Discourse: https://discourse.brew.sh
[X] ran a brew command and reproduced the problem with multiple formulae? If it's a problem with a single, official formula (not cask) please file this issue at Homebrew/homebrew-core: https://github.com/Homebrew/homebrew-core/issues/new/choose. If it's a brew cask problem please file this issue at https://github.com/Homebrew/homebrew-cask/issues/new/choose. If it's a tap (e.g. Homebrew/homebrew-php) problem please file this issue at the tap.
[X] ran brew update and can still reproduce the problem?
[X] ran brew doctor, fixed all issues and can still reproduce the problem?
[X] ran brew config and brew doctor and included their output with your issue?

Brew config:
$ brew config
HOMEBREW_VERSION: 1.6.7-4-g9c1a988
ORIGIN: https://github.com/Homebrew/brew
HEAD: 9c1a988c326ba20f1b8a06b4b4f6af11b34722a6
Last commit: 72 minutes ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: a930ced7bc7f391f9d488d904254f9a9ace1db04
Core tap last commit: 3 hours ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_DEV_CMD_RUN: 1
CPU: quad-core 64-bit haswell
Homebrew Ruby: 2.3.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/bin/ruby
Clang: 9.1 build 902
Git: 2.17.1 => /usr/local/bin/git
Curl: 7.54.0 => /usr/bin/curl
Java: 10.0.1, 1.8.0_172, 1.8.0_152, 1.6.0_65-b14-468
macOS: 10.13.5-x86_64
CLT: <IP_ADDRESS>.1.1527767617
Xcode: 9.4
XQuartz: 2.7.11 => /opt/X11

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

Warning: The filesystem on / appears to be case-sensitive.
The default macOS filesystem is case-insensitive. Please report any apparent problems. # I'm not changing my FS for a homebrew bug report

Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  emacs # Not linking b/c I have a cask linked
  markdown # Not linking due to conflict
  mpich # Not linking due to conflict w/ open-mpi

To help us debug your issue please explain:

What you were trying to do (and why)

Installing a formula with a dependency on Fortran that uses CMake and installs fortran .mod module files, e.g. json-fortran

What happened (include command output)

The install succeeded, however, even when FC=/usr/local/bin/gfortran-8 the Fortran compiler picked was ifort because I have intel-parallel-studio installed and linked (installed to /usr/local/Cellar/intel-parallel-studio). Note: this behavior is specific to CMake, AFAICT. The solution is to either import and respect $FC into the super-env or intelligently set $FC to point to Homebrewed GCC's gfortran in the superenv. This will ensure CMake doesn't pick up and prefer ifort over Homebrew's gfortran. IMO, this it is a bug that CMake defaults to ifort over gfortran, but it is what it is. The output indicating that we will run into problems in the future is:

-- Checking whether /usr/local/bin/ifort supports Fortran 90
-- Checking whether /usr/local/bin/ifort supports Fortran 90 -- yes

What you expected to happen

Homebrew sets FC=/path/to/brewed/gfortran in the superenv so that CMake doesn't stupidly pick up ifort OR (less preferred) homebrew respects (imports) the users $FC environment variable. (The latter option is probably pretty error prone and dumb so I'm ruling it out.)

Step-by-step reproduction instructions (by running brew commands)

Install an Intel Fortran compiler into /usr/local/Cellar/intel-parallel-studio/2019.0.0 (you can sign up to be a beta tester and get a beta trial version license until they release the production version)
brew link intel-parallel-studio
Build a fortran formula from source that provides a module file and uses CMake as the build system: e.g.,

$ FC=$(type -P gfortran-8) brew install --build-from-source --verbose json-fortran
/usr/bin/sandbox-exec -f /tmp/homebrew20180606-3992-10vi3su.sb nice /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3_2/bin/ruby -W0 -I /usr/local/Homebrew/Library/Homebrew -- /usr/local/Homebrew/Library/Homebrew/build.rb /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core/Formula/json-fortran.rb --verbose
==> Downloading https://github.com/jacobwilliams/json-fortran/archive/6.3.0.tar.gz
Already downloaded: /Users/ibeekman/Library/Caches/Homebrew/json-fortran-6.3.0.tar.gz
==> Verifying json-fortran-6.3.0.tar.gz checksum
tar xzf /Users/ibeekman/Library/Caches/Homebrew/json-fortran-6.3.0.tar.gz
==> cmake .. -DCMAKE_C_FLAGS_RELEASE=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -DCMAKE_INSTALL_PREFIX=/usr/local/Cellar/json-fortran/6.3.0_1 -DCMAKE_BUILD_TYPE=Release -DCMAKE_FIND_FRAMEWORK=LAST -DCMAKE_VERBOSE_MAKEFILE=ON -Wno-dev -DUSE_GNU_INSTALL_CONVENTION:BOOL=TRUE
-- The Fortran compiler identification is Intel <IP_ADDRESS>80317
-- Check for working Fortran compiler: /usr/local/bin/ifort
-- Check for working Fortran compiler: /usr/local/bin/ifort  -- works
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Checking whether /usr/local/bin/ifort supports Fortran 90
-- Checking whether /usr/local/bin/ifort supports Fortran 90 -- yes
-- CMake build configuration for JSON-Fortran 6.3.0
-- Dynamically computing FORD output information...
-- Running FORD to dynamically compute documentation outputs, this could take a while...
^C

After a successful install try compiling a dumb test program with GFortran that consumes one of the installed .mod files from the formula:

! usemod.f90
program usemod
use json_kinds
implicit none
print*, 'if this compiled then there is no problem'
end program

$ gfortran-8 -I /usr/local/include usemod.f90
f951: Fatal Error: Reading module 'json_kinds' at line 1 column 2: Unexpected EOF
compilation terminated.

Obviously, brew unlink intel-parallel-studio before building JSON-Fortran with Homebrew solves this issue. But since Fortran compilers are not in general inter-operable, it would be very nice to have Homebrew ensure that packages with depends_on "gcc" due to Fortran dependencies actually use gfortran for compilation. For CMake based packages this is not the case due to CMake's quirks.
Thanks for you time and for your great work as volunteers. If someone points me in the right direction I'll try to find time to work up a PR that will inject FC=/path/to/brewed/gfortran into the build environment.
Best,
Zaak

The formula is responsible for setting the desired FC. Does it not work to
ENV["FC"] = "/path/to/whichever"

at the beginning of def install?

@ilovezfs Sure, that would work. But AFAICT, most CMake + Fortran formulae assume that GFortran will be used, since it's the only Fortran compiler currently available in homebrew (unless someone added flang when I wasn't paying attention). The C compiler is always set as Clang by homebrew, why not exert the same level of control and predictability for Fortran?
If you show me an easy way to find all formulae with depends_on "gcc" and depends_on "cmake" => :build I can make a PR to homebrew-core that enforces GFortran for all of them.
But I really don't see any point in providing users/formula authors with that flexibility when you're already enforcing MPI => open-mpi and the C compiler as clang.

Unlike the superenv compiler shims, Fortran is going to have to be supplied by a specific dependency in the formula so it makes sense to handle that in the formula.

If the general consensus is that picking the right Fortran compiler is the formula's responsibility then I will defer to the judgement of the homebrew maintainers. But as a formula contributor, it's not really clear that not doing setting FC in your formula can get you or other users into trouble in the future. I.e., if they build any software from source and have the audacity to install an additional Fortran compiler on their system. By default the "gcc" dependency for Fortran is already saying "please use gfortran" ever since depends_on => :fortran was removed. However, thanks to CMake's quirks, merely having another Fortran compiler present on the system can break this behavior and cause very confusing and un-anticipated results that are hard to debug.
An alternate (better?) approach would be to modify the std_cmake_args when a depends_on "gcc" is present so that -DCMAKE_Fortran_COMPILER=/path/to/brewed/gfortran is included by default. If any formulae do anything naughty (from a CMake perspective) like ENV["FC"] = /path/to/brewed/open-mpi/bin/mpif90 and also use CMake for the build then it might cause some problems. Right now, this is not the case for any formulae; hdf5 and petsc are the only formulae that set ENV["FC"] = ... (Both DO set it to mpif90, but neither use CMake for the build.)
If it is decided that Formulae are responsible for providing their one ENV["FC"] = ..., then I would recommend (and try to do it myself) that formulae with a depends_on "gcc" and a depends_on "cmake" => :build" get edited to use ENV["FC"] = /path/to/homebrew/gfortran. Show me an easy way to get a list of those formulae and I can test & implement this in a PR to homebrew-core. But I'd love to hear if anyone (including @ilovezfs) finds my argument convincing that the onus of this should not be left to formula maintainers.

If it is decided that Formulae are responsible for providing their one ENV["FC"] = ..., then I would recommend (and try to do it myself) that formulae with a depends_on "gcc" and a depends_on "cmake" => :build" get edited to use ENV["FC"] = /path/to/homebrew/gfortran. Show me an easy way to get a list of those formulae and I can test & implement this in a PR to homebrew-core.

To be clear, it's the formula's responsibility to set it if needed, which would mean anywhere where CI actually fails without it. I didn't mean to imply that we should be setting everywhere. I favor as little magic as possible on the backend, and given how infrequently it's been necessary to intervene and set FC, going back to set it globally or in std_cmake_args would be an unnecessary step backwards in the direction of unneeded magic.

IMO, this it is a bug that CMake defaults to ifort over gfortran, but it is what it is.

Have you actually reported it to CMake upstream to request gfortran take precedence over ifort and been turned away with a won't-fix? That seems like a reasonable request especially given ifort isn't even in PATH during the build.

It is in the PATH during the build.
The problem will never affect CI or bottled builds (unless someone installs
another Fortran compiler on the ci system).
I don’t really see it as magic if we’re already saying we want GFortran
through the gcc dependency.
What is magic and highly confusing is trying to use a package you installed
with homebrew in the past only to get a cryptic error message about a .mod
file during compilation.
On Wed, Jun 6, 2018 at 12:20 PM ilovezfs<EMAIL_ADDRESS>wrote:

IMO, this it is a bug that CMake defaults to ifort over gfortran, but it
is what it is.
Have you actually reported it to CMake upstream to request gfortran take
precedence over ifort and been turned away with a won't-fix? That seems
like a reasonable request especially given ifort isn't even in PATH during
the build.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Homebrew/brew/issues/4293#issuecomment-395128509, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAREPBf09EL99kytT4bQ-wChjojyXF9oks5t6AFFgaJpZM4Uc1OB
.

It is in the PATH during the build.

How? That will only happen if you set it as a dependency in the formula.

I don’t really see it as magic if we’re already saying we want GFortran through the gcc dependency.

Setting an environment variable (or passing extra args) that may or may not be necessary for a successful build based on attempted deductions from a combination of dependencies is pretty magical.

get a list of those formulae

List of possibly affected should be
Josephs-MacBook-Pro:Formula joe$ (cd $(brew --repo homebrew/core)/Formula; grep -rlE "depends_on.*gcc" .|while read f; do brew deps --include-build -1 $f | grep -q cmake && echo $(basename $f .rb); done)
eccodes
gmsh
grib-api
json-fortran
lapack
libcds
mmseqs2
netcdf
opencoarrays
plplot
root
scalapack
spades
sundials

modulo false positives for openmp use.

It is in the PATH during the build.
How? That will only happen if you set it as a dependency in the formula.

Oh, I guess if /usr/local/bin is ignored unless a formula dep exists then I am mistaken and CMake is doing some pretty damn magical BS to find ifort. In this case, I think (hope) the CMake devs would be willing to default to the Fortran compiler actually available on the path...

List of possibly affected should be
Josephs-MacBook-Pro:Formula joe$ (cd $(brew --repo homebrew/core)/Formula; grep -rlE "depends_on.*gcc" .|while read f; do brew deps --include-build -1 $f | grep -q cmake && echo $(basename $f .rb); done)
eccodes
gmsh
grib-api
json-fortran
lapack
libcds
mmseqs2
netcdf
opencoarrays
plplot
root
scalapack
spades
sundials
modulo false positives for openmp use.

@ilovezfs you rock! If the final ruling on this issue is "won't fix/invalid", then I can go through and check/verify those formulae. In addition, I think we might want to add a note to the formula cookbook documentation in the Fortran section to warn new formula submitters that they may want to take a little extra care if their build system uses CMake.

Oh, I guess if /usr/local/bin is ignored unless a formula dep exists

/usr/local/bin is never in the PATH during a build (unless you're using --env=std). Instead we use /usr/local/opt/foo/bin:/usr/local/opt/bar/bin:etc.

CMake is doing some pretty damn magical BS to find ifort.

Yeah. Even putting aside whatever is allowing it to find ifort, and assuming that part is legitimate in CMake world, requesting a gfortran > ifort order of preference upstream would be lovely.

I think (hope) the CMake devs would be willing to default to the Fortran compiler actually available on the path

👍

Yeah. Even putting aside whatever is allowing it to find ifort, and assuming that part is legitimate in CMake world, requesting a gfortran > ifort order of preference upstream would be lovely.

Agreed.
I'll await the final ruling on the issue (unless you've already made it) before looking at the formula you've identified and the formula cookbook documentation upgrade.
Thanks again.

FYI: https://gitlab.kitware.com/cmake/cmake/issues/18072

If I've understood this correctly this seems to be an upstream issue and a wontfix for us. @ilovezfs if I've misunderstood: please reopen. Thanks for the report, @zbeekman!

@ilovezfs @MikeMcQuaid Can we please reopen this? I have been in touch with upstream, and have determined that this is a result of L193 in super.rb:
  def determine_cmake_prefix_path
    PATH.new(
      keg_only_deps.map(&:opt_prefix),
      HOMEBREW_PREFIX.to_s, # line 193
    ).existing
  end

The effect of this line is to say to CMake: "Go and throw HOMEBREW_PREFIX at the front of every single search path." Any find_program() and find_library() calls and a whole bunch of other stuff will be searching in /usr/local/{bin,lib,include,share,etc,...} or wherever the HOMBREW_PREFIX is. (Note that, while the documentation of the variable itself is somewhat sparse, the documentation of it's affect on find_program() which CMake uses to determine the compiler, is clear that this will get picked up from the user's environment.)
This is most certain the type of magic one should avoid, and seems to defeat the purpose of the superenv if CMake is going to go ahead and blithely ignore part it. CMake will be picking up every installed package in calls to find_program() etc. with this set.
I have confirmed that removing it from the build environment (by deleting line 193 of super.rb) resolves this issue for me. I have no idea if any CMake based packages will get caught out by the removal of this but, if they do, it most likely means that they have dependencies that have not been correctly enumerated.
I'm going to open a PR to see what happens, and make your lives easier in the event you agree with me that this is a bug in super.rb. Looking at the commit log, this seems to have been the default behavior since legacy homebrew May 2014 in commit https://github.com/Homebrew/legacy-homebrew/commit/8a6c747cbdcd2bb1c4a6f39dc44d967548e7f967.

Nice catch!

Sorry, I should have time to work on the PR later today.
On Sun, Jul 1, 2018 at 10:40 AM stale[bot]<EMAIL_ADDRESS>wrote:

This issue has been automatically marked as stale because it has not had
recent activity. It will be closed if no further activity occurs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Homebrew/brew/issues/4293#issuecomment-401611075, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAREPP7WlDei7J85C0R-kE-c-oa93vToks5uCN9igaJpZM4Uc1OB
.


Add support for ContentEditable DIV

Currently, a div with the contenteditable attribute is not supported, and will not update the counter

@TheKillerremijn Have you been able to even show the counter on one of these? I can't.

content editable is not supported.
The editor you use for it should have support for it. This plugin is meant to be used only on inputs and textareas.


Updated DOCS.md

Proposed Changes

Many to make setting up this add-on more intuitive and current IAW new HA UI changes.

Related Issues

(Github link to related issues or pull requests)

I replied to most of the dissimilar comments.

I'm going to close and friendly decline this PR.
There are many unrelated changes and I don't feel like you are able to bring this one home.
Nevertheless, thanks for willing to contribute 👍
../Frenck


Uncaught TypeError: Cannot read property 'getConfigParam' of undefined

Install the package
Open a file like this in Atom: "~/haskell/test.hs" (REPL also doesn't open unless I have a .hs file open)
Click "Haskell IDE > Open REPL" in the menubar
Error occurs.

 Should be fixed in 0.1.5. That said, this package is designed for use alongside ide-haskell & friends (ide-haskell-cabal, etc), so I suggest you consider installing those as well. Standalone operation is supported though, despite an occasional bug, so it's entirely up to you.

Cool! Thanks for the quick response!


Added ability to set color temp on Wink lights

This PR has gone stale for a month. Closing it. Please reopen when rebased on the latest dev version and comments addressed.


[image_picker] dosen't return anything if onActivityResult on MainActivity.java is overridden

I discovered it trying to use a platform view

me too.. do not know how to resolve it!

Resolved calling super.onActivityResult(requestCode, resultCode, data);


Use size_t for index argument

This matches the OpenCoarrays public API, as well as the MPI_Aint type
used in MPI_Compare_and_swap and MPI_Fetch_and_op function signatures.

Avg response time
coverage on master

Summary of changes
Summarize what you changed
Rationale for changes
Why did you make these changes?
Additional info and certifications
This pull request (PR) is a:

[x] Bug fix
[x] Feature addition
[ ] Other, Please describe:

I certify that

[x] I reviewed and followed the contributing guidelines, including
- Increasing test coverage for all feature-addition PRs
- Increasing test coverage for all bug-fix PRs for which there
does not already exist a related test that failed before the PR
- At least maintaining test coverage for all other PRs
- Ensuring that all tests pass when run locally
- Naming PR  to indicate work in progress (WIP) and to attach the PR
to the appropriate bug report or feature request issue
- White space (no trailing white space or white space errors may
be introduced)
- Commenting code where it is non-obvious and non-trivial
- Logically atomic, self consistent and coherent commits
- Commit message content
- Waiting 24 hours before self-approving the PR to give another
OpenCoarrays developer a chance to review my proposed code

@jabl Sorry for the delay in reviewing and merging this. I'll merge today once the non-macOS CI tests pass. (I need to resolve updated upstream packages on macOS to get the build to work again.)


Rewrite project structure so that goquery can be imported as a library

As of @directionless's suggestion, it makes more sense for goquery to be imported as a library, rather than needing to clone and modify the source to get any integration working.
main.go should be reworked so that the entry point is in goquery.go with a call to Start(api GoQueryAPI) where api is either a custom or referenced built in API
This way contributions are easier and
An example wrapper example.go can be used to demonstrate integration, and also used to go run to see an example working quickly.

In addition, goquery does not need to be responsible for command line argument parsing. Since there will be an outer wrapper go file handling the call and options configured for goquery, the responsibility is of the caller to configure the options.

@AbGuthrie Do you expect to do refactoring to the API for working with a server? We are looking at implementing for Fleet and wondering whether we should wait for this refactor.

Hi Zachary, integration revolves around the GoQueryAPI interface. I will be aiming to keep it as stable as possible.
With the current implementation, users would need to git clone and then create a new file within the api folder. This is obviously not ideal.
This ticket's effort will not change API interface, but will change where the custom APIcode lives and how its passed in. It would make more sense for users to just import goquery and pass their custom GoQueryAPI object to the main function.
It would be a good idea to wait because you wont need to git clone and build manually to integrate!


Display Ipv6 addresses in System Monitor

Note: this also updates the Nix flake lock so qemu runs again on my nixos-unstable system

Will discard the flake.lock commit once merged, please upstream that.

Okay, willdo


CON-435 Allow querying on record id.

Added logic in findAtomic class.
Created Test classes to test the features.

Please review and provide feedback @javierlores and @as577

manually merged


feat: implement a shared Glitch shortcode

Resolves #64
The Glitch shortcode on both d.d.c and web.dev have the same design and code structure. So, this shortcode can be moved into webdev-infra so it will be a shared shortcode which can be used by both d.c.c and web.dev.
Changes in this pull request:

Adds a new shared Glitch shortcode

Usages:
{% Glitch {
  id: 'tabindex-zero',
  path: 'index.html',
  previewSize: 0,
  allow: []
} %}

{% Glitch 'tabindex-zero' %}

@matthiasrohmer  I have tested a shared Glitch shortcode with web.dev and d.c.c, it works fine with both site.
The results of testing a shortcode with both web.dev and d.c.c. are shown below:

web.dev
d.c.c.


[CDPx] update SDK, restore telemetry, build MSIX

Summary of the Pull Request
Update the config files for the CDPx pipeline to:

use the latest Windows 10 SDK
restore telemetry without requiring the projects to reference the nuget package
build and sign the MSIX bundle

References
Part of the work for https://github.com/microsoft/PowerToys/issues/413

PR Checklist

[x] Applies to https://github.com/microsoft/PowerToys/issues/1356 & https://github.com/microsoft/PowerToys/issues/1357

Validation Steps Performed
Tested individual scripts locally.

@ryanbodrug-microsoft
Ryan, you can give it a try locally to check if the scripts to restore and build the project work on your machine before we merge this and trying to kick off a build.
In the .pipeline folder, using a VS 2019 command prompt, you can execute the following scripts individually.

restore.cmd
restore-installer.cmd
restore-telemetry.cmd
build.cmd
build-installer.cmd
msix\build-msix.cmd

Let me know if you have any question. Thanks.

@Enrico Giordani (Janea Systems<EMAIL_ADDRESS>restore.cmd, and restore-installer.cmd worked for me, but I’m getting the following error from restore-telemetry.cmd.  I’m guessing the package source for Microsoft.PowerToys.Telemetry.1.0.0. is incorrect locally?
c:\Repos\PowerToys.pipelines>restore-telemetry.cmd
c:\Repos\PowerToys.pipelines>cd /D "c:\Repos\PowerToys.pipelines"
c:\Repos\PowerToys.pipelines>call nuget.exe restore -ConfigFile nuget.config packages.config   || exit /b 1
All packages listed in packages.config are already installed.
c:\Repos\PowerToys.pipelines>move /Y "Microsoft.PowerToys.Telemetry.1.0.0\build\include\TraceLoggingDefines.h" "..\src\common\Telemetry\TraceLoggingDefines.h"   || exit /b 1
The system cannot find the file specified.
Here are the last 2 commits I have.
<EMAIL_ADDRESS>From: Enrico Giordani<EMAIL_ADDRESS>Sent: Monday, February 24, 2020 8:37 AM
To: microsoft/PowerToys<EMAIL_ADDRESS>Cc: Ryan Bodrug<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/PowerToys] [CDPx] update SDK, restore telemetry, build MSIX (#1358)
@ryanbodrug-microsofthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryanbodrug-microsoft&data=02|01|ryanbod%40microsoft.com|efca442351aa403c10a308d7b947cb69|72f988bf86f141af91ab2d7cd011db47|1|0|637181590319639026&sdata=JcvgjaqyCbiHKWuwortXOAvWVqCWSZ1zuNjnTWeOpJg%3D&reserved=0
Ryan, you can give it a try locally to check if the scripts to restore and build the project work on your machine before we merge this and trying to kick off a build.
In the .pipeline folder, using a VS 2019 command prompt, you can execute the following scripts individually.

restore.cmd
restore-installer.cmd
restore-telemetry.cmd
build.cmd
build-installer.cmd
msix\build-msix.cmd

Let me know if you have any question. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPowerToys%2Fpull%2F1358%3Femail_source%3Dnotifications%26email_token%3DANNVUNNVRAYRWBZPGGSYOYLREPZTLA5CNFSM4K2LUWQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMYSIQI%23issuecomment-590423105&data=02|01|ryanbod%40microsoft.com|efca442351aa403c10a308d7b947cb69|72f988bf86f141af91ab2d7cd011db47|1|0|637181590319639026&sdata=t7ajlbwyG77Q62BaXDIdcdJT0t%2B%2FoSij6c6pCgUl8lM%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANNVUNMEBSRPMYQHGQWWOLTREPZTLANCNFSM4K2LUWQA&data=02|01|ryanbod%40microsoft.com|efca442351aa403c10a308d7b947cb69|72f988bf86f141af91ab2d7cd011db47|1|0|637181590319649020&sdata=fSXV2rCl2MRd9YQ3oDGVr3SFgO%2F4Y1RKxAMzTSsJAbU%3D&reserved=0.

@enrico Giordani (Janea Systems<EMAIL_ADDRESS>restore.cmd, and restore-installer.cmd worked for me, but I’m getting the following error from restore-telemetry.cmd. I’m guessing the package source for Microsoft.PowerToys.Telemetry.1.0.0. is incorrect locally? c:\Repos\PowerToys.pipelines>restore-telemetry.cmd c:\Repos\PowerToys.pipelines>cd /D "c:\Repos\PowerToys.pipelines" c:\Repos\PowerToys.pipelines>call nuget.exe restore -ConfigFile nuget.config packages.config || exit /b 1 All packages listed in packages.config are already installed. c:\Repos\PowerToys.pipelines>move /Y "Microsoft.PowerToys.Telemetry.1.0.0\build\include\TraceLoggingDefines.h" "..\src\common\Telemetry\TraceLoggingDefines.h" || exit /b 1 The system cannot find the file specified. From: Enrico Giordani<EMAIL_ADDRESS>Sent: Monday, February 24, 2020 8:37 AM To: microsoft/PowerToys<EMAIL_ADDRESS>Cc: Ryan Bodrug<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/PowerToys] [CDPx] update SDK, restore telemetry, build MSIX (#1358) @ryanbodrug-microsofthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryanbodrug-microsoft&data=02|01|ryanbod%40microsoft.com|efca442351aa403c10a308d7b947cb69|72f988bf86f141af91ab2d7cd011db47|1|0|637181590319639026&sdata=JcvgjaqyCbiHKWuwortXOAvWVqCWSZ1zuNjnTWeOpJg%3D&reserved=0 Ryan, you can give it a try locally to check if the scripts to restore and build the project work on your machine before we merge this and trying to kick off a build. In the .pipeline folder, using a VS 2019 command prompt, you can execute the following scripts individually. * restore.cmd * restore-installer.cmd * restore-telemetry.cmd * build.cmd * build-installer.cmd * msix\build-msix.cmd Let me know if you have any question. Thanks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPowerToys%2Fpull%2F1358%3Femail_source%3Dnotifications%26email_token%3DANNVUNNVRAYRWBZPGGSYOYLREPZTLA5CNFSM4K2LUWQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMYSIQI%23issuecomment-590423105&data=02|01|ryanbod%40microsoft.com|efca442351aa403c10a308d7b947cb69|72f988bf86f141af91ab2d7cd011db47|1|0|637181590319639026&sdata=t7ajlbwyG77Q62BaXDIdcdJT0t%2B%2FoSij6c6pCgUl8lM%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANNVUNMEBSRPMYQHGQWWOLTREPZTLANCNFSM4K2LUWQA&data=02|01|ryanbod%40microsoft.com|efca442351aa403c10a308d7b947cb69|72f988bf86f141af91ab2d7cd011db47|1|0|637181590319649020&sdata=fSXV2rCl2MRd9YQ3oDGVr3SFgO%2F4Y1RKxAMzTSsJAbU%3D&reserved=0.

It's using the wrong nuget.config locally.  In the restore.cmd, and restore-installer.cmd.
NuGet Config files used:
C:\Users\ryanbod\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

. restore.cmd, and restore-installer.cmd worked for me, but I’m getting the following error from restore-telemetry.cmd. I’m guessing the package source for Microsoft.PowerToys.Telemetry.1.0.0. is incorrect locally? c:\Repos\PowerToys.pipelines>restore-telemetry.cmd c:\Repos\PowerToys.pipelines>cd /D "c:\Repos\PowerToys.pipelines" c:\Repos\PowerToys.pipelines>call nuget.exe restore -ConfigFile nuget.config packages.config || exit /b 1 All packages listed in packages.config are already installed. c:\Repos\PowerToys.pipelines>move /Y "Microsoft.PowerToys.Telemetry.1.0.0\build\include\TraceLoggingDefines.h" "..\src\common\Telemetry\TraceLoggingDefines.h" || exit /b 1 The system cannot find the file specified.

It's using the wrong nuget.config locally. In the restore.cmd, and restore-installer.cmd.
NuGet Config files used:
C:\Users\ryanbod\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

This appears expected the restore-telemetry.cmd references the correct .nuget config.  I'm able to hit the correct feed after removing the telemetry package from my local package root, however now I get a 401 on the feed.

c:\Repos\PowerToys.pipelines>dotnet add "..\src\modules\fancyzones\editor\FancyZonesEditor\FancyZonesEditor.csproj" package "Microsoft.PowerToys.Telemetry"
Writing C:\Users\ryanbod\AppData\Local\Temp\tmpC099.tmp
info : Adding PackageReference for package 'Microsoft.PowerToys.Telemetry' into project '..\src\modules\fancyzones\editor\FancyZonesEditor\FancyZonesEditor.csproj'.
info : Restoring packages for c:\Repos\PowerToys\src\modules\fancyzones\editor\FancyZonesEditor\FancyZonesEditor.csproj...
error: Unable to load the service index for source https://1essharedassets.pkgs.visualstudio.com/_packaging/Artifact%40Release/nuget/v3/index.json.
error:   Response status code does not indicate success: 401 (Unauthorized).

. restore.cmd, and restore-installer.cmd worked for me, but I’m getting the following error from restore-telemetry.cmd. I’m guessing the package source for Microsoft.PowerToys.Telemetry.1.0.0. is incorrect locally? c:\Repos\PowerToys.pipelines>restore-telemetry.cmd c:\Repos\PowerToys.pipelines>cd /D "c:\Repos\PowerToys.pipelines" c:\Repos\PowerToys.pipelines>call nuget.exe restore -ConfigFile nuget.config packages.config || exit /b 1 All packages listed in packages.config are already installed. c:\Repos\PowerToys.pipelines>move /Y "Microsoft.PowerToys.Telemetry.1.0.0\build\include\TraceLoggingDefines.h" "..\src\common\Telemetry\TraceLoggingDefines.h" || exit /b 1 The system cannot find the file specified.

It's using the wrong nuget.config locally. In the restore.cmd, and restore-installer.cmd.
NuGet Config files used:
C:\Users\ryanbod\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

I'll make sure my enviroment is clean and update here.

. restore.cmd, and restore-installer.cmd worked for me, but I’m getting the following error from restore-telemetry.cmd. I’m guessing the package source for Microsoft.PowerToys.Telemetry.1.0.0. is incorrect locally? c:\Repos\PowerToys.pipelines>restore-telemetry.cmd c:\Repos\PowerToys.pipelines>cd /D "c:\Repos\PowerToys.pipelines" c:\Repos\PowerToys.pipelines>call nuget.exe restore -ConfigFile nuget.config packages.config || exit /b 1 All packages listed in packages.config are already installed. c:\Repos\PowerToys.pipelines>move /Y "Microsoft.PowerToys.Telemetry.1.0.0\build\include\TraceLoggingDefines.h" "..\src\common\Telemetry\TraceLoggingDefines.h" || exit /b 1 The system cannot find the file specified.

It's using the wrong nuget.config locally. In the restore.cmd, and restore-installer.cmd.
NuGet Config files used:
C:\Users\ryanbod\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

I'll make sure my enviroment is clean and update here.

I'll also currently don't have access to the feed.  I'll see if I can get access.

@enricogior:
Most scripts seem to work for me.
For restore-telemetry.cmd I had to make the following changes locally for it to work (this shouldn't affect the build pipeline):

remove the cached telemetry package from my user directory
update my nuget.exe version to the latest to use Integrated Windows Login for authentication.

I'm not able to run build-msix.cmd
.  My version of makeappx doesn't seem to be aware of the build command.  Is there a specific version I should be updating.  I couldn't find any docs on the build command either.

Ryan,
after you run restore-telemetry.cmd, do you have a folder called Microsoft.PowerToys.Telemetry.1.0.0 in .pipeline/?
Even if that command fails for you locally, you can proceed with the build commands since the telemetry restore only overwrites an existing file, so it's a step can can be skipped when testing the other scripts.

From: Ryan Bodrug<EMAIL_ADDRESS>Sent: Monday, February 24, 2020 7:44 PM
To: microsoft/PowerToys<EMAIL_ADDRESS>microsoft/PowerToys<EMAIL_ADDRESS>Enrico Giordani (Janea Systems Inc<EMAIL_ADDRESS>Cc: Mention<EMAIL_ADDRESS>Subject: RE: [microsoft/PowerToys] [CDPx] update SDK, restore telemetry, build MSIX (#1358)
@Enrico Giordani (Janea Systems<EMAIL_ADDRESS>restore.cmd, and restore-installer.cmd worked for me, but I’m getting the following error from restore-telemetry.cmd.  I’m guessing the package source for Microsoft.PowerToys.Telemetry.1.0.0. is incorrect locally?
c:\Repos\PowerToys.pipelines>restore-telemetry.cmd
c:\Repos\PowerToys.pipelines>cd /D "c:\Repos\PowerToys.pipelines"
c:\Repos\PowerToys.pipelines>call nuget.exe restore -ConfigFile nuget.config packages.config   || exit /b 1
All packages listed in packages.config are already installed.
c:\Repos\PowerToys.pipelines>move /Y "Microsoft.PowerToys.Telemetry.1.0.0\build\include\TraceLoggingDefines.h" "..\src\common\Telemetry\TraceLoggingDefines.h"   || exit /b 1
The system cannot find the file specified.
Here are the last 2 commits I have.
<EMAIL_ADDRESS>From: Enrico Giordani<EMAIL_ADDRESS>Sent: Monday, February 24, 2020 8:37 AM
To: microsoft/PowerToys<EMAIL_ADDRESS>Cc: Ryan Bodrug<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [microsoft/PowerToys] [CDPx] update SDK, restore telemetry, build MSIX (#1358)
@ryanbodrug-microsofthttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fryanbodrug-microsoft&data=02|01|v-engior%40microsoft.com|9f138140df4d468326f608d7b9599c11|72f988bf86f141af91ab2d7cd011db47|1|0|637181666912184625&sdata=Yf8ZMsQvNKaN8XfMSdI27ld7dBcfWRg5BQh5zzLv%2F6M%3D&reserved=0
Ryan, you can give it a try locally to check if the scripts to restore and build the project work on your machine before we merge this and trying to kick off a build.
In the .pipeline folder, using a VS 2019 command prompt, you can execute the following scripts individually.

restore.cmd
restore-installer.cmd
restore-telemetry.cmd
build.cmd
build-installer.cmd
msix\build-msix.cmd

Let me know if you have any question. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2FPowerToys%2Fpull%2F1358%3Femail_source%3Dnotifications%26email_token%3DANNVUNNVRAYRWBZPGGSYOYLREPZTLA5CNFSM4K2LUWQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMYSIQI%23issuecomment-590423105&data=02|01|v-engior%40microsoft.com|9f138140df4d468326f608d7b9599c11|72f988bf86f141af91ab2d7cd011db47|1|0|637181666912194618&sdata=Fb76pdfahVMC5KNZ92Wdjrmdm6G8pU2C%2B%2FDaOLHZLb4%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FANNVUNMEBSRPMYQHGQWWOLTREPZTLANCNFSM4K2LUWQA&data=02|01|v-engior%40microsoft.com|9f138140df4d468326f608d7b9599c11|72f988bf86f141af91ab2d7cd011db47|1|0|637181666912194618&sdata=DrGl8%2BoJ31DMSjVEJvd571Ouniw5Osdd0gXZDev7j1c%3D&reserved=0.

My version of makeappx doesn't seem to be aware of the build command.

No idea why that is happening for you.

Thanks for testing, even with the couple of issues you run into, I think we are good enough to give it a try and merge it so we can kick-off a build.

Thanks for testing, even with the couple of issues you run into, I think we are good enough to give it a try and merge it so we can kick-off a build.

Sounds good.  The first issue for me was an old version of nuget.exe, I suspect its a similar issue for makeappx as well.

@ryanbodrug-microsoft
can you approve the PR? Thanks.


Temporarly set user_options for test users and leap hubs

Fixes https://github.com/2i2c-org/infrastructure/issues/2146
A persistent fix requires some cleanup related to profile handling in kubespawner so that it's easier to see where default settings are failing or if they are inconsistent.

hmm ⬆ modifying the test, shouldn't actually trigger the hubs to deploy. Maybe we can exclude this test file from the triggers

I think we should actually just put the deployer in it's own repo

@sgibson91, until then, I've opened https://github.com/2i2c-org/infrastructure/pull/2866

Opened https://github.com/2i2c-org/infrastructure/issues/2869 to track reverting this. Thank you!


[RSR-522] - COMPAS CORE - Update XSD file

The US purpose is to update the new COMPAS XSD file in attachement into COMPAS Core: compas-core/scl-extension/src/main/resources/xsd at develop · com-pas/compas-core · GitHub
Impacts:
compas-core/scl-extension/src/main/bindings/scl-extensions.xjb => tSclFileType type to be updated

SCL_CoMPAS_20220614.zip
Update of the CoMPAS XSD from 14.06.2022

Compas XSD fixed
SCL_CoMPAS_20220615.zip

List of updates done on the new COMPAS CORE XSD:

The "CompasConnectivityNode" private has been removed. The ZoneNumber attribute is now placed into "CompasBay" private and is renamed BayCount attribute.

The "CompasTopo" private has been created with its 3 attributes " Node", "NodeOrder" and "Direction". It is describe the topology of a bay

The new Enum "CompasTopoNodeDirection"  with "Up" and "Down" values associated with the "CompasTopo" private and "Direction" attribute


Add cupy.union1d API.

Hi, Team!!
The PR aims to add cupy.union1d API. It follows #6078.
I would love to get your feedback.
Thanks! :)

/test mini

Thanks for your work! It's almost fine except for a test method I mentioned above.

Hi, @takagi!
Thanks a lot for reviewing! :)
That test case was wrong (I had a different thing in my mind), anyways I made the required corrections :) Thank you!
Will you please take a look? Thanks!

/test mini

LGTM! Waiting for CI pass to merge.


Tweak CI versions (add 24.0)

I quoted the versions, since those are strings (e.g. 24.0 is understood as 24, a number).

If 9ccf511 doesn't fix CI, I'll propose setup-beam as an alternative.

CI starts for 24, but there's a test that's failing... the action's empty output is not very helpful, though 😄

Bump.

Bump, @talentdeficit.


igv.js view on variant details page does not "jump" to SV position

Describe the bug
The IVG view on the variant details page for SV (GRCh38) shows the whole genome (chr1-22, X and Y) instead showing the region, where the SV is localized. Region is set to all.
I can enter the position manually in the IGV view (eg chr1:20,605,522-20,606,197) and then the IGV jumps to the correct position. However, the tracks which are shown for GRCh37, eg DGV, gnomAD SV ... are not visible. Maybe the bed files for the tracks are missing for GRCh38?
Something really weird happened, if I scroll during loading of the SV variant details page. Then the IGV view shows the "right" position, but with the hg19 genome build. Which is of cause then the wrong position in this genome build. Maybe related to https://github.com/varfish-org/varfish-server/issues/1525
To Reproduce
Steps to reproduce the behavior:

open a case
click on "Filter SV"
click on "Filter&Display"
click on a variant in the list
scroll to IVG view on variant details page

Expected behavior
IGV view should show the position matching to the SV and should show tracks indicating SV in this region from gnomAD SV, DGV etc.
Screenshots
IGV view only show "all"

IGV view after manually entering the position

IGV view with hg19, after scrolling during variant details page loading

Desktop (please complete the following information):

OS: Win10
Browser Firefox
Version 124.0.0

Smartphone (please complete the following information):
n/a
Additional context
n/a

Will be closed with https://github.com/bihealth/reev-frontend-lib/pull/203


Fixing ignoreErrors section of PHPStan file

Regexes in the phpstan.neon file where accepting too wide errors.
Thanks to @ondrejmirtes recent changes in PHPStan, PHPStan now detects those potential errors.
I fixed the regexes... and PHPStan found 42 errors :open_mouth:
Let's fix those.

Great :)


Refactored ClusterInit, receiver per kind instead of per activation

Identity will now be retrieved from the actor-local context store, eliminating the need for a specific receiver per identity.

Pulling this in


JSON format dependency list (BOM)

Hi, I am trying to analyze a massive of maven projects using eclipse steady plugin. I need both the dependency list and the CVE list. But steady:report  only provides CVE lists and their related dependencies. If I want to get the full BOM, I have to go to the webpage, which is a nightmare for batch operation.
I am wondering are there any configurations that I missed that can help me get the full BOM list?
If not, is there any possibility you can provide the feature to generate an aggregate dependency list report locally? Preferring JSON format. :smile:

solved, actually, I can get the list through the internal API.
get deps: {backend_url}/apps/{group}/{artifact}/{version}/deps
get vulns: {backend_url}/apps/{group}/{artifact}/{version}/vulndeps


added chrome workaround for Access-Control-Request-Headers with empty string

See https://github.com/agrueneberg/Corser/issues/18

Good job, thanks!

Sorry, in all this excitement I hit the wrong button :)


Test Debug - fork.c/forkandopen.c

per 150
It seems like theres fd table replication issues on fork. Both of these are failing immediately after fork when trying to pen runnable-ld.so
[1760,3685512768:13:24:20.307099] [nap 1] new child count: 1
[1760,3685512768:13:24:20.307102] fork_num = 1, cage_id = 2
[1760,3685512768:13:24:20.307105] NaClHostDescOpen(0x55e4c1343660, /lib/glibc/runnable-ld.so, 0x0, 0x1b6)
[1760,3685512768:13:24:20.307108] NaClHostDescOpen: invoking POSIX open(/lib/glibc/runnable-ld.so,0x0,0600)
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/safeposix/dispatcher.rs:90:58
stack backtrace:
   0: rust_begin_unwind
             at /rustc/003d8d3f56848b6f3833340e859b089a09aea36a/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/003d8d3f56848b6f3833340e859b089a09aea36a/library/core/src/panicking.rs:100:14
   2: core::panicking::panic
             at /rustc/003d8d3f56848b6f3833340e859b089a09aea36a/library/core/src/panicking.rs:50:5
   3: dispatcher
   4: lind_open
             at /home/lind/lind_project/src/native_client/src/shared/platform/lind_platform.c:117:5
   5: NaClHostDescOpen
             at /home/lind/lind_project/src/native_client/src/shared/platform/posix/nacl_host_desc.c:314:15
   6: NaClDescIoDescOpen
             at /home/lind/lind_project/src/native_client/src/trusted/desc/nacl_desc_io.c:187:12
   7: NaClAppLoadFileFromFilename
             at /home/lind/lind_project/src/native_client/src/trusted/service_runtime/load_file.c:23:28
   8: NaClChildNapCtor
             at /home/lind/lind_project/src/native_client/src/trusted/service_runtime/nacl_app_thread.c:113:22
   9: NaClSysFork
             at /home/lind/lind_project/src/native_client/src/trusted/service_runtime/nacl_syscall_common.c:4081:15
  10: NaClSysForkDecoder
             at /home/lind/lind_project/src/native_client/scons-out/dbg-linux-x86-64/gen/native_client/src/trusted/service_runtime/nacl_syscall_handlers.c:4692:10
  11: NaClSyscallCSegHook
             at /home/lind/lind_project/src/native_client/src/trusted/service_runtime/nacl_syscall_hook.c:149:15
  12: <unknown>
             at /home/lind/lind_project/src/native_client/src/trusted/service_runtime/arch/x86_64/nacl_syscall_64.S:211
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5

I fixed the fork bug with the last PR.
forkandopen now works, but I found some weird behavior with fork.c
Namely we get a dup error, even though dup isnt called in the program! And something triggers a waitpid perrror. May be related.
waitpid(): No child processes```

Ok so that waitpid perror is just because the child is exiting first and isnt an actual error. I fixed the dup problm in a PR over on the rustposix repo.