Limit Dockerfile to a specific version ID

FEATURE REQUEST
As Dockerfile build instructions are still changing, I miss the possibility to tag somehow the minimal supported version to clearly state minumum requirements on the building system. - as we know it from Maven. (Yes after all the system would spit buckets of ambigous errors, so I thought a more declarative style might be a benefit)
Something like
LANGUAGE_VERSION=1.9
would me in my opinion really helpful!
thanks. :)

If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
For more information about reporting issues, see CONTRIBUTING.md.
You don't have to include this information if this is a feature request
(This is an automated, informational response)

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

I think this is a duplicate of an issue I opened a long time ago; https://github.com/docker/docker/issues/4907.
However, the Dockerfile syntax is currently frozen, so we currently cannot accept changes to the Dockerfile syntax; https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax

I understand maven so I instantly understand what this could do for us. If it were easier to change the builder, and we weren't in a freeze, I think it would help solve a lot of problems that require us to have the freeze. I think having a version that is respected by the builder, it becomes easy to do a clean split of previous functionality to new functionality (Not that a refactor or rewrite of the builder would be easy, this would isolate any effects). This could be a really good first steep to allowing experimentation with builder changes.

Closing this issue as inactive in efforts to make issue list cleaner. Feel free to open new proposal.


Actions run onClick but not in class handlers

I just started using Redux Zero and came across an issue, I am most certainly making a mistake!
When I use onClick={action} , state is successfully updated and everything is great :)
When I move {action} into my class handler onClick{this.handleRefresh}, state is not updated and the function is not called.
I've attached my full setup.
React V16
actions.js
import store from './store';

export const refreshingOn = () => {
	store.setState({
		refreshStatus: true
	});
};

export const refreshingOff = () => {
	store.setState({
		refreshStatus: false
	});
};

LibraryRefreshIcon.js
import React, { Component } from 'react';
import RefreshIcon from 'material-ui-icons/Refresh';
import './LibraryRefresh.css';
import { connect } from 'redux-zero/react';
import { refreshingOn, refreshingOff } from '../../containers/Root/actions';

const mapToProps = ({ refreshStatus }) => ({ refreshStatus });

class LibraryRefreshIcon extends Component {
	constructor(props) {
		super(props)
		this.state = {
			iconStyle		: 'libraryRefreshIcon',
		};
	}

	handleRefresh = () => {
		console.log(refreshingOn);
		this.setState({
			iconStyle: 'libraryRefreshIconAnimation',
		});
		{refreshingOn}

		setTimeout( () => {
			this.setState({
				iconStyle		: 'libraryRefreshIcon',
			});
			{refreshingOff}
		}, 400);
	}

	render() {
		console.log(this.props);
		console.log(refreshingOn);
			return (
			<div className='libraryRefreshIconContainer'>
				<RefreshIcon onClick={this.handleRefresh} className={this.state.iconStyle}/>
			</div>
		);
	}
}

export default connect(mapToProps)(LibraryRefreshIcon);

Thanks for anyhelp! I found Redux to be really complicated and Zero already feels much easier to learn/use. Thank you :)

I'm a noob :)
you can run actions in handlers by using action() - just needed the parenthesis.
Redux zero is great.

No problem @brenwkennedy
Sorry for not answering this earlier :(


Add FLATCC_BUILD_INTO_SOURCE_DIR cmake option

FLATCC_BUILD_INTO_SOURCE_DIR controls the built destinations of libraries and executables.
Some flatcc users need both local and cross-compiled versions of the binaries, so it's helpful to build them into the cmake binary directory instead of into the source tree.
And when they're built into a directory with Release or Debug path components, the _d suffixes are not necessary.

Hello! I'm happy to make changes here: the name of the option, adding a separate option for the _d part, splitting out a separate PR for the _d part.
This helps avoid a race condition in our build, where we need both host and cross-compiled target builds of flatcc. Here's the patch for how I'll be able to simplify our build once this PR goes in: https://github.com/pytorch/executorch/commit/db31f4961e8a576af93af34dbbc43965ee1edec9. And simplification aside, it avoids a currently unavoidable race condition in some of our environments, depending on when the host and target binaries are built.

This looks reasonable.
I don't have the full overview of CMake but I can see this being useful.
It is incredibly helpful to just have $FLATCC/bin and $FLATCC/lib, and the _d suffix for debugging, but it is not a universal solution.
Another option is to copy files after building so we don't need the discrepancy between build types, at least for non-cross builds.
It seems that you have done the right thing, but please make VERY sure it will not break default behaviour.
If you think consolidation to earlier location makes more sense, per you comments, please go ahead, as long as it does not affect the intended behaviour.

We need some update to README as well, once we settle on the solution.

Thank you for taking a look, @mikkelfj!

Another option is to copy files after building so we don't need the discrepancy between build types, at least for non-cross builds.

This didn't work for us because when building in parallel, both the host and cross-compiled targets will try to build to the same location under the source tree, causing a race condition. Depending on when the copy happened, we would randomly get the host binary or the cross-compiled binary.

please make VERY sure it will not break default behaviour.

(For the record, I ran the following tests on an M1 macbook using AppleClang <IP_ADDRESS>00026)
I wrote a test script at https://gist.github.com/dbort/5cc082098cfe681402c5d0ac71403615 to build with scripts/build.sh with and without this PR. https://gist.github.com/dbort/b13f59ae9b87d472c05b08369e9c3554 shows the output: the same set of files are created under the lib and bin directories.
flatcc-test:INFO: Manifests are identical:
-----BEGIN-----
bin/flatcc
bin/flatcc_d
lib/libflatcc.a
lib/libflatcc_d.a
lib/libflatccrt.a
lib/libflatccrt_d.a
-----END-----
PASS

I also tested the behavior with this new option disabled:
echo "FLATCC_BUILD_FLAGS=-DFLATCC_BUILD_INTO_SOURCE_DIR=OFF" > scripts/build.cfg.pr306
./scripts/initbuild.sh pr306
./scripts/build.sh
ls bin lib build/{Debug,Release}/{bin,lib}

This shows that the built binaries and libraries are not in the source tree, and are under the appropriate build config directories:
bin:

build/Debug/bin:
flatcc

build/Debug/lib:
libflatcc.a	libflatccrt.a

build/Release/bin:
flatcc

build/Release/lib:
libflatcc.a	libflatccrt.a

lib:

I'm happy to add more tests to these scripts, if you have other files or CMake variables that you'd like me to compare, or if you'd like me to test different build configurations.

Also, what parts of the README do you suggest that I should update?

Hi @mikkelfj, could you please take a look at my testing if you have a chance? We're running into more build issues related to binaries-in-tree and "_d" suffixes, and it would help us a lot if we were able to merge this change, if you're ok with it.

I am using ninja multi config setup and I have used
        "FLATCC_INSTALL": "ON",
        "FLATCC_INSTALL_LIB": "${sourceDir}/build/${presetName}/vendor/executorch/lib"

to specify the destination, FLATCC_INSTALL_LIB.
Sharing with you as I see your change does manual steps instead.

@ykhrustalev thanks for pointing that out! FLATCC_INSTALL_LIB looks like it would let us separate host and target libraries. I'll see if it helps us fix our current breakage.
I'd still like to merge this PR if possible so that we can build flatcc using the same conventions that most cmake projects use. FLATCC_INSTALL_LIB is relative to the repo root, so we'd need to use ../ components to put the binaries in the project-level cmake output tree. (We use flatcc as a submodule, so our build artifacts typically live in a higher-level build directory.) FLATCC_INSTALL_LIB also doesn't let us change the bin/ outputs, and it still adds the _d suffixes for debug mode.


Fix typo in UpperServlet class

Typo in the output text that says "capitalize" instead of "upper case"

Completed.


Add support for NIRx fNIRS data in SNIRF format

Describe the new feature or enhancement
We currently have a SNIRF reader that works with files produced using the society for fNIRS approved generator/converter.
However, there is quite some flexibility in the specification. Further, we only support a subset of the specifiation (for example we do not support anything other than continuous wave spectroscopy, and we dont support 2D locations).
NIRx now export their data as SNIRF. This is great. However, they do not export some fields that are optional in the spec. And currently our reader expects these data fields. So the reader needs to be modified to be forgiving if these optional fields are missing, or it needs to throw a usefull error.
Describe your proposed implementation
I have recorded some data with a NIRScout2 device in snirf format. I will add this to the test data repository and I will then update our reader to gracefully handle these missing fields.
My initial investigation indicates that the fields we need to not expect are

/nirs(i)/probe/sourceLabels
/nirs(i)/probe/detectorLabels

so this shouldnt be too much work for me.
I will also use this oppurtunity to all other fields we expect are "required" and try not to rely on optional fields.
Additional comments
I am writing this here so everyone knows and does not try to duplicate effort.
I will also address https://github.com/mne-tools/mne-nirs/issues/257
This will not address https://github.com/mne-tools/mne-python/issues/9308
FYI @robquant @HanBnrd @larsoner

In the case that these fields are missing I am going to assign the following naming structure...

Sources: S1, S2, S3, etc
Detectors: D1, D2, D3, etc

All sounds good @rob-luke !


fix server side rendering issue

Same as https://github.com/ApoorvSaxena/lozad.js/pull/119
We are using lozad in the react app with server side rendering. Our app was crashing on server side rendering because window doesn't exist in node.js (ReferenceError: window is not defined). This change is fixing that issue.

hi, Is there any plan to release this fix? thanks


Fix debug mode

This fixes the crash found in Issue #327, where two memcopy's are trying to transfer data larger than the array size since those arrays were destacked when moved over to Alpaka.

@YonsiG Can you check that the output ntuple looks good before this is merged? Thank you.

@YonsiG Can you check that the output ntuple looks good before this is merged? Thank you.

Hi Gavin, I checked that before and after this PR the output ntuple looks good. And after this PR, the debug branches can be stored in the root files normally. Thanks!


chore(package): update validate-commit-msg to version 2.10.0

https://greenkeeper.io/

Storybook Hub is building storybooks for every commit in this PR.
Latest Storybook: https://f4880f39-3289-46b4-a13c-c2e31be02c97.sbook.io/
( Visit here for more info )

This comment is automatically added by Storybook Hub


[PDI-18257] - Metadata Injection configuration error on Table Output …

…step
@pentaho-lmartins
@pentaho/tatooine

:white_check_mark: Build finished in 17m 23s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3622, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 23m 47s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3622, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 22m 13s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3623, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 23m 49s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3623, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message

:white_check_mark: Build finished in 24m 8s
Build command:
mvn clean verify -B -e -Daudit -amd -pl engine

:ok_hand: All tests passed!
Tests run: 3623, Failures: 0, Skipped: 7    Test Results

:information_source:  This is an automatic message


nomad-autoscaler: init at 0.3.3

Motivation for this change
Autoscaling plugins for nomad
Added the withPlugins so that people didn't have to install all of the plugins which are about ~185MB.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
21.11 Release Notes (or backporting 21.05 Relase notes)

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

[ ] Fits CONTRIBUTING.md.

calling some people from #128516
cc @Chili-Man @balsoft

Result of nixpkgs-review pr 128117 run on x86_64-linux 1

1 package built:

nomad-autoscaler


https://github.com/SpiderLabs/ModSecurity/issues/533

PR for issue 533

Unclean PR, to be replaced by another one


Add restartableInputStream, first commit

PTAL -
@garrettjonesgoogle Not finished yet, just to make sure the idea aligns with #2620

@vam-google , could you review this?

@hzyi-google could you address @vam-google 's comments?

A lot of changes need to be made for this, so abandoning. With submit a different PR when finished.


Rename files as describe in #261

These are the last of the files @janodvarko has already done a few before this issue was open.

Pull Request #258 also contains file renames.


Project icon as favicon in HTML5 WebAssembly export

Operating system or device, Godot version, GPU Model and driver (if graphics related):
Firefox 57 and Chromium 62 under Archlinux 64bits, Godot compiled today 33ffdba553e90471150bd84067c88a79e874a2aa and WebAssembly template idem
Issue description:
This can be done manually, but it would be great if Godot could export automatically the project icon as a favicon in HTML5.
I know this was partially answered in #12543:

We need ability for users to add a custom icon for their executable, not have to rely on resource hacker

Problem with this is that it seems to be only doable when exporting from Windows. Cant be done from other platforms. All libraries we tried to do this ended up corrupting the executable.

but as far as I understand this do not apply to HTML5 because it's not about writing it to an executable, but a matter of copying the .png file, renaming to favicon.png, and linking in the HTML file.
For now, the debug console in the browser is complaining about icon missing:
**ERROR**: Error opening file: res://icon.png
**ERROR**:    At: core/io/image_loader.cpp:54:load_image() - Error opening file: res://icon.png

Thanks for your answer and work !

Sounds good to me, and shouldn't be too hard to implement. cc @eska014


Number of actions in deep SARSA grid world

Why does the implementation (deep_sarsa_agent.py) have action_space = [0, 1, 2, 3, 4] when there are only 4 possible actions that the agent can take (as specified in the environment.py)?
Thanks,
Akilesh

Hi, Akilesh.
up, down, left, right, stay(don't move) 5 possible actions are exist.
Thanks,
Hyeokreal

Thanks Hyeokreal.


PhreshPlayer app added.

Your app is live on the site now. Sorry for the delay! https://electronjs.org/apps


remove: Remove unnecessary judgment about debug log level

Change-Id: I3fc59f63420e9e89441a116e0f7fbaec0eb032fc

[x] I understand that this repository is auto-generated and my pull request may not be merged

Changes being requested
Additional context & links

In the Python official library, the debug method already has a level judgment, so there is no need to repeat the judgment

The reason that check is there is to avoid paying the performance cost of calling model_dump(), pydantic methods like that aren't free


fix search_mr bug for unlimited bar1

 if (conn->local_mr.find((uintptr_t)base_ptr) == conn->local_mr.end()) {
    IBVMemoryRegion *mr = new IBVMemoryRegion(conn->pd, base_ptr, ptr_region_size);
    conn->local_mr[(uintptr_t)base_ptr] = mr;
    mr->add_ref();
}

when register as base_ptr,  we should use base_ptr to find.
We conducted extensive stress testing using a pressure testing tool and occasionally encountered the error message, “Failed to find lkey from ptr {}, reason 2.”
Upon analysis, the cause was found to be related to the lookup method using base_ptr + offset. This method could sometimes locate other previously registered memory blocks (mem) that satisfy the condition it->first <= (uintptr_t)ptr but do not satisfy (uintptr_t)ptr < it->first + it->second->get_mr()->length.
In such cases, the length of these previously registered memory blocks was insufficient for the base_ptr + offset calculation.

Thank you so much for your PR!


Fix streaming logs for tty

@nahiluhmot
Streaming logs does not return anything when used with a TTY.

Looks good, but would it be valuable to add a test for this?

Added tests.

Awesome, :+1:


Bump Dependencies #3565973051

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

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


Favicon plugin causes a crash if no link is included

Current behaviour
If the HTML file does not include a <link rel="icon"> tag and the FaviconBundlerPlugin is enabled, webpack crashes with the following traceback:
  throw new Error('Tap function (tapPromise) did not return promise (returned ' + _promise1 + ')');
        ^

Error: Tap function (tapPromise) did not return promise (returned undefined)
    at _next0 (eval at create (/home/ginger/vyxal.github.io/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:33:9)
    at eval (eval at create (/home/ginger/vyxal.github.io/node_modules/tapable/lib/HookCodeFactory.js:33:10), <anonymous>:52:1)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Expected behaviour
The plugin should probably throw an error explaining that the file lacks a link tag.
Reproduction Example
Create an HTML file without a <link rel="icon"> tag, enable the FaviconBundlerPlugin, and attempt to bundle it with the HtmlBundlerWebpackPlugin.
Environment

OS: Linux
version of Node.js: v18.13.0
version of Webpack: 5.89.0
version of the Plugin: 3.4.0

Hello @GingerIndustries,
thank you for the issue report.
I wil fix it.

it is a really special use case <link rel="icon"> or it's an user error? Should be this tag ignored or should an exception occur?

it is a really special use case <link rel="icon"> or it's an user error? Should be this tag ignored or should an exception occur?

I'm of the opinion that if the plugin is enabled but the page lacks a favicon it's an error, since why would they have the plugin if they didn't have a favicon to use it with?

I'm of the opinion that if the plugin is enabled but the page lacks a favicon it's an error, since why would they have the plugin if they didn't have a favicon to use it with?

yes/no

if the favicon plugin is used but no favicon found, this is an user error, not plugin error. User self should check the generated result and see whether all is correct
if no favicon was detect, then the  favicon plugin should do nothing, just ignore it, no throw an error, because it brake compilation process (the HTML w/o favicon is valid)
if in Webpack config are configured CSS, images loaders and no CSS or images was in entry detected, the Webpack throw no exception
if html-bundler-webpack-plugin is configured with entry as a path to html templates and the entry directory is empty, this is no error too, just will be nothing rendered

All use cases such as <link rel="icon"> or <link invalid-href="./favicon.png" rel="icon" /> or the link tag is missing are the same. The plugin doesn't analyse whether any <link> tag exists or not in HTML. The plugin detect and resolve only attributes (href, src, etc) by tags. If any resolvable attribute is missing, then plugin do nothing, HTML stay as is.
Also, I will resolve this case (Favicon file is not found) w/o an exception.

But I can display a warning in the console without breaking compilation, for example:

Warning
Favicon file is not found!
If the FaviconsBundlerPlugin is used, at last one favicon source file should be defined, e.g.:
<link rel="icon" href="path/to/source/favicon.png">

@GingerIndustries
the crashing is fixed, in this case will be display a warning.
Please check the version 3.4.3.

Cool, thanks!


This project works with Swarm?

I wanted to play with Swarm locally by creating three virtual machines and instantiating docker in each. Would it be possible to use Swarm with this application? It looks more robust than the kitematic.
cheers

Hi @MichelDiz right now we don't have full support Docker Swarm. We have tools for connecting to remote nodes. We're planning to integrate Swarm and many other tools for deployment. But I can't say how soon it will be because for fast realization of a plan we need to find few payment clients or some IT companies which will support our development.


[SPARK-25174][YARN]Limit the size of diagnostic message for am to unregister itself from rm

What changes were proposed in this pull request?
When using older versions of spark releases,  a use case generated a huge code-gen file which hit the limitation Constant pool has grown past JVM limit of 0xFFFF.  In this situation, it should fail immediately. But the diagnosis message sent to RM is too large,  the ApplicationMaster suspended and RM's ZKStateStore was crashed. For 2.3 or later spark releases the limitation of code-gen has been removed, but maybe there are still some uncaught exceptions that contain oversized error message will cause such a problem.
This PR is aim to cut down the diagnosis message size.
How was this patch tested?
Please review http://spark.apache.org/contributing.html before opening a pull request.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/2413/
Test PASSed.

Test build #95073 has started for PR 22180 at commit 8f5b67a.

Test build #95073 has finished for PR 22180 at commit 8f5b67a.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95073/
Test PASSed.

cc @gatorsmile @vanzin

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/2468/
Test PASSed.

Test build #95132 has started for PR 22180 at commit 3271c3f.

Test build #95132 has finished for PR 22180 at commit 3271c3f.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/95132/
Test PASSed.

Looks good, merging to master.


ItemList Input Freeze

Godot version
v4.0 alpha8
System information
Windows 10
Issue description
Pressing any key other than the ui_up/down/left/right keys will freeze the ability to move between items in an ItemList for a couple of seconds.
As I show in the video by logging my keys, as soon as I press any key other than up or down the ItemList will ignore my inputs.
The ItemList stays focused the whole time. Either pressing the enter, spacebar, left or right key or waiting for a couple of seconds will resume normal behaviour.
https://user-images.githubusercontent.com/12717313/168495863-10c0696d-4c5d-450a-bc33-59f18eac8057.mp4
Expected behaviour is of course for the ItemList not to ignore inputs when pressing keys other than the ui_up and down keys.
Steps to reproduce
New Project:

Create a Node2D scene
Add an ItemList (CanvasLayer as shown in the video is not required)
Add a couple of items to the ItemList
Run the program
Use the default ui_up and ui_down keys to move between items
Press any other key to freeze any further movement for a couple of seconds

Minimal reproduction project

Follow steps 4-6

Minimal reproduction project
ItemList Bug.zip

This is likely because the "autocompletion" behavior (which jumps to the item that matches the string you're typing) intercepts arrow keys. It probably shouldn't.
For reference, this "autocompletion" behavior is also present on item lists in your OS' file manager. Try opening a folder with lots of files and start typing some letters :slightly_smiling_face:

This is likely because the "autocompletion" behavior (which jumps to the item that matches the string you're typing) intercepts arrow keys. It probably shouldn't.
For reference, this "autocompletion" behavior is also present on item lists in your OS' file manager. Try opening a folder with lots of files and start typing some letters 🙂

Ah yes that seems to be related to the wonky behaviour. If you (or anyone else) happen to know a way to overwrite this behaviour I would love to hear it :sweat_smile:


Upgrade DavMail.app to v4.7.0

Thank you for the contribution. It was merged directly as fd34c3dc169a54e315473657ea0194a8ce5600c0 to keep commit history cleaner. Your contribution is still credited to you.


Scroll to Top and Code Schools Design Refactor

Description of changes

Lot's of changes, let me know if you have questions. The site has a much better UX with the Code Schools page and the css issues that were causing problems. The top nav is not part of this PR. I'm doing my best to get work done and keep my PR's relevant and contained to their respective issues.
Issue Resolved

Fixes #426 #399 #395 #263 #199 #198
This also fixes our manifest.json file, which lets users add the app to their homescreen. It's almost a full PWA, we just need to implement a service worker.

This is ready for review. No rush - I'd recommend running it locally to see the changes. Now when you click anywhere on the code school's card it opens the link in a new tab. Also, I think I've got all the other external links opening in new tabs. :rocket:

Is there a way we can DRY up all of the target="_blank" rel="noopener noreferrer" in links? Maybe through a component? This would help make all links consistent across the app as well.

#431 is also addressed here

Here's a demo video on this PR:
https://youtu.be/vzUBuZhnOBQ
I've sifted through every line and made some corrections so it's not too cumbersome to review. It's ready for review whenever you get a chance. Let me know if you have any questions.

I don't really see a major difference until you're at the absolute minimum width for the browser.
https://youtu.be/vzUBuZhnOBQ?t=36s

I've made some changes.
https://slack-files.com/T03GSNF5H-F6U0PPCUF-a36fcf03e4

ok ready @kylemh

You made this PR from your own fork, so I cannot make changes to it.
See #437


Don't install tests / Split test dependencies

Hi,
I'm trying to use gmusicapi with mopidy-gmusic (a plugin for mopidy).
Mopidy checks the plugins' transitive dependencies during start up, otherwise stops loading the plugin.
As gmusicapi currently seems to install the test directory, it checks for the test dependencies, too.
Usually one would not require them to be installed.
Could you exclude the test directory in setup.py and split the dependencies into install_requires and tests_require?

Yeah, I'd like to do this. This was intentional - when gmusicapi was young, I often needed users to run the test suite to help with debugging - but isn't needed anymore.


docs(api): Remove "PAPIv2.14 unsupported" notes

Overview
docs.opentrons.com had some notes that PAPIv≥2.14 was unsupported by opentrons_simulate, opentrons.simulate.simulate(), and opentrons.simulate.get_protocol_api(). Now that #13709 is merged, it is, so we can remove those notes.
Review requests

docs.opentrons.com is deployed separately from the rest of the robot stack. Is it correct to merge this into chore_release-7.0.1, or should this go into edge?
Any places that I missed?
Do we want to wait until the v7.0.1 alpha is successfully QA'd to merge this, or is that excessively paranoid?

Risk assessment
Very low.

It's unclear to me whether we're officially supporting Jupyter and expecting it to work on Flexes, so I'll leave the work of confirming and documenting that to a separate PR.

Hang on, we already did a lot of this stuff and merged it to edge. Apparently that didn't get into the release branch…so this might cause a conflict down the road. The changes from this PR should prevail (remove note, use |apiLevel| substitution).


Add credit command

#91 : The credit command will print the past week and all-time contributors' usernames and number of commits. The lists are sorted by number of commits (descending).

closing due to stale


Redux-search + Redux-immutable

I am working on a project where we are using an immutable redux store where the initial state of the app is an Immutable.Map() (see https://github.com/gajus/redux-immutable). Is there an easy way to get redux-search to work with this setup?
I get this error: "Can not read property "menuItems" of undefined", where "menuItems" is my resource index. Having the top-level of the state as a plain JS object works just fine.

I ended up having a split state (plain/immutable) at root level which is perfectly fine in my case.

Glad you got it sorted :)
On Mar 16, 2017 10:48 AM, "Ariel Fischer"<EMAIL_ADDRESS>wrote:

I ended up having a split state (plain/immutable) at root level which is
perfectly fine in my case.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/bvaughn/redux-search/issues/62#issuecomment-287138091,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABznXvegjw8BmdcpG_QWJOsz9Kzm9Irks5rmXXngaJpZM4MfcBm
.


UserSecrets reloadOnChange

With AddJsonFile(...), the reloadOnChange option is very convenient. Can this be made available for AddUserSecrets<T>() as well?
I see that it can be added in UserSecretsConfigurationExtensions.cs, but is there a reason for leaving it out from there?

Resolved by @Kahbazi in https://github.com/aspnet/Extensions/pull/549. Thanks for the PR!


Fix: Fixed COMException when renaming files

Resolved / Related Issues
To prevent extra work, all changes to the Files codebase must link to an approved issue marked as Ready to build. Please insert the issue number following the hashtag with the issue number that this Pull Request resolves.

https://files-org.sentry.io/issues/5463612608/events/79a0bb9c84c54f7e8ad055f904d061af/

Steps used to test these changes
Stability is a top priority for Files and all changes are required to go through testing before being merged into the repo. Please include a list of steps that you used to test this PR.

Opened Files ...
...

@hishitetsu do you have any ideas on how to fix the root issue?

I can't think of a good idea at the moment. I wish I knew a procedure that could be reproduced reliably.

In the meantime, these fixes seem to help.


mysqlcluster: innodb_log_file_size auto config. #501

What type of PR is this?

/enhancement
Which issue(s) this PR fixes?

Fixes #501
What this PR does?
Summary:

When the redo log file size is not set manually, auto set  redo log file size is  25% of innodb_buffer_pool_size , but never over 8G.
when users want set over 8G,  they should set it in yaml file manually.

Special notes for your reviewer?

add unit test?


Keybord nevigation Issue#10

Two cases are addressed in this patch which is raised in Issue#10,

Case No 1 to provide traversing of search link based on Up and Down key press event I have added "tabIndex" attribute in html page and index.js where search links are being rendered. Two functions in Index.js has been added which are "traverseElementOnKeyDown(event)" and "findElementByAttributeValue(e,v)".

Case No 2 by pressing "Esc"  key send focus back to html page also has been addressed.

Thanks @JBaba for the PR! Looks very good. I've added a couple comments!

This works great!
A couple things I think we couple improve:

Add a better style for active links. Maybe just text-decoration:underline?
When using the arrow keys, the page scrolls a bit each time. This doesn't happen with the "tab" key. I think we should avoid this behaviour (a return false or event.preventDefault() may do the trick?)
When you arrive at the end of the list, the next "tab" keypress goes back on top, to the first
 element. Maybe instead of giving a specific tabindex to each h3.a, we could just explicitly give tabindex=-1 to the
 elements?

I was about to address some of this that's great that you just mentioned. I
didn't know how could I address this changes while I was in middle of
development.
I will work on this addressed changes.
On Mar 17, 2016 9:19 PM, "Sylvain Zimmer"<EMAIL_ADDRESS>wrote:

This works great!
A couple things I think we couple improve:

Add a better style for active links. Maybe just
text-decoration:underline?
When using the arrow keys, the page scrolls a bit each time. This
doesn't happen with the "tab" key. I think we should avoid this behaviour
(a return false or event.preventDefault() may do the trick?)
When you arrive at the end of the list, the next "tab" keypress goes
back on top, to the first  element. Maybe instead of
giving a specific tabindex to each h3.a, we could just explicitly give
tabindex=-1 to the  elements?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/commonsearch/cosr-front/pull/31#issuecomment-198151745

@sylvinus Can you help me understand this "next" and "previous" behaviour because after clicking on either of this "renderHit" function is not being invoked and which results into tabIndex not being assigned to search links. I don't know what's happening here ?

Currently the "next" links are regular links that cause a page reload. So the page you get has been rendered from the Go template, not from JavaScript's renderHit()

So only first page search result will use JavaScript's renderHit(). What's solution for rest of the pages and how can I help ?
Even if you come back from second page to first by clicking on previous then also we don't have tabIndex

@JBaba it's the other way around: all results except the first page load use renderHit().
You have already patched index.html to add some tabindexes, you just need to make the same changes there are you make in renderHit!

I have tried to use $index but it always gives me 0,1,2,3.... series to start at my desired value i have to do something like this,
{{add $index 6}}
func add(x, y int) int {
    return x + y
}

Let me know your views on this if you agree then i can go ahead and make this change.

Can't you do {{ add $index offset}} ?

@sylvinus  For this we have to define add function. I was reading similar article on this.

If you need to do that you can add it here:
https://github.com/commonsearch/cosr-front/blob/master/server/templates.go#L83

Thanks that worked.

I have addressed new changes.
Need help with scrolling page to top when we reach at end of screen but preventDefault() interrupts that.
I have tried using this code,
var h = window.innerHeight;
var rect = currentElement.getBoundingClientRect();
var offset = h - rect.top;
if(offset < 100 ){
	window.scrollTo(0, h/2);
}

But this works for sometimes and sometimes not. Couldn't figure out why ?

Scrolling to h/2 seems suspicious to me.. Shouldn't it be rect.top?

This what i have found after referring few posts. I am finding offset (bottom) by subtracting document inner width from top of element. I was also not sure and after tested for while felt that this is buggy so asked for helped. What do you suggest how should we approach this ?

It seems like the general idea should work, but the formula doesn't look right. Try window.scrollTo(0, rect.top);?

@sylvinus  I have simulated problem here you can see what's happening,
https://jsfiddle.net/naimish101/bat8bf8h/4/

@JBaba Seems to be fixed if you use offset < 0 instead ?

@sylvinus you must be testing on chrome. It does not work vary well with other browsers.

It seems to work for me in Firefox as well.
I'm working on interface tests for #1 so I'm going to merge it now and with Saucelabs we will make sure it behaves the same way in all browsers!
Thanks for the great work!


CAD files for footprint switching?

thanks for sharing this, it's certainly going to make many peoples access to grids much easier.
Would it be possible for you to share the CAD files so we can switch out the button footprint? I havnt been able to find those particular buttons in my part of the globe, but there's planty of similar alternatives.
Cheers!

Added KiCAD file.
I used a very local Taiwanese switch so a global alternative would be welcome!

excellent, thanks!
I'm in China, so maybe not so global but more options are always better.


proposal: io: CopierTo and CopierFrom interfaces

Proposal Details
The io.Copy and io.CopyBuffer functions will use WriteTo when the source supports it and ReadFrom when the destination supports it.
There are cases when a type can efficiently support WriteTo or ReadFrom, but only some of the time. For example, CL 472475 added an WriteTo method to *os.File which performs a more efficient copy on Linux systems when the destination is a Unix or TCP socket. In all other cases, it falls back to io.Copy.
The io.Copy fallback means that io.CopyBuffer with an *os.File source will no longer use the provided buffer, because the buffer is not plumbed through to WriteTo. (It also resulted in https://go.dev/issue/66988, in which the fallback resulted in the fast path in *net.TCPConn.ReadFrom not being taken.)
There have been previous proposals to fix this problem:

#21904: Rejected.
#16474: Discussion ongoing, but this wouldn't address the io.Copy case.

Those issues also contain some links to various other instances of this problem turning up, but I think the *os.File.WriteTo case is a sufficient example of a problem that needs solving, since io.CopyBuffer no longer works as expected on files.
I propose that we add two new interfaces to the io package:
package io

// CopierTo is the interface that wraps the CopyTo method.
//
// CopyTo writes data to w until there is no more data to write or when an error occurs.
// The return value n is the number of bytes written.
// Any error encountered during the write is also returned.
//
// When len(buf) > 0, CopyTo may use the provided buffer as temporary space.
//
// CopyTo may return an error wrapping errors.ErrUnsupported to indicate that
// it is unable to efficiently copy to w.
//
// The Copy function uses CopierTo if available.
type CopierTo interface {
	CopyTo(w Writer, buf []byte) (n int64, err error)
}

// CopierFrom is the interface that wraps the CopyFrom method.
//
// CopyFrom reads data from r until EOF or error.
// The return value n is the number of bytes read.
// Any error except EOF encountered during the read is also returned.
//
// When len(buf) > 0, CopyFrom may use the provided buffer as temporary space.
//
// CopyFrom may return an error wrapping errors.ErrUnsupported to indicate that
// it is unable to efficiently copy from r.
//
// The Copy function uses CopierFrom if available.
type CopierFrom interface {
	CopyFrom(r Reader, buf []byte) (n int64, err error)
}

The CopierTo and CopierFrom interfaces supersede WriterTo and ReaderFrom when available. They provide a way to plumb the copy buffer down through the copy operation, and permit an implementation to implement a fast path for some subset of sources or destinations while deferring to io.Copy for other cases.
We will update io.Copy and io.CopyBuffer to prefer CopierTo and CopierFrom when available.
We will update *os.File and *net.TCPConn (and possibly other types) to add CopyTo and CopyFrom methods.

Is CopyTo guaranteed to have had no observable effect when it returns an errors.Is(,errors.ErrUnsupported) error?

Is CopyTo guaranteed to have had no observable effect when it returns an errors.Is(,errors.ErrUnsupported) error?

Yes.

The motivation for this proposal is to fix io.Copy when used with common standard library types such as *os.File and *net.TCPConn.
It's perhaps not immediately obvious that io.Copy is broken. Let's look at a concrete example from the net/http package (https://go.googlesource.com/go/+/refs/tags/go1.22.2/src/net/http/transfer.go#412):
func (t *transferWriter) doBodyCopy(dst io.Writer, src io.Reader) (n int64, err error) {
	buf := getCopyBuf()
	defer putCopyBuf(buf)
	n, err = io.CopyBuffer(dst, src, buf)
	if err != nil && err != io.EOF {
		t.bodyReadError = err
	}
	return
}

This function copies from a user-provided io.Reader to an io.Writer. It doesn't know anything about the source and destination, although the Writer has usually been created by the net/http package. It uses io.CopyBuffer and does buffer pooling to minimize allocations. The copy operation takes advantage of sendfile when available.
Let's consider the case where we're on macOS, copying from an *os.File created by os.Pipe, and to a *net.TCPConn.
In this case:

doBodyCopy allocates a copy buffer from its pool.
io.CopyBuffer notices that the source supports WriteTo and calls it.
*os.File.WriteTo doesn't have any special handling on macOS, so it wraps the source in a type that removes the WriteTo method and calls io.Copy.
io.Copy notices that the destination supports ReadFrom and calls it.
*net.TCPConn.ReadFrom calls sendfile, which fails, because macOS doesn't support sendfile from a pipe.
*net.TCPConn.ReadFrom wraps the destination in a type that removes the ReadFrom method and calls io.Copy.f
io.Copy allocates a buffer and does the copy.

Note that there are three io.Copy operations in the call stack. We lost the user-allocated buffer provided to CopyBuffer after the first one. It is entirely not obvious to the original caller (doBodyCopy) that the buffer provided to CopyBuffer won't be used; doBodyCopy was, after all, operating on a plain io.Reader and io.Writer.
We could change doBodyCopy to mask any ReadFrom or WriteTo methods on the reader and writer, at the cost of disabling the sendfile optimization when we do want it. Requiring every caller of io.CopyBuffer everywhere to do this would be unfortunate.
This is a mess.
At a high level, I have two goals. When using common types from the standard library (files, network sockets):

io.Copy (and related functions) should not recursively call itself; and
io.CopyBuffer should use the buffer provided to it.

Arguably, the recursive calls to Copy aren't necessarily a problem, but they add so much confusion to the call stack that it has become very difficult to understand what's actually going on in a copy operation. The CopyBuffer buffer getting lost is, I think, at this point a straight up bug: As of Go 1.22, CopyBuffer with an *os.File as the source will never use the provided buffer. The fact that this changed between Go 1.21 and 1.22 seems to me to be a plain regression.
The Go compatibility promise closes off most avenues for fixing this:

We document io.Copy as calling ReadFrom/WriteTo when available.
Changing io.CopyBuffer to not call ReadFrom/WriteTo seems likely to cause regressions in code that expects the current behavior.
We can't remove the WriteTo method from *os.File.
We can't remove the ReadFrom method from *net.TCPConn.
We can't start returning errors.ErrUnsupported from existing ReadFrom or WriteTo methods.

(Of these options, the last one seems like the most feasible: If could return ErrUnsupported from *os.File.WriteTo and *net.TCPConn.ReadFrom when the fast sendfile path is not available, then we can get by without any new APIs. That was #21904, which was rejected. Perhaps it should be reopened?)
The root of the problem is that WriteTo and ReadFrom aren't the right interface between io.Copy and an io.Reader/io.Writer:

Support for fast-path copies may be conditional on the pairing of (source, destination), and the WriteTo/ReadFrom are necessarily associated with only one or the other. There needs to be a way for a type to support fast copies, with a fallback to the usual copy path.
If a type needs a buffer to support its copy, it has WriteTo/ReadFrom have no access to the buffer provided to io.CopyBuffer.

The proposed CopierTo/CopierFrom aim to fix io.Copy on os and net package types by providing an interface that does include the necessary features.
Adding yet more magic methods to dig us out of the hole caused by the existing magic methods does seem somewhat odd. It's quite possible that if we were designing io.Copy from the start, there would be a better way to do this. But I don't see another way out of this given the current constraints, I believe this proposal does address the problem, and I think that the addition of *os.File.WriteTo in Go 1.22 has put us at a point where surprising io.Copy behavior is common enough that we need to do something to address the situation.

We could constrain this by using an internal package, and by looking for methods that return types defined in that internal package.  That would mean that only types in the standard library would implement the new interfaces.  On the one hand that would prevent other packages from taking advantage of these new methods.  On the other hand it would constrain the additional complexity.
For example
package iofd

type FD uintptr

type SysFDer interface {
    SysFD() FD
    CopyBetween(dst, src FD, buf []byte) (int64, bool, error)
}

Then in package io
    srcfd, srcOK := src.(iofd.SysFDer)
    dstfd, dstOK := dst.(iofd.SysFDer)
    if srcOK && dstOK {
        len, handled, err := srcfd.CopyBetween(dstfd, srcfd, buf)
        if handled {
            return len, err
        }
    }

We could constrain this to be internal-only, but I don't think it's worth it. We'd still have the complexity of the new methods, we'd just not be allowing anyone else to take advantage of the benefits.

I think the complexity of the new methods is significantly less if nobody else can implement them.  In particular we can design the new methods so that they work on the pair of source and destination, which is what we need.  One of the problems with the current methods is that they only work on the source or on the destination, which is how we've gotten into the position of needing to use both, and therefore needing to turn off both, and therefore increasing complexity.

#69097 is another example of things going wrong in the current tangle of ReaderFroms/WriterTos. I'm pretty sure this also broke with the addition of *os.File.WriteTo in 1.22.

You're right, there is no reason to make CopyBetween a method of SysFDer.  It should just be a top level internal/poll.copyBetween function that copies between two file descriptors.  We can handle LimitedReader (and CopyN) by also passing a maximum length.
I think there is a problem with ReaderFrom and WriterTo that you aren't mentioning: in order to use them to invoke sendfile or copy_file_range, whoever implements the methods needs to dig through the argument to find out what it can do.  That's the step I'm trying to avoid by SysFDer.  I agree that this does not help with the io.CopyBuffer problem.


[Pristine] Allow passing a list of gems to pristine

In the process of testing this, I discovered and fixed a bug that had pristine git gems not get added files removed.

@colby-swandale r?

Do we want to print a warning to the user if they're giving a gem not in the Gemfile? Otherwise this LGTM

@colby-swandale done

🎉 @bundlerbot r+


Transform spatial view attachment's clip from drawing to sheet.

For some reason, we have always defined clip volumes in world coordinates. That seems like a poor (and probably unintentional) choice - really, a clip associated with a node in the scene graph should be defined in that node's coordinate space.
When we display a spatial view within a section drawing view, we transform the spatial view's clip into drawing (world) coordinates.
When we display that section drawing view as a view attachment on a sheet, the clip remains in drawing space - but it needs to be in sheet (world) coordinates.
There were two options for fixing this:

Rectify the mistake of always defining clips in world coordinates. Far too error-prone and disruptive.
Allow the sheet view to tell the drawing view how to transform the clip to world coordinates.

The latter is implemented by AttachToViewportArgs.drawingToSheetTransform. It is admittedly a bit of a hack.
Fixes ADO 806159 and 806140.

@Mergifyio backport release/2.19.x


Extending linxal - LAPACK only?

Do you welcome PRs implementing more Linear Algebra procedures which might not necessarily be based on LAPACK?
I need to write a (modified) Gram Schmidt procedure for one of my problems. I was quite surprised that LAPACK doesn't provide anything for that itself. Probably because it's too simple... So a pure Rust implementation it is. :)

I don't think there's anything wrong with algorithms that aren't direct translations of LAPACK drivers or computations routines. I think they would probably require a higher bar for testing, though. Most of the existing testing is essentially at the interface level, since LAPACK is doing the heavy lifting. A novel implementation would inherently be treated more skeptically.
In this case, though, LAPACK does provide QR-decomposition, via ?geqrf, for m x n matrices. The direct output is opaque, but you can use ?orgqr to recover the Q matrix, which is precisely the GSO.
So, if you're just talking about GSO, I would prefer an implementation to go that route.

I should also mention that I do want factorizations (QR, LQ, Cholesky) to be exposed in a user-friendly way in linxal. So, if you don't mind waiting a couple of days, I will probably push code in the next couple of days that will at least make QRs  easy to use.

Very valid points. If I am not mistaken though, LAPACK uses Householder reflections instead of Gram-Schmidt, don't they?
The reason I was looking into modified Gram Schmidt is that I get the normalization factors of the orthogonal vectors as a side effect of the reorthogonalization procedure. With ?geqrf and ?orgqr this route would take a few extra steps.

Ah I see. I think you're right; I don't think you can recover those normalization constants without significant extra work.
In that case, I'd be happy to accept a modified GSO implementation.

Hey! What's your opinion on this? https://github.com/SuperFluffy/gram_schmidt
It's a pretty straight forward implementation, and I am using it in production for a while now. It is of course missing some documentation.
In terms of implementation style I have focused on what you are doing. Although I am not sure about the structure of, e.g. impl SVD for $impl_type instead of implementing these traits on ArrayBase with different elements (since, after all, the functions are not supposed to act on the primitives but on the matrices).

Looks good for floats. You'll certainly have to modify it a bit to have it work for complex vectors as well, since ndarray's Dot doesn't do a proper complex inner product. linxal already has a conjugate method defined on LinxalScalar, but it would probably better to have a generic InnerProduct trait, so that one could use BLAS for the heavy lifting.


export format discussion

I wrote/drew up a description of the main thing we talked about in a very bootleg PDF: lifetimes.pdf
A few additional thoughts:

The declaration items currently give their universe parameters as name indices, which the type checker needs to promote to levels. It seems like it would be easier to do what's already done with #EC and give a list of level indices instead of name indices, and the type checkers could get rid of a (very) little bit of code in the parser.

Something to think about down the line if there are multiple type checkers, it may be nice to have an extension to the export format that conveys the pretty printer options the user wants to use and a list of the declarations they actually want to see printed back to them. Users would just convey that once to the exporter and be able to expect the same behavior from each checker, and it might prevent different checkers from having slightly different ways of taking pretty printer options.

It may be worth it to have some kind of lean version identifier somewhere. While the underlying theory isn't really expected to change, there might be small implementation details in checkers or the format that warrants versioning (we're on v2 of the export format after all).

I wrote/drew up a description of the main thing we talked about in a very bootleg PDF: lifetimes.pdf

LGTM

The declaration items currently give their universe parameters as name indices, which the type checker needs to promote to levels. It seems like it would be easier to do what's already done with #EC and give a list of level indices instead of name indices, and the type checkers could get rid of a (very) little bit of code in the parser.

At first glance this does not sound consistent to me: we use level objects when using universes but names when declaring them (as it wouldn't make sense to have Level.zero as a universe parameter). This is how it works internally everywhere in Lean as well.

2. Something to think about down the line if there are multiple type checkers, it may be nice to have an extension to the export format that conveys the pretty printer options the user wants to use and a list of the declarations they actually want to see printed back to them. Users would just convey that once to the exporter and be able to expect the same behavior from each checker, and it might prevent different checkers from having slightly different ways of taking pretty printer options.

Makes sense, though a standardized command line format should achieve the same, no?

3. It may be worth it to have some kind of lean version identifier somewhere. While the underlying theory isn't really expected to change, there might be small implementation details in checkers or the format that warrants versioning (we're on v2 of the export format after all).

Perhaps an export format identifier instead, then?

I wrote/drew up a description of the main thing we talked about in a very bootleg PDF: lifetimes.pdf

LGTM

The declaration items currently give their universe parameters as name indices, which the type checker needs to promote to levels. It seems like it would be easier to do what's already done with #EC and give a list of level indices instead of name indices, and the type checkers could get rid of a (very) little bit of code in the parser.

At first glance this does not sound consistent to me: we use level objects when using universes but names when declaring them (as it wouldn't make sense to have Level.zero as a universe parameter). This is how it works internally everywhere in Lean as well.

2. Something to think about down the line if there are multiple type checkers, it may be nice to have an extension to the export format that conveys the pretty printer options the user wants to use and a list of the declarations they actually want to see printed back to them. Users would just convey that once to the exporter and be able to expect the same behavior from each checker, and it might prevent different checkers from having slightly different ways of taking pretty printer options.

Makes sense, though a standardized command line format should achieve the same, no?

3. It may be worth it to have some kind of lean version identifier somewhere. While the underlying theory isn't really expected to change, there might be small implementation details in checkers or the format that warrants versioning (we're on v2 of the export format after all).

Perhaps an export format identifier instead, then?

At first glance this does not sound consistent to me: we use level objects when using universes but names when declaring them (as it wouldn't make sense to have Level.zero as a universe parameter). This is how it works internally everywhere in Lean as well.

I forgot this is one of the areas where the type checkers differ; trepplein and nanoda eagerly promote declaration uparams to levels (so the declaration headers are (Name, Level*, Type)), but the C++ and Haskell versions keep them as names. I'll probably switch to using names to keep things consistent.

Makes sense, though a standardized command line format should achieve the same, no?

Sure, I'm fine with doing that instead.

Just a request for initial feedback, let me know what you think about the changes in 4e9bf08.

The recursor rules, constructors, recursors, and reducibility hints (for height) were added to the output.
THM is a separate thing now, since it doesn't have a hint.
QUOT has been changed to output each declaration separately with the accompanying name, type, and uparams.
IND now only has the constructor names in-line since the constructor types are output separately and can be found by name.

Makes sense to me. /cc @semorrison @digama0?

SGTM as well. I agree that the checker should be doing more checking and less generating of expressions.

@Kha Is there a quick way to tell whether an Expr contains an mdata node? The current implementation of getIdx and dumpExpr outputs duplicate and unreachable items because App f a and App f (mdata a) have the same export representation, but different hash digests/aren't BEq. The direct solution of recursively removing the mdata works fine, but it seems to increase the execution time by ~2x even with a cache.
There are relatively few mdata nodes in the entire environment, so if there's a way to quickly determine whether or not an Expr has any mdata nodes and only rebuild the ones that do, I think that would solve the problem pretty nicely.

I think the best way to fix this is to just add a mdata node to the export format. For the purpose of hash/eq, it's fine if the node doesn't even say anything, it's just mdata ? e without any information about the content of the mdata. On the other hand, this information is useful for various things, so I think it would be okay to just serialize it too.

With a slightly more clever implementation I got the mdata-less version of dumpExpr to roughly the same performance on Init.lean, and ~30% slower on mathlib4. I'm proposing putting it behind a flag, it's an extra 50 sloc that's mostly let bindings. I like the option of leaving the mdata nodes in, but after working an mdata node into the wip rust checker, it can feel out of place in something that's supposed to be minimal.

@Kha
I'm getting ready to release the updated version of nanoda_lib and the binary, and I wrote a small book about the kernel/type checking. I pushed a commit for this repo here as a candidate for the exporter changes that were discussed. Let me know if you have comments/concerns. It includes the mdata pruning and addition of a version string for the export format.
I'll send you a draft of the book in the next day or two to get your thoughts on the initial release.

Also to Sebastian and @digama0, I put the introductory section of the book type checker guide in a gist. If you have a minute, I would appreciate any feedback as experts.
It includes a slightly edited quote from Mario on zulip, if you're opposed to its inclusion or want to change the wording, please let me know.

LGTM

Looks nice! You might want to reference https://doi.org/10.1016/j.entcs.2012.06.008 in the Adversarial section

Looks nice! You might want to reference https://doi.org/10.1016/j.entcs.2012.06.008 in the Adversarial section

That's a wonderful reference, thank you.


feat: support ALTER TABLE ... ALTER COLUMN ... TYPE ...

I hereby agree to the terms of the GreptimeDB CLA.
Refer to a related PR or issue link (optional)
https://github.com/GreptimeTeam/greptimedb/issues/3517
https://github.com/GreptimeTeam/greptime-proto/pull/149
What's changed and what's your intention?
Support: alter table xxx alter column xxx type xxx
https://www.postgresql.org/docs/current/sql-altertable.html
public=> CREATE TABLE test(id INTEGER PRIMARY KEY, i INTEGER NULL, j TIMESTAMP TIME INDEX, k BOOLEAN);
OK 0
public=> ALTER TABLE test ALTER COLUMN I TYPE STRING;
OK 0
public=> DESCRIBE test;
 Column |         Type         | Key | Null | Default | Semantic Type
--------+----------------------+-----+------+---------+---------------
 id     | Int32                | PRI | YES  |         | TAG
 i      | String               |     | YES  |         | FIELD
 j      | TimestampMillisecond | PRI | NO   |         | TIMESTAMP
 k      | Boolean              |     | YES  |         | FIELD
(4 rows)

Checklist

[x]  I have written the necessary rustdoc comments.
[x]  I have added the necessary unit tests and integration tests.
[x]  This PR does not require documentation updates.

Good job! But why not use the common SQL syntax?
ALTER TABLE table_name
MODIFY COLUMN column_name datatype;

It would be better that the user doesn't need to learn a new syntax.

But why not use the common SQL syntax?

This is the syntax PostgreSQL currently uses.
https://www.postgresql.org/docs/current/sql-altertable.html
ALTER TABLE distributors
    ALTER COLUMN address TYPE varchar(80),
    ALTER COLUMN name TYPE varchar(100);

But why not use the common SQL syntax?

This is the syntax PostgreSQL currently uses. https://www.postgresql.org/docs/current/sql-altertable.html
ALTER TABLE distributors
    ALTER COLUMN address TYPE varchar(80),
    ALTER COLUMN name TYPE varchar(100);

Yes, but MySQL, Oracle, and SQLServer are using modify column.

tips: sqlparser-rs already supports modify column: https://github.com/sqlparser-rs/sqlparser-rs/pull/1216

Create an issue here for reminding us the docs after this whole feature is done.

Hi @KKould There are some conflicts

tips: sqlparser-rs already supports modify column: sqlparser-rs/sqlparser-rs#1216

Is it possible to upgrade the SQL parser-rs to the latest?

I created PR: https://github.com/GreptimeTeam/sqlparser-rs/pull/11 to support modify column

If the CI failure in https://github.com/GreptimeTeam/sqlparser-rs/pull/11 is easy to fix. We could implement the final syntax in this PR. @KKould Could you please take a look?

If the CI failure in GreptimeTeam/sqlparser-rs#11 is easy to fix. We could implement the final syntax in this PR. @KKould Could you please take a look?

I checked before and it seems that these errors are caused by other PRs, not this PR.

The pr should be open on v0.44.x instead of the main branch, because the sqlparser code will be synchronized with datafusion' sqlparser code regularly. However, I still recommend not to change the keywords and use parser directly to identify the token to avoid conflict when sync upstream sqlparser later.


[WIP] popup fixes

Fixes:

[x] clicking off the popup will close it
[ ] destroy popup - unfortunately, on view change, the tether bindings die out, and the element is moved out to the body earlier which causes the directive to stay in play. On view change back, the directive is still there and responds to the same ID command (and then there were 2).

Closing due to inactivity. If you get back to this @AntJanus, please reopen.


Changes helpers.fileExists to use regular stat instead of lstat.

This fixes issue #20 -- where you get "file not found" errors when the
target of an $include is a symlink to a file. Use of stat means the
system will follow these symlinks instead of returning information about
the link itself.

@tgockel Good work!! Thanks for your support. :-)


Added Lake Washington Institute of Technology

Added Lake Washington Institute of Technology

Hate to bother you, I understand that you might have got some reasons to hold the quest off. I am a student at this school and am hoping to get some of your products with the academic discount...
Do I need to fix anything or provide you with any additional evidence to get the request merged?

please excuse my delay with reply, i'm adding the domain

Thank you so much :)


⚠ Processors has degraded performance

In 46b005c, Processors ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 45 ms

Resolved: Processors performance has improved in e1ec812.


Reproducer for: "couldn't find DSO to load: libhermes.so caused by"

i created a project for reproducing this crash of java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so
hope it help here to debug this crash.

**Step reproduce:

Init project: npx react-native init Test0714

android/gradle.properties ->  newArchEnabled true

add @react-native-firebase/app

register firebase console -> add google-services.json (packageName: "com.test0714") to dir: /android/app

rnfirebase docs: => cd android && ./gradlew signingReport

add "classpath 'com.google.gms:google-services:4.3.15'" into dir: /android/build.gradle

Lastly, execute the plugin by adding the following to your /android/app/build.gradle file:
->apply plugin: 'com.google.gms.google-services' // <- Add this line

In File: /android/app/build.gradle
=> add these lines: "multiDexEnabled true" and "implementation 'androidx.multidex:multidex:2.0.1'"

yarn add @react-native-firebase/messaging

yarn add @react-native-firebase/crashlytics

android/build.gradle add line: "classpath 'com.google.firebase:firebase-crashlytics-gradle:2.9.4'"
android/app/build.gradle add line:  "apply plugin: 'com.google.firebase.crashlytics'"

// run-android here working fine.
/ / / / / / / /
// Crash after do these things with react-native-code-push
// adb logcat ==> java.lang.UnsatisfiedLinkError: couldn't find DSO to load: libhermes.so

yarn add react-native-code-push

android/setting.gradle:
include ':app', ':react-native-code-push'
project(':react-native-code-push').projectDir = new File(rootProject.projectDir, '../node_modules/react-native-code-push/android/app')

android/app/build.gradle
apply from: "../../node_modules/react-native/react.gradle"
apply from: "../../node_modules/react-native-code-push/android/codepush.gradle"

update MainApplication.java
// 1. Import the plugin class.
import com.microsoft.codepush.react.CodePush;
//
@Override
protected String getJSBundleFile() {
return CodePush.getJSBundleFile();
}

Run build: npx react-native run-android**

https://github.com/NguyenHoangMinhkkkk/reproduce-0714-crash
Originally posted by @NguyenHoangMinhkkkk in https://github.com/facebook/react-native/issues/35895#issuecomment-1475881250

Can someone try the reproducer provided by @NguyenHoangMinhkkkk and verify that it consistently happening?

And one more thing.
in gradle.properties, if hermesEnabled set as false then the app works.

I can able to reproduce this issue 'couldn't find DSO to load' in latest react-native 0.71.6 with hermesEnabled true

This is happening because of this line (apply from: "../../node_modules/react-native/react.gradle") in app/buil.gradle. This is required by older versions of codepush however they fixed it in the latest release.
Fix:

remove
apply from: "../../node_modules/react-native/react.gradle"
from app/build.gradle
Update react-native-code-push to v8.0.1
rebuild android and you should be good to go

You can confirm the apply from: "../../node_modules/react-native/react.gradle" is the problem by creating a new project in RN and adding this line in the app/build.gradle.
And also double check code-push is working for you.

This is happening because of this line (apply from: "../../node_modules/react-native/react.gradle") in app/buil.gradle. This is required by older versions of codepush however they fixed it in the latest release.

Thanks for verifying this @rada You're right that line is unnecessary.
Closing as this is now solved

This is happening because of this line (apply from: "../../node_modules/react-native/react.gradle") in app/buil.gradle. This is required by older versions of codepush however they fixed it in the latest release.
Fix:

remove
apply from: "../../node_modules/react-native/react.gradle"
from app/build.gradle
Update react-native-code-push to v8.0.1
rebuild android and you should be good to go

You can confirm the apply from: "../../node_modules/react-native/react.gradle" is the problem by creating a new project in RN and adding this line in the app/build.gradle.
And also double check code-push is working for you.

Thanks  🚀

This is happening because of this line (apply from: "../../node_modules/react-native/react.gradle") in app/buil.gradle. This is required by older versions of codepush however they fixed it in the latest release.
Fix:

remove
apply from: "../../node_modules/react-native/react.gradle"
from app/build.gradle
Update react-native-code-push to v8.0.1
rebuild android and you should be good to go

You can confirm the apply from: "../../node_modules/react-native/react.gradle" is the problem by creating a new project in RN and adding this line in the app/build.gradle.
And also double check code-push is working for you.

Worked perfectly

This is happening because of this line (apply from: "../../node_modules/react-native/react.gradle") in app/buil.gradle. This is required by older versions of codepush however they fixed it in the latest release.
Fix:

remove
apply from: "../../node_modules/react-native/react.gradle"
from app/build.gradle
Update react-native-code-push to v8.0.1
rebuild android and you should be good to go

You can confirm the apply from: "../../node_modules/react-native/react.gradle" is the problem by creating a new project in RN and adding this line in the app/build.gradle.
And also double check code-push is working for you.

Thank you

This is happening because of this line (apply from: "../../node_modules/react-native/react.gradle") in app/buil.gradle. This is required by older versions of codepush however they fixed it in the latest release.
Fix:
1. remove
   `apply from: "../../node_modules/react-native/react.gradle"`
   from [app/build.gradle](https://github.com/NguyenHoangMinhkkkk/reproduce-0714-crash/blob/main/android/app/build.gradle#L183)

2. Update react-native-code-push to v8.0.1

3. rebuild android and you should be good to go

You can confirm the apply from: "../../node_modules/react-native/react.gradle" is the problem by creating a new project in RN and adding this line in the app/build.gradle.
And also double check code-push is working for you.
@rada  Hi guys,
Thank you so much it works for me in Debug mode. However when it comes to release mode, the app build successfully but pictures are shown...I have to add apply from: "../../node_modules/react-native/react.gradle" for the release App to work! It is so annoying.
Any ideas guys? Thank you so much


lint > JS semicolon

Hey - what's up with the build on this one?

Redeploying now. I'm guessing it was a hick-up as the error occurred on netlify deployment.
There was an error running this command.```

@joekarasek could you fix the merge conflicts here when you get a sec? Ready to merge this in once that’s wrapped up!


there needs "then"

https://github.com/Azure/AZNFS-mount/blob/73829dec6e9ac80695fc494a3b81addd9e175ac6/src/aznfswatchdog#L153
to
 if [ $? -eq 0 ] && [ -n "$conntrack_timeo_timew" -a $conntrack_timeo_timew -gt $AZNFS_TIMEWAIT_TIMEOUT ]; then

@jkl2554 Thanks for pointing out the issue which got pushed in latest release. This will be fixed soon.


feat(Page): Support Page.getMetrics and metrics event.

Provides access to the current page performance metrics.
Allows to push page metrics from the page JavaScript with console.timeStamp()

Thanks Alexei!
Let's list the metric names explicitly so that it's easier to consume.


Fontname of a Type 3 font looks wrong

Description
For all other fonts, we get the expected font names of the embedded font, but for a Type 3 font, the prefix hash is included.
I tested this with SumatraPDF and Adobe Reader and both show the same name.
Maybe the reason is that this Font object is the only one having the Name key set: /Name /YXDKRS+SegoeUIEmoji.
Here comes the emoji 😂, which is from a different font and embedded as Type 3 font.

With older versions, emojis where embedded as a normal non-colored font and thus there was no need for Type 3 fonts.
Related: https://github.com/typst/typst/pull/5070

Reproduction URL
No response
Operating system
Windows
Typst version

[X] I am using the latest version of Typst

Here is an additional code to see how pdflatex writes the pdf object for Type 3:
\pdfobjcompresslevel=0
\documentclass[a4paper]{article}

\usepackage{wesa}
\usepackage[T1]{fontenc}

\begin{document}
\wesa
Example text which is in Type 3 format.
\end{document}

You can try LibreOffice, it uses Type 3 for color fonts.

Yes, you're right! I tried it, here is the result:

They are also using the expected Name without prefix hash.
It seems all three LuaTeX, LibreOffice and Typst embed the color emoji fonts differently, we can see this from the three different Adobe Reader images. My first impression is that the LuaTeX version is the best, but I have no further information here about the details and I couldn't find more information.

LuaTeX converts bitmap color glyphs into graphics and inserts them this way instead of font glyphs.
LibreOffice uses Type 3 fonts, which I think the same as Typst.
I don’t remember the exact details, but when I wrote the LibreOffice code I had issues with Type 3 font names and I had to jump through some hoops to make it work (some libraries, like Poppler, wouldn’t even show Type 3 font names at all). May be you can diff the two PDFs to see what is the difference.

I think this is the relevant difference:
   /Type /Font
   /Subtype /Type3
-  /Name /OHPKRD+TwitterColorEmojiSVGinOT
+  /Name /AppleColorEmoji

Typst prefixes the Type 3 font name with the subset id, but LibreOffice does not.

Yes. LibreOffice also does it, but only in the Font Descriptor:
12 0 obj
<</Type/FontDescriptor/FontName/BAAAAA+SegoeUIEmoji
...
>>
endobj

and then in the Font:
14 0 obj
<</Type/Font/Subtype/Type3/Name/SegoeUIEmoji
...
>>
endobj

Yes. LibreOffice also does it, but only in the Font Descriptor:

IIRC, I did this intentionally because I found out (like you did here) that the subset ID is not expected here, or at least apps I tested didn’t string it from /Font/Name, Unlike FontDescriptor/FontName.

About LuaTeX I really can't find anything besides this which suggests Type 3. But they seem to use some method that only works with HarfBuzz.

I wrote the initial code in luaotfload that handles colors fonts when using HarfBuzz and it doesn’t use Type 3 fonts. I think they were probably planning to switch it to use Type 3 fonts, but does not look like this ever happened, the PDF generated by LuaTeX today still uses images directly and it has no Type 3 fonts.

Thanks for the information, that makes it clear! I think, removing the prefix from the /Name would solve it then.

I think this is intentional, see https://github.com/typst/typst/pull/5070

Not sure whether it was intentional that it contains the prefix. Previously, it was not written at all.

Was it not? At least from the diff, it looks like the subset tag was written before. The only thing that changed is that the /Name entry contains the same.

What I meant was that the subset tag was written for the FontDescriptor, but nothing was written for the Type3Font itself. Now both get the subset tag. I think what the PR wanted to achieve is to write a Type3Font /Name at all, not the specifics of whether it contains a subset tag or not.

From my understanding of https://github.com/typst/typst/issues/5067, the point was that the name in FontDescriptor and in the font itself have to match, but maybe I got it wrong.

But this doesn't talk about the subset tag, so isn't there still the option of omitting the subset tag for both? Not sure whether that would be any more correct, just talking about the possibility. Anyway, I don't really have a clue of what's correct here.

Yeah, same. 😄

I don’t think anyone knows what is “correct” here either. We have PDF readers (both from Adobe and from others) that don’t strip the subset tag from /Font/Name but strip it from /FontDescriptor/FontName, and then we have the validation tool in #5067 that expects /Font/Name and /FontDescriptor/FontName to be identical (including the subset tag, I just checked it with LibreOffice-generated PDF and it complained about the mismatch).
Either the PDF readers are wrong or the validation are wrong, though if you ask anyone who worked with PDF they will tell you whatever Adobe tools does is the actual standard, not whatever is written in the spec (and the spec is not saying much here, even).

I think passing this validator is more important than the aesthetics of the font name in the settings panel, so maybe we can just close this?
Removing the subset tag from both seems ill-advised.

Yes, I agree.


Primary key can't be created if specify index as well

GORM Playground Link
https://github.com/go-gorm/playground/pull/497
Description
When I do many2many relation, sometimes you want to have additional index other than the one created by primary composite key, e.g. I have
type User struct {}
type Organization struct {}
type UserOrganization struct {
	UserId         string
	OrganizationId string
}

by default it create primarily key, e.g. (userId, orgId), but I also want to query by org id, so I need to have an index like:
type UserOrganization struct {
	UserId         string `gorm:"primaryKey,priority=1;`
	OrganizationId string `gorm:"primaryKey,priority=2;index"`
}

but if you do this, from an clean database, it will only create index, not the primary key
the workaround is to just use another composite index, but not really a nice solution

type UserOrganization struct {
	UserId         string `gorm:"primaryKey;`
	OrganizationId string `gorm:"primaryKey;index"`
}

primaryKey not support priority

any particular reason why it can't be supported? we are happy to contribute if it's possible

@zfy0701 just haven't supported it yet, welcome to contribute it.


Fix markdown syntax so title renders correctly

Hi! I found what appears to be a minor syntax issue preventing the 'power' title rendering on the Switch docs. Hope this is helpful, please feel free to close without comment if not.

rad, thank  you @philipbelesky !!!


Fix #7575 UI : Fetch bots with limit=100 and filter it on the UI side.

Fixes #7575
Describe your changes :

I worked on issue #7575

Type of change :

[x] Improvement

Frontend Preview (Screenshots) :
https://user-images.githubusercontent.com/59080942/191232062-b4097a09-0ea6-40dc-9bab-5d15c20e4ac1.mov

Checklist:

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

Reviewers
@open-metadata/ui

Can you check why cypress is failing here?


Adaptive lighting error in Core Log

Version information:
current
Description:
I was looking in the logfiles, I don't know what HA or AL was trying to do ATM.
2021-09-29 19:30:59 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
File "/config/custom_components/adaptive_lighting/switch.py", line 1228, in turn_on_off_event_listener
entity_ids = cv.ensure_list_csv(service_data[ATTR_ENTITY_ID])
KeyError: 'entity_id'

Same here:
Logger: homeassistant
Source: custom_components/adaptive_lighting/switch.py:1257
Integration: Adaptive Lighting (documentation, issues)
First occurred: 20:25:38 (2 occurrences)
Last logged: 20:27:50

Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/config/custom_components/adaptive_lighting/switch.py", line 1257, in turn_on_off_event_listener
    entity_ids = cv.ensure_list_csv(service_data[ATTR_ENTITY_ID])
KeyError: 'entity_id'

Using latest adaptive_lighting 1.0.14

There is many tickets pointing at the same error over a long period of time, can it be possible to dedup them?
https://github.com/basnijholt/adaptive-lighting/issues?q=is%3Aissue+is%3Aopen+Error+doing+job%3A+Task+exception+was+never+retrieved

This issue is fixed in https://github.com/basnijholt/adaptive-lighting/pull/321.
Please update Adaptive Lighting :)


Slicing of rank>=6 tensor?

Currently it throws a not implemented error "inputs rank not in [0,5]".

It is not supported as we don't see a good use case yet. What is yours here?

Some new convolutional layers invented in the last few months for superresolution etc. require further division of the H and W dimension like [N, C, H, H_sub, W, W_sub]. Although the slicing can be simulated via reshaping and slicing in a lower rank tensor, it's just doesn't feel right when T.transpose() and T.reshape() are both supported for rank 6 tensor and T.slice() isn't.

Interesting, could you give a citation of papers that do this. It is difficult to extend past 5 in the current framework because it requires more Eigen template instantiation which would bloat the binary. One way to get around this would be to implement a catchall non templatized version of slice. Most ops don't really support more than 5 so you probably will hit this on many other ops as well.

Interesting, could you give a citation of papers that do this. It is difficult to extend past 5 in the current framework because it requires more Eigen template instantiation which would bloat the binary. One way to get around this would be to implement a catchall non templatized version of slice. Most ops don't really support more than 5 so you probably will hit this on many other ops as well.

Automatically closing due to lack of recent activity. Please reopen when further information becomes available.


Consider using log/slog instead of logrus

Not a specific knock on logrus, but I only found 3 log lines using logrus in this library. Can we cut this third-party import and use standard library option?
$ grep logrus -r ./*
./go.mod:	github.com/sirupsen/logrus v1.9.3
./go.sum:github.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ=
./go.sum:github.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ=
./pkg/vex/vex.go:	"github.com/sirupsen/logrus"
./pkg/vex/vex.go:		logrus.Warn(err)
./pkg/vex/vex.go:	logrus.Warn("vex.StatementFromID is deprecated and will be removed in an upcoming version")
./pkg/vex/functions_files.go:	"github.com/sirupsen/logrus"
./pkg/vex/functions_files.go:		logrus.Info("Abriendo CSAF")

Sounds good to me, these are mostly vestigial from the original OpenVEX poc, we have tried to remove most of the output.


HLS ram-storage overflow

I use ram storage for HLS (SRS 3.0) and find some trouble.
It seem to ram not free when old HLS part has been cleaned.
Thanks for you work. SRS 3.0 is great!

It's a bug, I will fix it.

Please file bug at: https://github.com/simple-rtmp-server/srs/issues/new


trim whitespace from aws signature

This is causing an error because of trailing whitespace on the AWS signature. New versions of urllib2 complain with "Invalid header value"

It seems you're trying to fix the issue I reported in #33. I submitted functionally the same patch (#34), but I think my version is better for the RPM packaging. I left the module version at 1.0.1, but increased the version reflected in the RPM package from 1.0 to 1.0.1.
The rpm target in make now builds yum-plugin-s3-iam-1.0.1-1.noarch.rpm (instead of yum-plugin-s3-iam-1.0-1.noarch.rpm earlier).

why not increase the module version too?

I don't know that yum (or any software for that matters) actually uses the version number from the python module.
The RPM package version information needs to be increased (version or release) so that rpm -U or yum update works. I also think the module version and the rpm version should match, which is not the case in master or your patch.

This project needs a new maintainer, see: https://github.com/seporaitis/yum-s3-iam/issues/38 if interested in discussing further.

@revmischa: I merged #34.
Do you think we should update the version number again?


Add redis based authorization code services and tests

Fixes gh-935

Hope this gets merged soon. For the mean time, I'll be including the fix to our code base.

Thanks for the PR @srempfer. This is now in master.


--stripe-packages: do not consider top-level test dir a test

Motivation
Fix a stripe-specific edge case where the top-level test/ dir also contains the test-harness and runtime support for tests that isn't actually a test itself. The original intent of this function was to not classify these files as tests for the purposes of packages, however the path's actually contain a ./ prefix which defeated this logic.

Test plan

See included automated tests.

Fix a stripe-specific edge case where the top-level test/ dir also contains the test-harness and runtime support for tests that isn't actually a test itself. The original intent of this function was to not classify these files as tests for the purposes of packages, however the path's actually contain a ./ prefix which defeated this logic.

Is it possible to write a CLI test for this behavior? If so I'd love for us to try adding one.
Otherwise, lgtm.

Is it possible to write a CLI test for this behavior? If so I'd love for us to try adding one.

Extended an existing CLI test to include this behavior.


[DOOR Bugs] TypeHint(Union[...]) comparators busted in edge cases

Hey @leycec!
I've started playing with the goodies of @beartype, and TypeHint has been working fantastically. :)
However, I've been wondering about a particular behaviour involving Unions.
Check this out:
from typing import Union
from beartype.door import TypeHint
from numbers import Number

class A:
    pass

class B(A):
    pass

>>> TypeHint(Union[A]) >= TypeHint(Union[A, B])
False

Should this be True? In fact, I'm inclined to believe that TypeHint(Union[A]) == TypeHint(Union[A, B]) in this case.
Also,
>>> TypeHint(Union[Number, int]) >= TypeHint(Union[Number, float])
True

>>> TypeHint(Union[Number, int]) <= TypeHint(Union[Number, float])
True

>>> TypeHint(Union[Number, int]) == TypeHint(Union[Number, float])
False

What are your thoughts on the above behaviour?

Blargh! This some sus af tbh behaviour there. On the one hand, one of these comparisons seems "possibly okay" for competing definitions of "possibly" and "okay":
>>> TypeHint(Union[Number, int]) == TypeHint(Union[Number, float])
False

Since int and float are incommensurable (i.e., have no subclass relationship ignoring PEP 484's implicit numeric tower), we would expect all comparisons between int and false to evaluate to False. So, that sorta makes sense. These two, however, do not:
>>> TypeHint(Union[Number, int]) >= TypeHint(Union[Number, float])
True
>>> TypeHint(Union[Number, int]) <= TypeHint(Union[Number, float])
True

:vomiting_face:
For the same reason, these two comparisons should also evaluate to False. They do not. That's bad. In response, the black hole at the heart of the beartype.door API voraciously begins devouring everything in its stellar neighbourhood.
And this is undeniably awful:
>>> TypeHint(Union[A]) >= TypeHint(Union[A, B])
False

:vomiting_face: :vomiting_face: :vomiting_face:
That's the exact opposite of what you'd expect! Intuitively, Union[A] seems like it should definitely be a subhint of Union[A, B]. The former is commensurable with the latter but matches substantially fewer (in the "countably infinitely fewer" sense of "fewer") type hints than the latter. If these words I am typing are true, we would expect that comparison to instead evaluate to True: e.g.,
# Listen and obey, @beartype! *ROAR* Bad bear, bad bear! *ROAR, ROAR*
>>> TypeHint(Union[A]) >= TypeHint(Union[A, B])
True

A Heroic Plan for Fixing that Which Has Been Broken
Sadly, beartype 0.12.0 will probably preserve this broken behaviour. Scarce open-source time, thy name is Christmas. If you'd like to delve into this a bit, though, that'd be a wondrous Yuletide miracle! The relevant code resides in:

The public beartype.door._doorcls.TypeHint.is_subhint() method, which is where the illicit and poorly maintained fireworks begin exploding. This method internally defers to...
The private beartype.door._doorcls.TypeHint._is_le_branch() method, where most of the heavy-lifting in type hint comparisons resides.
The private `beartype.door._proposal.doorpep484604.

Specifically, this code snippet strikes me as extremely suspicious:
class TypeHint(...):
    def is_subhint(...):
        ...

        # Return true only if this type hint is a subhint of *ANY* branch of the
        # passed type hint.
        return any(
            self._is_le_branch(other_branch)
            for other_branch in other._branches
        )

Yikes! What are you even doing there, @beartype? :face_exhaling:

Curioser and curioser. I didn't entirely understand the prior logic for UnionTypeHint.is_subhint(), so I refactored everything according to Dr. Demento's Inscrutable Law of "Less Code Must Be Better." But it turns out that I didn't really need to do that at all, as it changed nothing.
After having cogitated deeply about the true meaning of unions at Christmas while creeping about the cottage at midnight, I have confirmed to at least myself that:

This is goodness incarnate:

>>> TypeHint(Union[Number, int]) >= TypeHint(Union[Number, float])
True
>>> TypeHint(Union[Number, int]) <= TypeHint(Union[Number, float])
True

Since Number is the superclass of both int and float, Union[Number, int] and Union[Number, float] semantically reduce to just Number. Since TypeHint(Number) >= TypeHint(Number) and TypeHint(Number) <= TypeHint(Number) are both trivially true, the above results hold. Thus do we thank you, Santa Bearclaws.

This is badness personified, however:

>>> TypeHint(Union[Number, int]) == TypeHint(Union[Number, float])
False

By the same reasoning, that should evaluate to True as well. It currently doesn't. Why? Because our UnionTypeHint subclass isn't redefining the __eq__() dunder method. It should be. Rudolf the Bug-sniffing Reindeer: you know what to do here.

This is badness in the flesh, too:

>>> TypeHint(Union[A]) >= TypeHint(Union[A, B])
False

Exactly as you suggest, @wesselb, both that and the equality TypeHint(Union[A]) == TypeHint(Union[A, B]) should absolutely evaluate to True. You're right about everything, as always!
Thankfully, I can explain exactly what's going wrong here, too. It may not look like it, but Union[A] is A. Literally. This is not semantics. Python's standard library tries to be clever by reducing a union containing only one type hint to just that type hint at runtime. For clarity, let's rewrite the above comparison using that explicit reduction as well as the <= operator:
>>> TypeHint(Union[A, B]) <= TypeHint(A)
False

Ah-ha! Now we see exactly what's gone wrong here. As currently implemented, the UnionTypeHint.is_subhint() method (underlying the <= operator) only supports comparisons between union type hints. Clearly, that's insufficient. No one ever expected an edge case union type hint like this. A union absolutely can be a subhint of a non-union, as the above example capably demonstrates.
So, we need to also generalize the UnionTypeHint.is_subhint() method to transparently support comparisons against non-union type hints as well. How? By just treating a non-union type hint as a union of only that type hint, which is really just reversing the reduction that Python itself uses. Viola!
Santa Bearclaws, you may now eat all the gluten-free cookies.

As usual, yet another fantastic reply by @leycec. :) That Union[A] is A has tricked me before too!
I'm glad you've gotten to the bottom of this so super quickly. Thanks again for your hard work!! We all love @beartype 😃
(A @beartype-powered Plum 2.0 should now be coming up soooooon!)

Aww. You're so welcome. Big wintry hugs from the enslaved happy QA elves at @beartype to you and your family this Christmas. Plum is equally amazing and about to blow even more of our socks off! :socks: :christmas_tree: :santa:
Which is a good thing on multiple counts. My wife insists my socks simply must be cleaned. Much to everyone's detriment, I keep resisting this sound advice. "Viva la poor hygiene."

Big beary hugs and a Merry Christmas to you and your family too! 🎅
Let's make sure those socks get blown off soon then haha. :P 🧦

Socks officially blown! Mine, that is. Resolving these edge cases was super-fun but super-non-trivial. It's like we're building out a theorem prover built on the unstable back of the typing module capable of solving Fermat's Last QA Problem. The DOOR API is rapidly transforming into this monolithic type hint calculus monstrosity capable of deciding that 42 might, after all, be the meaning of Python.
In short, this has now been resolved by c449dfc – to be released with our upcoming beartype 0.12.0 mic drop just as soon as I catch up on six month's worst of loss sleep. Wish me luck, boys! I'm crashin' hard tonight. :sleeping:

Thank you, @leycec!! This is super great. :)


Fix invoke usage with Python3

What does this PR do?
Make inv work with Python3
Motivation
No reason to require 2.7 for tooling

Superseded by #3136


[pmdk:x64-windows]build failure.

When asking a question please also include where you looked for an answer (so we can update the documentation if needed).
My installation process has been a failure.It's going to show every time——“CMake Error at scripts/cmake/vcpkg_execute_required_process.cmake:72 (message):”and"
Working Directory: E:/StudySoftware/pmdk/vcpkg/buildtrees/pmdk/x64-windows-rel
Error code: 1
See logs for more information:
E:\StudySoftware\pmdk\vcpkg\buildtrees\pmdk\build-x64-windows-rel-out.log"
Then I open the build-x64-windows-rel-out.log file,I find
error C2220: warning treated as error - no 'object' file generated
and
warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss

Hi @gottagogottagoGxj, does this issue still bother you?

We haven't been able to repro this; if more information comes up, or this issue appears again, please reopen.


Title: animated-search-bar

Is your feature request related to a problem? Please describe.
Hey I made animated-search-bar Project Which Is Very Good!
Describe the solution you'd like.
This Project is very Helpfull,
I Make This Project With the help of HTML, CSS & JavaScript.
Describe alternatives you've considered.
The CSS & JavaScript Code are Available in very well mannered! & Easy to understand!
Add any other context or screenshots about the feature request here.
No response

@kalashvasaniya animated search for?
can you elaborate this...

@kalashvasaniya animated search for?
can you elaborate this...

Just an animation that's it assign this pls. & Give lvl 1

@kalashvasaniya animated search for?
can you elaborate this...

Just an animation that's it assign this pls. & Give lvl 1

umm I don't think this can be of any much use, sorry can't assign this :(