Implementation of Brick Sort/ Odd even sort

Algorithm: Implementation Of Brick Sort
an odd–even sort or odd–even transposition sort (also known as brick sort or parity sort) is a relatively simple sorting algorithm, developed originally for use on parallel processors with local interconnections. It is a comparison sort related to bubble sort,   It is a comparison sort related to bubble sort, with which it shares many characteristics.
Languages Supported:

C [@jivthesh ]
C++
C#
Java
Python [@sparkingdark ]
JavaScript
go
dart

Would you like to work on it @sparkingdark ?

Adsign me the python.

Assign me c

@sparkingdark Go ahead with Python
@jivthesh  Go ahead with C

@VijayaGB98 please assign me this issue in C++( HakinCodes(P))

i would like to work with this by JAVA

Can I work on C++


Does clang compilation try to use GCC's libstdc++?

This is inspired by this question  on StackOverflow.
When trying to compile some code with clang-6.0:
#include <array>
constexpr std::array<int, 10> a{};
static_assert(std::next(std::begin(a)) == std::begin(a) + 1);

, I get an unexpected compilation error, but what's more surprising is that the errors seem to come from gcc 7.2.0's libstdc++ code:
<source>:4:15: error: static_assert expression is not an integral constant expression
static_assert(std::next(std::begin(a)) == std::begin(a) + 1);
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_iterator_base_funcs.h:201:32: note: non-constexpr function '__iterator_category<const int *>' cannot be used in a constant expression
      std::__advance(__i, __d, std::__iterator_category(__i));
                               ^
/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_iterator_base_funcs.h:214:7: note: in call to 'advance(__x, 1)'
      std::advance(__x, __n);
      ^
<source>:4:15: note: in call to 'next(&a._M_elems[0], 1)'
static_assert(std::next(std::begin(a)) == std::begin(a) + 1);
              ^
/opt/compiler-explorer/gcc-7.2.0/lib/gcc/x86_64-linux-gnu/7.2.0/../../../../include/c++/7.2.0/bits/stl_iterator_base_types.h:204:5: note: declared here
    __iterator_category(const _Iter&)
    ^
1 error generated.

Isn't this a bug?

Hi @eyalroz! Thanks for reporting this. As mentioned on #904, we'll take a look as soon as possible and will report back as soon as we know something.
Thanks again to @dodomorandi and you for taking the time to file an issue, we really appreaciate :)

https://github.com/mattgodbolt/compiler-explorer/blob/3ac06e33f97c2b60ce89308c9efa55d87d56121b/etc/config/c%2B%2B.amazon.properties#L81
From above, I think clang on godbolt indeed uses libstdc++ 7.2.0 by default. I'm not sure whether this is a bug or a feature. (BTW It's possible to override the default with --gcc-toolchain=/opt/compiler-explorer/gcc-snapshot or the like.)

That was the obvious potential difference between machines where the code is known to compile without errors to the compiler explorer. It could be something else, I'm only going on a hunch here.

By default clang uses GCC's standard library on Linux platforms. This is to keep compatiblity with libraries built by GCC, as I understand it.
As such Compiler Explorer uses GCC's libstdc++ by default, unless you specify otherwise, as noted above.
Sorry if this isn't clear: as far as I can tell Compiler Explorer just does what clang does by default.

@mattgodbolt : While I understand why there might be a reason to use libstdc++ on Linux distros, I believe that's somewhat confusing for Compiler Explorer to do. At the very least this should be made explicit. and I would seriously consider the suggestion in #905.

Regarding the "this should be made better-noticeable" bit I do admit that the UI is awful there! The i icon you see next to the options input is meant to display (on mouse over) what options we add to the compilation for you.
That is something we can improve, and we are open to suggestions if anyone has a good idea about how we should communicate it!
:)

Also, note that  the PR you mention is not yet merged only because I want to make sure it does not break unintended things by bumping the tooling version.
I'm not sure how to test that, so I'm leaving it to more capable people. If anyone feels like they could help, feel free to chime in :)

You could test it by, at first, adding  -stdlib=libc++ by default to the compiler flags for clang when people select it as a compiler in a new compiler window. People will at least not be entirely surprised by the behavior they get - and would be able to revert to the old behavior by removing that switch.

You could test it by, at first, adding -stdlib=libc++ by default to the compiler flags for clang when people select it as a compiler in a new compiler window. People will at least not be entirely surprised by the behavior they get - and would be able to revert to the old behavior by removing that switch.

I like this idea, but adding and removing flags when people flick between compilers is tricky to do without causing surprising results: what if I had already specified a stdlib? What if I choose a non-clang compiler afterwards (which has no such command-line paramter?) What if I switch back? It gets tricky. We are looking at #905 though, to at least help with this!
Having some "Hey, I'm managing these command-line parameters" might be OK in the long run, though, if we can get the UI right! :)


wavesurfer.js included in GitHub Archive Program!

wavesurfer.js was included in the "greatest hits" and the code will go to musea around the world :) Congrats to all contributors!

The “Greatest Hits” are archives of GitHub’s 17,000 most-popular and most-dependended-upon repositories, written to hardened  film designed to last for 1,000 years, enclosed in beautiful museum-quality cases, and donated to three of the world’s great libraries, on three different continents.

See https://archiveprogram.github.com/faq/
cc @katspaugh

Awesome, congrats! 👏

Awesome, congrats! 👏

awesome stuff! 🚀


HOTT-1654 Support LOCALE service tags

Jira link
HOTT-1654
What?
I have added/removed/altered:

[x] Added LOCALE_PATH and PREFIX_PATH service tags

Why?
I am doing this because:

The Welsh support requires them and without adding them to the admin they don't get previewed correctly

Marked do not merge since its just confusing until we have cause to enable the welsh support


electron-packager error

Tell me about your development environment.

Node version:v8.4.0
NPM version: 5.3.0
vue-cli version:2.8.1
Operating System:
electron-packager

this is why？

This is an error related to electron-packager. Please reach out to their respective communities for further guidance as this is not a direct issue with electron-vue.


Request: Add option to stop after current plot

Would it be possible to add an option to automatically stop after the current plot creation + copy to destination directory has been completed?
E.g. if you type "e" + enter or something?

Why not use Ctrl+C?

Why not use Ctrl+C?

Because you don't want to ruin the currently running plot, you don't want to let it start a new plot and put hundreds of temp files everywhere cluttering your drive, and you don't want to sit in front of your computer waiting for the precise moment when one plot finishes and the other starts. This is not an essential feature, but it may be useful.

It also doesn't work that way, there is never a time for a clean break as running "-n -1", a new plot process will start before the copy job finishes.  I also noticed that if there are 2 copy jobs in queue, it will pause before starting another plot until you only have 1 copy job waiting.  This was a pleasant surprise for me as my bottleneck is moving things across my the network and I was concerned that I would run into issues with finished plots piling up while they wait to get transferred.  The way he set this up, it's almost like you have a built in plotman running.

I was concerned that I would run into issues with finished plots piling up while they wait to get transferred

Exactly, that's why it's waiting

it's done. we can cllose this

It would be cool if there would be still possibitily to shut it down "hard" way. Right now if the software bugs and gets stuck - you can't stop it at all as it will wait until plot is finished ( infinity )

It would be cool if there would be still possibitily to shut it down "hard" way. Right now if the software bugs and gets stuck - you can't stop it at all as it will wait until plot is finished ( infinity )

Just kill chia_plot in System Monitor/Task Manager

It would be cool if there would be still possibitily to shut it down "hard" way. Right now if the software bugs and gets stuck - you can't stop it at all as it will wait until plot is finished ( infinity )

Just kill chia_plot in System Monitor/Task Manager

Would be handy if you wouldn't have to constantly close around 60 processes :) since it starts to open new threads. This issue shouldn't be closed without emergency shutdown.

It would be cool if there would be still possibitily to shut it down "hard" way. Right now if the software bugs and gets stuck - you can't stop it at all as it will wait until plot is finished ( infinity )

Just kill chia_plot in System Monitor/Task Manager

Would be handy if you wouldn't have to constantly close around 60 processes :) since it tries to open new threads - it's almost impossible to close without reboot. This issue shouldn't be closed without emergency shutdown.

What OS are you running? In Ubuntu top I see only 1 process chia_plot with multiple threads.

It would be cool if there would be still possibitily to shut it down "hard" way. Right now if the software bugs and gets stuck - you can't stop it at all as it will wait until plot is finished ( infinity )

Just kill chia_plot in System Monitor/Task Manager

Would be handy if you wouldn't have to constantly close around 60 processes :) since it tries to open new threads - it's almost impossible to close without reboot. This issue shouldn't be closed without emergency shutdown.

What OS are you running? In Ubuntu top I see only 1 process chia_plot with multiple threads.

You are comparing your situation where everything works to some type of bug situation that is completely uncontrolled.
But here you are:

And killing PID 24180 doesn't stop the process or making new ones. It's just impossible to kill.

Looks like an issue with your plotting manager /script, but would not killall chia_plot be sufficient?

Looks like an issue with your plotting manager /script, but would not killall chia_plot be sufficient?
This is normal build directly from git not any plotting manager/script. and no killall chia_plot doesnt fix it. It's just perma stuck after this Issue has been "resolved" by @madMAx43v3r


text: can't easily add newline when file ends in image literal (PY and TS)

If the file ends in an image literal, it's collapsed in such a way that there's no easy way to add a newline afterwards:

This happens a lot actually because it's common to write new code at the bottom of the file so you're frequently hitting this. It's especially bad with set background image since that image tends to be large and then expanding + adding new lines + collapsing is a pain.

I agree this one is bad. It breaks the flow on the first line of games.

Fixed by changing the folding behavior


Q) Build with VS2015 Update 3 problem

Expected Behavior
Build with no error
Actual Behavior
CreatePkgDef : error : FileLoadException: Could not load file or assembly
'Microsoft.NodejsTools.InteractiveWindow, Version=1.0.2015.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed.
(Exception from HRESULT: 0x8013141A)	InteractiveWindow

and 15 more Errors

NTVS Version: v1.1.x branch, also with master branch
Visual Studio Version: 2015 Professional Update 3
Node.js Version: N/A

Steps to Reproduce

Open Nodejs/NodejsTools.sln in VS2015
Menu Build > Build Solution

Is it just me or any other have this problem?

Looks like you need to disable strong name verification for the NTVS assemblies. Here are the instructions for that: https://github.com/Microsoft/nodejstools/wiki/Build-Instructions#manual-environment-setup-steps
Also, did you run the EnvironmentSetup.ps1 script?
Let me know if that works.

Wow,

ran  EnvironmentSetup.ps1
Registered Nodejs\Prerequisites\EnableSkipVerification.reg file
Got "Build: 27 succeeded". Thanks a lot!


Update workflows to support multi architecture image builds

Implements: https://github.com/dependabot/dependabot-core/issues/5037
This pr updates workflows to support multi-arch docker image builds.
This is done by adding https://github.com/docker/build-push-action github action to build images.
This pr implements following changes:

Use buildx with QEMU to build multi-arch images. Benefit of this approach is minimal modifications to Dockerfile. Downside is increased build time since emulation is not very fast.
Build ci docker image once and pass it to test jobs as an artifact. It can potentially reduce flakiness as I observed that docker build can sometimes fail when fetching dependencies etc.

Since we can't fully test this workflow in scope of pull request, I ran a few builds in my fork. Full time of core image build takes around 2h when no cache is present: https://github.com/andrcuns/dependabot-core/runs/7818717934?check_suite_focus=true. It produces correct images for both architectures: https://github.com/andrcuns/dependabot-core/pkgs/container/dependabot-core. I have also tried to build another image using dependabot-core as base and it seems to work correctly on M1 macbook now.
Some potential follow ups to improve build speeds:

Switch from inline cache to github cache. This also allows to use max cache mode which is useful for multi-stage dockerfiles. It will also add branch scoped caches so changes in pr's would be cached properly instead of always fetching inline cache from latest published image.
Split dockerfile in multiple stages. It should improve caching since update in some of the first instructions wouldn't invalidate whole Dockerfile cache. Though change is less trivial for some of the ecosystems since they also install system packages and it's not possible to simply copy produced executable from the separate stage. But I believe there was a closed pr which already attempted to split the core image in to multiple dockerfiles, it could be useful to use as a base

Thanks for digging into this! I'm concerned about introducing any changes that makes our CI even slower than it already is. Or, to put it more strongly, we can't accept any changes that make our builds slower.
I noticed the build step takes 23 minutes in this setup, I presume that's without being able to leverage any sort of caching? I'm not sure how quick it would be normally, but having a setup where we need to wait relatively long before we get any sort of meaningful test signals seems less than ideal. Do you have any data on how fast we should expect workflows to finish counting from a PR being opened?
I remember that we've experienced using artifact caching, but landed on rebuilding the image for every workflow, because downloading the image was still slower than doing a cached build. Maybe this has changed, but just wanted to share what I remember.
The staged builds seem promising, but it would probably still be faster to use those in conjunction without the QEMU setup?
Would it be possible to split this build out into a separate optional workflow to try and keep the required workflows as fast as possible?

I noticed the build step takes 23 minutes in this setup, I presume that's without being able to leverage any sort of caching?

Yes, the current CI build step is slower due to completely invalidated cache, essentially it builds the image from scratch (whole cache got invalidated by changing the TARGETARCH argument in Dockerfile which is at the very top). You would get roughly the same result when updating anything ruby related with existing setup. As far as CI job goes, actually nothing changed, it is using exactly the same setup as before, only instead of plain docker with manually enabled buildkit it uses the build and push action and buildx (which is essentially also a wrapper around buildkit with more options).

I remember that we've experienced using artifact caching, but landed on rebuilding the image for every workflow, because downloading the image was still slower than doing a cached build. Maybe this has changed, but just wanted to share what I remember.

I suspected it might be so. If we check the job output, core image build itself took 14 minutes to build but it takes 6 minutes to upload to cache, since it's a fairly large image. I can simply revert the last commit and it will bring back the ci workflow to exactly how it was before, just instead of plain docker commands it uses the build and push action.

Do you have any data on how fast we should expect workflows to finish counting from a PR being opened?

I can try and run the workflow with proposed change to github cache type, because it's the only way to populate cache without actually publishing latest core image. Right now cache is essentially locked to whatever we have in latest core image.

The staged builds seem promising, but it would probably still be faster to use those in conjunction without the QEMU setup?

Splitting in to stages would just improve docker caching. The way Dockerfile is structured right now as single stage means that update to rubygems version for example invalidates the whole docker cache since it is all one sequential stage. Separate stages would simply allow docker to understand that changes in ruby stage do not affect all other stages.
Getting rid of QEMU however is rather non trivial since it requires substantial changes to how different types of ecosystems are compiled (the ones that are compiled during the build and not just fetched as a pre-compiled binary). Here is a good read about it for more context: https://medium.com/@tonistiigi/faster-multi-platform-builds-dockerfile-cross-compilation-guide-part-1-ec087c719eaf

Would it be possible to split this build out into a separate optional workflow to try and keep the required workflows as fast as possible?

I think the best course of action to not introduce too many changes to existing workflow could be, wdyt?

Remove the change that passes docker image as artifact and essentially revert setup to the way it was before (I think it's fairly safe to leave the changes that introduce build-and-push action since it doesn't change actual behaviour, it just introduces more options compared to plain docker command)
Extract arm64 build to separate workflow of job for now, so the feedback from the existing release jobs remains intact

wdyt?

Yeah that sounds good to me! I hope we can dedicate some time to improve this setup across the board

Some build time comparisons, just for visibility:
Bundler update (invalidates cache for most of the Dockerfile) with existing setup: 12m
This PR with completely invalidated cache: 13.5m
Difference just due to system dependency still being cached when bundler version is being updated. So this PR shouldn't introduce any additional delay in CI feedback loop.

@jurre I have reverted all the changes that changed existing behaviour in any way. The arm builds are simply started as separate jobs and CI setup should be building image in exactly the same way with the difference of using buildx github action instead of plain docker command.
There are a few CI failures but I'm fairly certain these are not related to the changes.

Yeah they don't seem related, let me dig into those failures for a bit, these changes look good to me, thanks @andrcuns!

I pushed one more small fix, I noticed that git-shim isn't using TARGETARCH argument to download the correct executable

@andrcuns Is it possible to keep things easily runnable locally? We have this bin/ci-test script for simulating what CI does locally, and I had just refactored our CI workflows to use it at #5525, so that it never becomes out of date. We should consider what to do about it. I think it's neat to be able to easily run what the CI runs locally, any ideas?

@deivid-rodriguez What that build-and-push action does, is basically creates a docker command, so for sure it is possible to run locally.
Essentially what it runs now is:
docker buildx build --cache-to=type=inline --cache-from=type=registry,ref=ghcr.io/dependabot/dependabot-core --platform=linux/amd64 --load -t tag-to-push .
I would simply update the commands that can build locally, to also use buildx plugin.
Buildx plugin comes preinstalled with docker for windows/mac out of the box. Linux users will have to install it manually.

Yeah, that's what I figured. My thinking is that, if we have the commands needed refactored in a script that we can run locally, maybe the actions don't buy us anything? How about updating the commands here to use docker buildx instead of docker build and not use any custom actions. I'm pretty sure it won't be as simple, right? My main concern is that bin/ci-test will get out of date constantly unless we actually exercise it in CI.

It's obviously not my call, but my rationale has always been CI first and everything else second.
If you would opt using plain shell scripts for the sake of sometimes running similar docker command locally, you would end up essentially reimplementing all the niceties that github action provides in plain shell scripts. It would also require either pretty complicated argument parser or duplication in workflow files to correctly push multiple tags to multiple registries plus reimplementing arguments that can be passed to the build command, like platform, cache type etc.
Some flows wouldn't even be compatible with running locally, like using github cache type, which I would suggest to explore over inline cache as it opens up possibilities for properly caching multi-stage docker builds and adds capability of having branch scoped caches as well.
In my humble opinion there is no real need to necessarily have 1:1 docker build command for local use. The setup is rather simple (for now at least) in terms of building core docker image. Simple docker build . will provide the same final image anyway. Some specific options used in CI flow is nothing more than performance and build time improvements.

If you would opt using plain shell scripts for the sake of sometimes running similar docker command locally, you would end up essentially reimplementing all the niceties that github action provides in plain shell scripts. It would also require either pretty complicated argument parser or duplication in workflow files to correctly push multiple tags to multiple registries plus reimplementing arguments that can be passed to the build command, like platform, cache type etc.

I think this wouldn't be too bad, but of course someone needs to do the work. I normally like using actions in CI, but in this particular case I prefer the way it's done now with plain docker commands that can be easily extracted to a script and run locally.

Some flows wouldn't even be compatible with running locally, like using github cache type, which I would suggest to explore over inline cache as it opens up possibilities for properly caching multi-stage docker builds and adds capability of having branch scoped caches as well.

Even if not a current concern, but a potential future concern, this does not seem too bad either. The script can handle both CI and local usages. For example, at #5525 I'm only passing the -it flag when running locally, but not in CI.

In my humble opinion there is no real need to necessarily have 1:1 docker build command for local use. The setup is rather simple (for now at least) in terms of building core docker image. Simple docker build . will provide the same final image anyway. Some specific options used in CI flow is nothing more than performance and build time improvements.

You certainly know that, but a newcomer to the code base might not know the real differences and it can be reassuring to make sure you're reproducing locally what the CI is doing as exactly as possible.
All in all, my take here is that the benefits this PR is bringing are superior to the ones in #5525. So I'd say, green light to the approach in this PR, and if I feel it's worth merging everything back to bin/ci-test, I can take on that work later. But I'm happy of course to hear the opinions of other maintainers.

Hey guys,
nice idea ...
what`s missing that this PR can be merged ?

Actually chatted internally on this, and we may postpone this until after those guys finish splitting up the docker image by ecosystem... there's enough moving parts and some questions about the emulation slowness that it seems more straightforward to let that work finish and then re-evaluate this.
That said, with the popularity of Apple's M1 laptops, I expect this will continue to be a popular request and so this will happen at some point, it just might not be next week.
Also, for the build slowness, we'll have to figure out whether we gate our PR's on this, or do it as a side-car job that runs but doesn't block merges to main. That's probably more likely.
Anyway, some open questions... but even though I don't yet have answers, wanted to post a status update.

With the split in to separate images, the arm builds actually should be more feasible because it will be much faster overall since the Dockerfiles are much smaller and it's a lot better in terms of caching since updates in some ecosystem that was higher up in Dockerfile will not be invalidating all the steps after it.

Related:

https://github.com/dependabot/dependabot-core/pull/6588

Also, I haven't lost track of this... there's some other stuff we're waiting for internally that means we should probably keep this floating until that lands.

Maybe someone finds this useful, for now I have set up arm builds in my own fork using approach that was proposed in this pr: https://github.com/andrcuns/dependabot-core/blob/arm-images/.github/workflows/images-arm.yml
It's quite slow, especially the python updater image, so I wouldn't build arm images in pr's, probably only releases. I think the main problems come from not being able to properly cache things which comes from the Dockerfile setup.
The main issue with caching I believe is that this line for all non ecosystem specific changes will invalidate docker cache. That however basically invalidates cache for all ecosystem specific images, because they all have FROM core image instruction, and since that has changed, docker will have to rebuild the whole ecosystem image. Most of the ecosystem images are not compilation intensive, so it's not a huge issue except the python one. Installation of python versions with arm emulation is very slow.
The other issue is that inline cache is not very useful for building core image. Inline cache supports only min mode which means it can't cache all stages of multi-stage docker build.


Support secret findings in Git history for added and its adjacent lines

During the commit iteration of the Git history (#68) we need to find possible secrets via added and its adjacent lines. Those findings should not only store the value, filename and line number, but also the commit hash, when they were added.
ex.
secret = PotentialSecret(
    filename="path/to/file",
    secret="super-secret-password",
    line_number=123,
    added_commit="0bf7d3fce7742ace10d6690a7d5b45cca7b7ad17",
)

Fixed with #67


Card and form setup

Motivation

implementing a card
creating a form
next/router

Issues closed
#4 #5

Icon has already been declared
you are importing Icon and then creating a const Icon
import React from "react";
import { Icon } from "@iconify/react";
import StyledIcons from "./styled";

const Icon = () => {
	return (
		<StyledIcons {...props}>
			<Icon icon="bx:bx-home-heart" />
			<Icon icon="icon-park-outline:hold-seeds" />
			<Icon icon="uil:shovel" />
			<Icon icon="si-glyph:hat" />
		</StyledIcons>
	);
};

export default Icon;

Should be:
import React from "react";
import { Icon } from "@iconify/react";
import StyledIcons from "./styled";

const MyIcons = () => {
	return (
		<StyledIcons {...props}>
			<Icon icon="bx:bx-home-heart" />
			<Icon icon="icon-park-outline:hold-seeds" />
			<Icon icon="uil:shovel" />
			<Icon icon="si-glyph:hat" />
		</StyledIcons>
	);
};

export default MyIcons;


workflow script broken

#125 broke the workflow.js demo script

Fixed in https://github.com/KeychainMDIP/kc/commit/4a8fd519d636e9c959209ed9e150bba8371f8390


Menu Items are not Visible in navbar

In dark mode, Menu items are not visible . Could you assign this issue to me?

Go ahead @Laxmankohar

Hey @Saurav-Pant , I am getting this error. Could you please help to fix this issue?

try npm run lint

can I do this?

try npm run lint

Bro, It is still not working.

one time please fork the repo again then clone @Laxmankohar

one time please fork the repo again then clone @Laxmankohar

Still not working..


Add initial entities, corresponding instance attributes, and test files.

Add initial entities, corresponding instance attributes, and test files.

Approved


retries: 0 should retry indefinitely

The current implementation is that it doesn't retry when options = { retries: 0 }. As I understand, if you don't want to retry, simply skip this package.
On the other hand, allowing for indefinite retries would be super useful.
Thank you.

I've also tried { retries: Infinity } but that throws a very gross error :)

This module uses retry underneath so I suggest you to request that feature in the module itself, see: https://github.com/tim-kos/node-retry/issues/5

Closing this in favor of tim-kos/node-retry#5, once it's done it will be available here.


chore: homepage product grouping

PR-Codex overview
This PR enhances the homepage with updated content and styling changes.
Detailed summary

Updated homepage title and description
Added AnimatedCLICommand component for interactive CLI animation
Improved card layout and design in HomePageCard
Reorganized and optimized homepage sections and components

The following files were skipped due to too many changes: pages/index.tsx

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

📝 Changed routes:

/

(view full size)

Commit 65f2867edc67728ba13cd1e2ac13535ac8363c2a (https://thirdweb-7ufmi36o7.thirdweb-preview.com).


Check access token in self.token dict

Since we can supply access_token in the token dict, so we need to check both places at here.

Thanks!


How to disable authentication to bypass login?

Please follow the issue template instructions.

🙏 Asking a question or getting help: post in the Superset Slack chat or GitHub Discussions under "Q&A / Help".
💡 Requesting a new feature: Search GitHub Discussions to see if it exists already. If not, add a new post there under "Ideas".


feat: HL 1440 set archived status for applications

Description :sparkles:
HL 1440
Update application.archived as True after it has been cancelled in ahjo or processed in Talpa.
Issues :bug:
Testing :alembic:
Screenshots :camera_flash:
Additional notes :spiral_notepad:

APPLICANT branch is deployed to platta: https://helsinkilisa-ui-pr3236.dev.hel.ninja :rocket::rocket::rocket:

HANDLER branch is deployed to platta: https://helsinkilisa-ui-handler-pr3236.dev.hel.ninja :rocket::rocket::rocket:

TestCafe result is success for https://helsinkilisa-ui-pr3236.dev.hel.ninja :laughing::tada::tada::tada:

TestCafe result is success for https://helsinkilisa-ui-handler-pr3236.dev.hel.ninja :laughing::tada::tada::tada:


Add an 'ns' shortcut, tidy capital letters

Not 1.0 critical
@jlowdermilk

lgtm. Would be safe to add, but not worth cherrypick.

I'm not merging any code until Jenkins is green for a turn.

This is supposed to be v1-post. No need to merge this until we open the
gate.
On Jul 15, 2015 12:58 PM, "Eric Tune"<EMAIL_ADDRESS>wrote:

I'm not merging any code until Jenkins is green for a turn.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11313#issuecomment-121727480
.

LGTM
cc @hurf

@bgrant0607 I'll make related changes after this patch is merged.

@k8s-bot: ok to test

LGTM.

You don't think we can get rid of it?  We have a bunch of things that were
left until we crossed the 1.0 threshold.
On Wed, Jul 22, 2015 at 5:25 PM, Kubernetes Bot<EMAIL_ADDRESS>wrote:

GCE e2e build/test passed for commit 30697ae
https://github.com/GoogleCloudPlatform/kubernetes/commit/30697aeef200c10f6e022c18cf7cfb80595bc389
.

Build Log
https://storage.cloud.google.com/kubernetes-jenkins/pr-logs/30697aeef200c10f6e022c18cf7cfb80595bc389/kubernetes-pull-build-test-e2e-gce/3179/build-log.txt
Test Artifacts
https://console.developers.google.com/storage/browser/kubernetes-jenkins/pr-logs/30697aeef200c10f6e022c18cf7cfb80595bc389/kubernetes-pull-build-test-e2e-gce/3179/_artifacts/
Internal Jenkins Results
http://goto.google.com/prkubekins/job/kubernetes-pull-build-test-e2e-gce//3179

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11313#issuecomment-123914398
.

Did we print a deprecated warning or anything? We can't expect users to look at the code.

I don't think it is documented anywhere, but I also have not scanned
examples for use of it (out of the house now).  If no examples use it and
it is not documented...
On Jul 22, 2015 5:38 PM, "Brian Grant"<EMAIL_ADDRESS>wrote:

Did we print a deprecated warning or anything? We can't expect users to
look at the code.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11313#issuecomment-123917463
.

It's not in any examples and it is not documented.  I think we can kill
it.  I'll send a PR and we can debate.
On Wed, Jul 22, 2015 at 5:44 PM, Tim Hockin<EMAIL_ADDRESS>wrote:

I don't think it is documented anywhere, but I also have not scanned
examples for use of it (out of the house now).  If no examples use it and
it is not documented...
On Jul 22, 2015 5:38 PM, "Brian Grant"<EMAIL_ADDRESS>wrote:

Did we print a deprecated warning or anything? We can't expect users to
look at the code.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/11313#issuecomment-123917463
.


Support entitysets with cycles in their relationship graph

For example, a self-loop:
Entities:
  employees
Relationships:
  employees.manager_id -> employees.id

Or, a cycle involving multiple entities:
Entities:
  users
  roles
Relationships
  users.role_id -> roles.id
  roles.creator_id -> users.id

We should be able to create features that traverse these cycles once or more. For example, "The average salary of the direct reports of an employee's direct reports": MEAN(employees.employees.salary).
To support this there are at least two places in the code which assume there are no cycles and so will need to be updated:

EntitySet.has_unique_forward_path: When searching for paths this ignores entities which have already been seen – only traversing cycles once. In the case of the "employees" entityset above it would say that there is a unique path from employees to employees, even though there are infinite.
DeepFeatureSynthesis.build_features: Currently this will get stuck in an infinite loop when run on an entityset with a cycle (in the call to EntitySet.get_backward_entities(eid, deep=True)). To fix this we could add a max_relationship_depth param to limit the number of relationships which will be traversed. This would change existing behavior even in entitysets without cycles because there is currently no such limit (max_depth only limits the nesting of features, not the lengths of their relationship paths).

@CJStadler can this be closed now?


cmd/compile: types2 not giving error for missing method typeparam

Originally posted by @mpx in https://github.com/golang/go/issues/51232#issuecomment-1047613920
go version devel +c9fe126c8b Mon Feb 21 21:28:40 2022 +0000 linux/amd64
From
package boom

type Foo[T any, PT *T] struct{}

func (f *Foo[T]) boom() {}

..at least, the call chain is more or less the same compared to @dr2chase's example:
[..]
panic({0xcaba20, 0x1311df0})
        src/runtime/panic.go:838 +0x207
cmd/compile/internal/types.(*Type).IsImplicit(0xc000648690?)
        src/cmd/compile/internal/types/type.go:1907 +0x18
cmd/compile/internal/typecheck.(*iexporter).doDecl(0xc00063c000, 0xc00041a0d0)
        src/cmd/compile/internal/typecheck/iexport.go:568 +0x38d
cmd/compile/internal/typecheck.WriteExports({0xe93080, 0xc00061a1b0}, 0x1)
        src/cmd/compile/internal/typecheck/iexport.go:334 +0x2f0
cmd/compile/internal/noder.WriteExports(0xc000628010)
        src/cmd/compile/internal/noder/export.go:40 +0x7a
cmd/compile/internal/gc.dumpCompilerObj(0xc000628010?)
        src/cmd/compile/internal/gc/obj.go:107 +0x28
cmd/compile/internal/gc.dumpobj1({0x7fff5b4cc9ce, 0x23}, 0x3)
        src/cmd/compile/internal/gc/obj.go:63 +0x17b
cmd/compile/internal/gc.dumpobj()
        src/cmd/compile/internal/gc/obj.go:44 +0x36
cmd/compile/internal/gc.Main(0xd52330)
        src/cmd/compile/internal/gc/main.go:330 +0x11bc
main.main()
        src/cmd/compile/main.go:55 +0xdd

@griesemer @findleyr
Here's a very simple case where types2 is not giving an error when a method is missing one of the required typeparams for its generic receiver type.  This only appears to happen because the typeparam PT is expressed in terms of T.  The error is properly reported if we change PT *T to PT any

This is due to constraint type inference at the receiver type expression.
See also #51233 -- these are not really related, but both suggest to me that type inference for type instances is too naive, and we (I) didn't give it enough thought.

I don't think we should ever allow type inference at the receiver type expression. The spec is clear that we need to provide all type arguments. When we do, the error goes away as far as I can tell.


Turkish translation added!

Feel free to pull it from Polyglot!

@humdingerb can you pull this in and then close this one out?

Besides it needs updating after the switch to OpenMeteo, Turkish catkeys are already in tree.

Translations have been updated in Polyglot. Closing this, since it'll eventually be updated along with the other translations anyways.


pass at reducing warnings from clang on macOS

Description
Includes several small fixs that address compiler warnings.
Type of change
Please select one below (Please click check boxes AFTER submitting ticket)

[x] Bug fix
[ ] New feature
[ ] New Documentation

How Has This Been Tested?
Tested via compiling on macOS

@brugger1 @biagas @markcmiller86 can you please give this a quick look?

@markcmiller86 @biagas i think this is ready, can one of you approve? I don't wield admin powers unnecessarily :-)

I think when Kathleen left a comment "looks good" her intention was to approve it. But, someone needs to actually hit the Approve button in the PR review. I just did. Sorry about that.
Mark
"Cyrus Harrison" wrote:
@markcmiller86https://github.com/markcmiller86 @biagashttps://github.com/biagas i think this is ready, can one of you approve? I don't wield admin powers unnecessarily :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/visit-dav/visit/pull/3424#issuecomment-485022357, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABLUUZHLYBZ3YJUVMIZ4ZMLPRI42RANCNFSM4HGX7EVQ.

No worries, thanks @markcmiller86 !


Dynamic context menu open issue

Currently I need to use dynamic context menu like this (approximately):

    public onContextMenu($event: MouseEvent, contact: Contact): void {

        $event.preventDefault();
        $event.stopPropagation();

        this.getContextMenuAction(contact).subscribe( (actions: ContextMenuAction[]) => {
            this.contextMenuActions = actions;
            setTimeout(() => {
                this.contextMenuService.show.next({
                    // Optional - if unspecified, all context menu components will open
                    contextMenu: this.basicMenu,
                    event: $event,
                    item: contact,
                });
            });
        })
    }

onContextMenu by itself is a click event somewhere on a button.
<context-menu #basicMenu>
    <ng-template *ngFor="let action of contextMenuActions" contextMenuItem (execute)="action.execute()">
        {{action.translationTag | translate:action.translationArgs}}
    </ng-template>
</context-menu>

Though if I remove setTimeout two issues appear:

First time context menu is shown without items.
execute is not fired though menu is closed on click

Is there a reason for setTimeout call or am I doing something wrong?

Short answer: Yes, you need the setTimeout.
Long answer:
I haven't seen anyone try to do something like this, but here's what I'm guessing is happening.
Without the setTimeout:

this.contextMenuAction is initially undefined (or [] if you set it to that)
<context-menu> sees no contextMenuItems
Setting this.contextMenuActions does not immediately trigger change detection on the <context-menu> so it uses the old values.
The first click shows no items.

With the setTimeout:

and 2. same.
Having setTimeout allows a change detection cycle to run in the <context-menu> component so that it picks up the new <ng-template contextMenuItem>s.
The first click shows the new items.

I have no good explanation for why the execute isn't fired.

Thank you for the explanation.
What I was trying to achieve is this simple scenario:

User clicks on some element
Some async requests might step in to form contextMenuActions.
Context menu opens with generated contextMenuActions.

I think it might make sense to update your example with Dynamic context menu. Cause it actually demonstrates static context menu. It's important that after contextMenuActions are generated new change cycle should take place.

Yes, that's a valid use case and I agree that the <context-menu> should handle it more elegantly, but it currently doesn't.  Want to submit a PR to update the docs?  I'm always looking for help and you can write clear explanations.

We're having the same issue with using dynamic context menus. When looking at the code we identified the issue being the ContentChildren Input inside the ContextMenuDirective. As you mentioned it's the changeDetection that didn't update the values between setting the items and opening the context menu.
We also tried to call the changedetection manually between the two lines of code but didn't work. Also calling setTimeout is not working properly. We have to use a specific time of milisecods to get it working.
      this.contextMenuActions = actions;
      this.triggerChange();

      if (!actions || !actions.length || actions.every(a => a.hidden)) {
        return;
      }

      setTimeout(() => {
        this.contextMenuService.show.next({
          event: event.event,
          contextMenu: this.contextMenuComponent,
          item: null
        });
        this.triggerChange();
      }, 450);

In my opinion it's a very common use case to have one contextmenu and setting the entries dynamically with an ngFor. We're looking for a clean way to solve this, do you have any suggestions for us?


Add 4 missing quotes

When copy-pasting the HTML provided on the Creating a scene tutorial, glitch.com complains about it:

So I think this is a mistake and fixed it.

lol


support unwrapped TF

hi there,
currently one way teraflops sets itself apart from competitor terranix is it 'exposes terraform directly to you through nix', reducing maintenance burden while still exposing the full functionality of terraform.
at the same time, teraflops currently wraps various terraform commands, whereas terranix facilitates converting nix to terraform json once, then using the unwrapped TF cli.
whereas teraflops' tf subcommand now offers a partial escape hatch, it may be nice for users to not depend on that wrapper either, instead being able to use the TF cli directly. teraflops currently makes this harder by wiping generated json at the end of its cli commands.
one thing i tried to cope with this now is having it delay such removal to retain the main.tf.json, which i'd then combine with a no-op command such as teraflops -f $PWD tf version such as to get the json wanted by the TF cli without necessarily tagging on other commands.
it'd be nice however to see teraflops formally offer a sub-command that'd just do the TF nix-to-json conversion without removing the json after. i'd be curious to see your considerations on that.

definitely a great idea! the file is already cashed under .terraform/teraflops.tf.json and sometimes i cp that and use it... an official subcommand is awesome
i will put that together shortly
thanks!


No service dependencies found.

I ran the components on my laptop
jaeger/cmd/collector$ go run main.go --cassandra.keyspace=jaeger_v1_test

agent:
jaeger/cmd/agent$ go run main.go --collector.host-port=localhost:14267

query:
jaeger/cmd/query$  ./query --cassandra.keyspace=jaeger_v1_test --query.static-files=../../jaeger-ui/public --log-level=debug

query-ui:
git clone https://github.com/jaegertracing/jaeger-ui.git
cd jaeger-ui
npm install
npm run build

and then, ran Hot R.O.D.
i could find trace in "http://localhost:3000/search" and the certain services have dependencies.
but, when i enter "http://localhost:3000/dependencies" it displayed "No service dependencies found."
cassandra(3.11.1) displayed no dependencies but has opererations and traces
cqlsh> select * from jaeger_v1_test.dependencies;

 ts | dependencies | ts_index
----+--------------+----------

(0 rows)
cqlsh> select * from jaeger_v1_test.operation_names limit 2;

 service_name | operation_name
--------------+-------------------
 jaeger-query | /api/dependencies
 jaeger-query |     /api/services

when i ran jaeger in docker, it works fine.

no errors in the components and cassandra

http://jaeger.readthedocs.io/en/latest/deployment/#aggregation-jobs-for-service-dependencies


viewMode cannot work

i use viewMode:months and format:'YYYY-MM'，but when i click a month ,then open it again ,it shows the days viewmode,is that something wrong? expect your response.

Hi, this is a duplicate of:
#1854
#1894
#1959
#2061 <--just 6 Issues ago.....
and there's a quick fix at #1897
For this case if not wrong was fixed on lastest release

This was fixed on 4.17.47, so I'll close this for now


[formrecognizer] Sample + Migration guide improvements

API change check
API changes are not detected in this pull request.


Make ghost mode in snake the default mode

since the game isn't configurable in the "resume" tab, it would be better for the player experience to have ghost mode as the default mode rather than having walls

fixed by #ce36045


Increase default window size

The help text of some of our commands has become rather long. Entered commands can also become quite long. Users/testers would need to manually expand the window to more easily view the output panel's lines. There could be potential for this to be reported as a feature flaw.
Based on the project constraints of what resolutions/scaling the product needs to work for, we could consider increasing the default window size (in particular, its width). However, we should also consider whether the UI looks too strange if the default window size is made too large such that there is a lot of empty space.

We could also consider increasing the height of the output panel, assuming this is easy to do.


Revert "Recurring form fixed"

Reverts juntos-com-vc/juntos.com.vc#138

Coverage remained the same at 86.428% when pulling 8fcfc2736193c42fa21c2323416a8ea8887b8f3b on revert-138-fix/recurring-form into b67234a2118bf0be9c9774e8e08537d20e86dc0b on master.


List of packages in image

Is there a way to get a list of the OS packages that are installed when ko creates an image?  I'm looking for the package name and version.

Do you mean Go packages, or do you mean system packages?
For the latter, we (by default) base on distroless, which does have some mechanism by which it reports this.  @dlorenc may recall more than me here.
For the former, not that I'm aware of.  Depending on what you need (e.g. licenses), we have some places downstream where we solve similar problems.


When I open /rfx and /multimedia at the same time, I play the video with windows mediaplayer of version 12.0.7610.18840, and the screen will flicker

When I open /rfx and /multimedia at the same time, I play the video with windows mediaplayer of version 12.0.7610.18840, and the screen will flicker. The FreeRDP's git number is "16069e6", branch is master.

Closing due to lack of activity.
Reopen/create a new issue if still relevant.


release 2.7 w/ intuit login fixes

Let's resolve those login account selection bugs!

Release to pypi as 2.7!


update example changelogs so that they pass the seeded quality checks (DAT-10023)

Environment
Liquibase Version: N/A
Liquibase Integration & Version: N/A
Liquibase Extension(s) & Version: N/A
Database Vendor & Version: N/A
Operating System Type & Version: N/A
Pull Request Type

[X] Bug fix (non-breaking change which fixes an issue.)
[ ] Enhancement/New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
Update the seeded example changelogs so that they pass all of the enabled-by-default quality checks that Liquibase ships with.
Steps To Reproduce

Make a new empty directory
Run liquibase init project and make your changelog file xml, yml or json
Run liquibase init starth2 in another terminal
Run liquibase update
Run liquibase checks run --checksScope database and see that the output shows that the two tables we create in the seeded changelogs do not have a comment.

Actual Behavior
Checks run fails.
Expected/Desired Behavior
Checks run finds no failures.
Screenshots (if appropriate)
Additional Context
Fast Track PR Acceptance Checklist:

[ ] Build is successful and all new and existing tests pass
[ ] Added Unit Test(s)
[ ] Added Integration Test(s)
[ ] Added Test Harness Test(s)
[ ] Documentation Updated

Need Help?
Come chat with us in the Liquibase Forum.

@StevenMassaro Should this change be merged to both master and DAT-9298?

@StevenMassaro Should this change be merged to both master and DAT-9298?

No, just DAT-9298.


feature req: Need logIndex in type CallLogFrame when invoke API debug_trace*

Describe the feature
When you add tracerConfig: { withLog: true } , The result of Calls like debug_traceXXX will return log index (index inner tx) inside callframe logs array to make clear of the sequence of logs.
Erigon and other nodes support this feature. It is a very useful feature. It's a strong feature to let Apps migrate from Erigon to reth. Consider add this feature please.
Additional context
No response

I think what you want is the position field in Geth's, ref https://github.com/ethereum/go-ethereum/pull/28389
I'll implement this feature by backporting from Geth's.

GREAT! thanks a lot

we added position in the recent release ty @jsvisa


feat(JOML): migrate color

This is a rework of how colors work in nui. This is more consistent with JOML. I think this configuration should be easier to use. toVector3f, toVector3i and toVector4f are not used in any of the modules under omega or the engine. If its not used then It would probably be ok to just remove the methods entirely. I also update some of the documentation at the same time. There are some cases I'm probably not considering.
ref: https://github.com/MovingBlocks/Terasology/pull/4118

Note: This PR addresses the current state of NUI (gestalt v5). PR #4 needs to be updated in case we merge this first.


Added Dutch translations of country names

Hey, thanks for the great package, I've added Dutch translations of country names.

@tsinis Thank you for your contribution. Released in v2.0.19.


(#112) - document log options in README

I found I couldn't find the documentation anywhere
for how to change the log settings, so I added it
here to the README. It's unfortunate that there's
no way to write to a file but NOT to stdout; hopefully
we should fix that in #110.

timebombed

7c955ce1e5c33571ccceac50882f8886cb5c3f7e


Add check for java reserved works in AndroidResource items

Context #9461
Some users are seeing the following error from aapt2.
APT2258 invalid symbol name 'com.companyname.mauiapp1:drawable/import'.
C:\Users*User\AppData\Local\Temp\2kevcthb.kih\com\companyname\mauiapp1\R.java*"

This is because import is a java reserved word. The aapt2 code generator is not taking that into account (like we do for C# designer.cs). As a result we get this error. Its not very helpful.
So lets introduce a new error APT0004 which will explicitly check for java keywords in resource filenames.
This will allow users to know why their build is failing.

/azp run

Draft commit message:
Context: https://github.com/dotnet/android/issues/9461

[Android Resource names become Java identifiers][0], so if you have
an image named `Resources/drawable/import.png`, *eventually* this
will become part of an `R.java` file with contents:

	/* partial */ class R {
	    public static class drawable {
	        public static final int import = 0xdeadbeef;
	    }
	}

at which point `javac` gets irate, because `import` is a Java keyword
and that's not a valid location for that keyword.

Other Android tooling also knows about and respects this limitation,
e.g. `aapt2`, which could report:

	…com\example\app\R.java: error APT2258: invalid symbol name 'com.example.app:drawable/import'.

This isn't something we can fix; Java keywords cannot be used as
Android Resource names.

What we *can* do is improve the UX, and explicitly call this out.

Introduce a new error `APT0004` error which will explicitly check for
Java keywords in resource filenames.  This will allow users to know
why their build is failing:

	error APT0004: Invalid file name: Filenames cannot use Java reserved words.

[0]: https://developer.android.com/guide/topics/resources/providing-resources#Accessing

@dellis1972: while it's good to capture the filename case, that's not the only place where Resource names can appear and become Java identifiers.  Two more places that come to mind are:

Layouts
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent">
  <Button android:id="@+id/import" android:layout_width="match_parent" android:layout_height="wrap_content" android:text="@string/hello" />
</LinearLayout>

The android:id="@+id/import" should cause things to break.

Strings:
<resources>
  <string name="import">lol</string>
</resources>

Can we check for these other occurrences as well?  Should that be done as part of this PR, or separately?

@dellis1972: while it's good to capture the filename case, that's not the only place where Resource names can appear and become Java identifiers. Two more places that come to mind are:

Layouts
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android" android:orientation="vertical" android:layout_width="match_parent" android:layout_height="match_parent">
  <Button android:id="@+id/import" android:layout_width="match_parent" android:layout_height="wrap_content" android:text="@string/hello" />
</LinearLayout>

The android:id="@+id/import" should cause things to break.

Strings:
<resources>
  <string name="import">lol</string>
</resources>

Can we check for these other occurrences as well? Should that be done as part of this PR, or separately?

Lets do this in a new PR. The current task does not process the actual files. Plus we might need to take into account custom classes which happen later in the build system.


docs: Add contributing guidelines

This is very important especially for newer contributors

Done: https://github.com/dev-protocol/app/commit/b283001173f17619d0bd10d9434bc79605ec401e


Export OptionallyTypedRule to Lint.Rules namespace

PR checklist

[x] Addresses an existing issue: #2536
[x] New feature, bugfix, or enhancement

[ ] Includes tests

[ ] Documentation update

Overview of change:
See #2536 for more details.

Thanks for your interest in palantir/tslint, @bgold09! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

thanks @bgold09

@adidahiya my pleasure!


VertexBatchTest.Locking failing locally

Summary
The VertexBatchTest.Locking is failing for me locally
Expected: False
  But was:  True

   at Duality.Tests.Drawing.VertexBatchTest.Locking() in C:\Git\duality\Test\Core\Drawing\VertexBatchTest.cs:line 90

How to reproduce

Run the test
It fails (well or not because it does not fail on the CI)

Workaround

Ignore it as it only happens locally

Analysis

Likely happens due to something environment specific. The question is what?

The specific part of the test that is failing is this:
// Make sure that our locks released properly, i.e. allowing the array to be garbage collected
WeakReference weakRefToLockedData = new WeakReference(typedBatch.Vertices.Data);
Assert.IsTrue(weakRefToLockedData.IsAlive);
typedBatch = null;
abstractBatch = null;
GC.Collect();
Assert.IsFalse(weakRefToLockedData.IsAlive);

Which is dependent on garbage collection behavior, or more specifically the assumption that GC.Collect will free the vertex data array synchronously before returning. Could this be related? Are there ways to ensure this across runtime / GC versions?

It does not do it synchronously:
https://stackoverflow.com/questions/748777/run-gc-collect-synchronously
Also I think depending on the GC like this is very error prone as it can change between runtime or config settings.

Also I think depending on the GC like this is very error prone as it can change between runtime or config settings.

It is, but since this part of the test is essentially a GC test, there's not really a way around that.

It does not do it synchronously:
https://stackoverflow.com/questions/748777/run-gc-collect-synchronously

That's likely the issue then. Could be worth a try to use this overload instead and also wait for pending finalizers afterwards.

Adjusted the test as described above. @Barsonax Can you check whether the issue is fixed on your machine?

Will check when iam at my pc

It did not fix the issue

Only happens in Debug mode, under release mode the test runs succesfully.
So this error can be fixed by skipping this test in debug mode (no sense in running it if it always fails). In nunit this can be done by making a custom NUnitAttribute and implementing IApplyToTest. Ofcourse a reasonable message should be given explaining that it does not run in debug.

Fixed in #719


BUG - fivetran_utils 0.3.2 has incompatible dependency on fivetran_utils vs hubspot

Are you a current Fivetran customer?
Please tell us your name, title and company
Yes! Joel, Head of Data & Insights at Education Perfect
Describe the bug
We did a revamp of our packages after upgrading to dbt 0.20.0, but the triangle of fivetran_log, hubspot, and dbt_expectations has gotten us into trouble.
Steps to reproduce
Our desired packages.yml:
packages:

  - package: dbt-labs/audit_helper
    version: 0.4.0

  - package: dbt-labs/codegen
    version: 0.4.0

  - package: dbt-labs/redshift
    version: 0.5.0

  - package: fivetran/fivetran_log
    version: [">=0.3.0", "<0.4.0"]

  - package: fivetran/hubspot
    version: [">=0.4.0", "<0.5.0"]

  - package: calogica/dbt_expectations
    version: 0.4.0

Output of dbt deps:

PS C:\WF\LP\data-insights\ep-dbt> dbt deps
Running with dbt=0.20.0
Encountered an error:
Version error for package fivetran/fivetran_utils: Could not find a satisfactory version from options: ['>=0.1.0', '<0.2.0', '>=0.2.0', '<0.3.0']

Expected behavior
Successful installation of all dependencies
Warehouse

[ ] BigQuery
[x] Redshift
[ ] Snowflake
[ ] Postgres
[ ] Databricks
[ ] Other (provide details below)

Additional context
Output when fivetran_log is commented out:
PS C:\WF\LP\data-insights\ep-dbt> dbt deps
Running with dbt=0.20.0
Installing<EMAIL_ADDRESS>  Installed from version 0.4.0
Installing<EMAIL_ADDRESS>  Installed from version 0.4.0
Installing<EMAIL_ADDRESS>  Installed from version 0.5.0
Installing<EMAIL_ADDRESS>  Installed from version 0.4.0
Installing<EMAIL_ADDRESS>  Installed from version 0.4.0
Installing<EMAIL_ADDRESS>  Installed from version 0.7.0
Installing<EMAIL_ADDRESS>  Installed from version 0.4.0
Installing<EMAIL_ADDRESS>  Installed from version 0.4.0
Installing<EMAIL_ADDRESS>  Installed from version 0.2.1

Output when fivetran/hubspot's version is ">=0.3.0", "<0.4.0" (I assume it references fishtown-analytics/dbt-utils but haven't checked):
PS C:\WF\LP\data-insights\ep-dbt> dbt deps
Running with dbt=0.20.0
Encountered an error:
Found duplicate project "dbt_utils". This occurs when a dependency has the same project name as some other dependency.

Screenshots

Please indicate the level of urgency

I can work around this by disabling fivetran_log, but that's a pain
Are you interested in contributing to this package?

[x] Yes, I can do this and open a PR for your review.
[ ] Possibly, but I'm not quite sure how to do this. I'd be happy to do a live coding session with someone to get this fixed.
[ ] No, I'd prefer if someone else fixed this.  I don't have the time and/or don't know what the root cause of the problem is.

@joellabes I just cut a release for v0.4.0 of the dbt_fivetran_log package. This version of the package is compatible with dbt v0.20.0 and you should now see succesfull installation of all packages you shared above. Please let me know if you experience any other issues when upgrading.
Thanks again for contributing on this upgrade!


Make the namespace filter more discoverable

Sometimes users get confused as to why they can't see resources in Cluster Explorer that they expected to see.
It could be because the namespace filter is not visually close to the Cluster Explorer side nav, which has everything else you need for cluster explorer:

We could consider moving the namespace filter to the top of the side nav with the aim of making it more discoverable.

Related epic closed and we've modified this behaviour in other work so closing as done. Feedback on subsequent improvements welcome but please confirm on a more recent version on how the picker looks.


Revise the vi mode indicator to ❮ for non-insert modes

related: #139

This PR changes the default behavior of the prompt in vi mode, as discussed in #139.
Previously, the prompt retained the fish shell's default mode indicator: it would print [I], [N], or [V] to indicate whether the user was in insert, normal, or visual mode.
After this commit, the prompt will flip to ❮ whenever the user is not in insert mode.  This matches the behavior of the zsh version of Pure.
The user can restore the prior functionality by setting the pure_reverse_prompt_symbol_in_vimode variable to false in their conf.d/pure.fish file.

Thanks for the comments.
I revised the PR to address your comments on the code, and took all your suggestions.
With regards to testing, I added one simple test for the config variable.  However, both on my local machine and the CI checks, the tests are not providing meaningful feedback—I am getting fish: 'end' outside of a block instead of results based on whether the test passed or failed.  (This is true even if I add tests that should fail.)
Given that I'm not able to see if the test is passing or not, I'm not particularly comfortable with writing a more complex test (especially since I'm not familiar with fish scripting or with whatever this test environment is).
If anyone else is more familiar with testing/has a setup under which the tests run, they should feel free to add an additional test for the rest of the functionality.

@codesections I committed some change, could you test it's the expected behaviour?

Yes, it seems to work great.  Thanks!


Fix performance of array initialization from a generic sequence.

This fixes a major perform bug involving array initialization from any
contiguously stored collection. This is not a recent regression. This fix
results in a 10,000X speedup (that's 4 zeros) for this code path:
func initializeFromSlice(_ a: [Int]) -> [Int] {
return Array(a[...])
}
A benchmark is included.

@swift-ci test.

@swift-ci test source compatibility.

@swift-ci benchmark

@swift-ci build toolchain

Linux Toolchain (Ubuntu 16.04)
Download Toolchain
Git Sha - 6d3397337d0f64e961e66930f4d809b30fbcca84
Install command
tar zxf  swift-PR-22541-158-ubuntu16.04.tar.gz
More info

Performance: -O

TEST
OLD
NEW
DELTA
RATIO

Regression

SortStringsUnicode
3305
3610
+9.2%
0.92x (?)

FlattenListLoop
3968
4331
+9.1%
0.92x (?)

Array2D
6912
7520
+8.8%
0.92x (?)

MapReduce
368
397
+7.9%
0.93x

ObjectiveCBridgeStubNSDateRefAccess
371
400
+7.8%
0.93x (?)

FlattenListFlatMap
6098
6560
+7.6%
0.93x (?)

MapReduceAnyCollection
370
398
+7.6%
0.93x (?)

Improvement

Data.hash.Empty
74
68
-8.1%
1.09x

Added

ArrayInitFromSlice
395
406
399
—

Code size: -O

TEST
OLD
NEW
DELTA
RATIO

Regression

ArrayOfGenericPOD.o
2735
4039
+47.7%
0.68x

Improvement

Codable.o
27891
27011
-3.2%
1.03x

Performance: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

ObjectiveCBridgeStubFromNSString
908
1041
+14.6%
0.87x (?)

SortStringsUnicode
3305
3590
+8.6%
0.92x

ObjectiveCBridgeStubFromArrayOfNSString2
3430
3700
+7.9%
0.93x (?)

Improvement

InsertCharacterEndIndexNonASCII
64
58
-9.4%
1.10x (?)

Added

ArrayInitFromSlice
387
387
387
—

Code size: -Osize

TEST
OLD
NEW
DELTA
RATIO

Regression

ArrayOfGenericPOD.o
3009
4273
+42.0%
0.70x

Improvement

Codable.o
27907
27075
-3.0%
1.03x

Performance: -Onone

TEST
MIN
MAX
MEAN
MAX_RSS

Added

ArrayInitFromSlice
503
515
507
—

Code size: -swiftlibs

TEST
OLD
NEW
DELTA
RATIO

Improvement

libswiftMetal.dylib
40960
36864
-10.0%
1.11x

✅
Benchmark Check Report

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

Build failed
Swift Test OS X Platform
Git Sha - 6d3397337d0f64e961e66930f4d809b30fbcca84

macOS Toolchain
Download Toolchain
Git Sha - 6d3397337d0f64e961e66930f4d809b30fbcca84
Install command
tar -zxf  swift-PR-22541-205-osx.tar.gz --directory ~/

@swift-ci smoke test OS X platform.


Implement ERC721.cairo

This PR implements ther ERC721 standard for starknet contracts written in Cairo.
The implementation here tries to be as close as a literal translation of OpenZeppelin's ERC721.sol contract.
The initialize function should be similar to the constructor function in solidity.
Missing feature are:

_symbol

_name

tokenURI

_baseURI

symbol and name have not been implemented because cairo currently doesn't have a string type.

tokenURI and baseURI are WIP (by WIP I mean more like R&D at this point :))

Note: I'm not familiar with the hook _beforeTokenTransfer so the implementation in Cairo might be a little bit naive.

@martriay I've just added two commits that support name and symbol with short strings (i.e. strings that are < 31 characters).
For the tokenURI, we were thinking about storing a string that would correspond to Chain Agnostic CAIP-22 and CAIP-29.
Let me know what you think :)
PS: I know TokenURI could be only two felts instead of three if we stored the byte directly instead of the string representation, but I thought it would be easier to stick with the string repr. Let me know what you think :)

Thanks for doing this and sorry for keeping this PR waiting for so long. Will prioritize it in the short term.
Could you expand a bit more on the two/three felts issue?

Now that I think about it I just come to realize that the ChainAgnostic tokenURI is really cool... when bridging lol. It doesn't make sense for native L2 tokens...

Excellent draft! Superceded by #94


squashed and merged commits?

Hey, want to bring to the attention about an issue I noticed in this project.
It appears that all git commits are squashed, so the original author/committer info gets lost in git log.
This may not be a big deal, but if we want to motivate more new people to contribute, it might be important.

Hi @weimingzha0, this is somewhat by design at the moment. None of the pull requests are squashed. Instead lot of the code is rewritten or manually ported, optimizing for shorter review cycles and maintainability.


What Scopes are required for Github token?

What scopes are required for the Github token? I only want to give minimal permissions for hopefully obvious reasons.

Oy public repo read access is needed

Actually, there are no scopes required for the token

I tried it yesterday with no scopes - that didn't work.
I needed to add public_repo scope to make it work

Same. I tried it with no scopes originally and it would fetch the repo and display the templates, but would not allow the downloads.

hmm, its strange.. I tested token without any permissions and it works fine.


[Cypress] adding mochawesome report artifact to UI tests

PR for: https://github.com/epinio/epinio-end-to-end-tests/issues/144
Changes implemented

Installed mochawesome reporting tool in our Cypress test to improve quality reporting and easiness to locate errors by attaching screenshots and videos to exact errors.

Explanation

CI will autogenerate an artifact named mochawesome report with all passing / failing tests like this one: mochawesome-report.zip

If succeeds, a green mark check with the content of the test will be displayed:
If fails, the test will be marked in red, displaying the error, a screenshot an a video attached to the specific scenario:

The artifact needs to be downloaded an opened in a browser the mochawesome.html file

Tested on CI  with a small sample of 1 test passing and 1 failng: https://github.com/epinio/epinio-end-to-end-tests/actions/runs/3178115569
Small demo
https://user-images.githubusercontent.com/37271841/193771119-e6a4c69f-7ceb-4d98-bbe3-effa28ff630f.mov
Note:
The default version of mochawesome, creates a report without screenshots nor videos in it and calls the route where these ones are placed by default to 'bind' them to the main report to be later visualized. The problem is that it seems in our CI the screenshots and video files are not reachable aside from artifacts. This was workarounded by copying those files within the mochawesome-report and pointing the binding function to this route. Since we are not copying automatically screenshots and videos to the mochawesome-report locally, the reports will appear by default without them unless they are copied manually.

When tested in CI with all the runners in parallel, since there was a sole html file it was overriden all the time, leaving the report with the latest test solely: https://github.com/epinio/epinio-end-to-end-tests/actions/runs/3180302125
This was overcome by renaming an html per test https://github.com/epinio/epinio-end-to-end-tests/actions/runs/3181147403.

Fixed another issue where, after an initial failed run and a successful second one, the step where screenshots were not attached would be marked as failed, raising a failed flag. This is fixed now and 2 runs, one failed and another one successful will be correctly marked with 2 rounds of files present in the artifact.
Example:
Round 1 failed: https://github.com/epinio/epinio-end-to-end-tests/actions/runs/3182560567/attempts/1

Round 2 successful:https://github.com/epinio/epinio-end-to-end-tests/actions/runs/3182560567

Both flags respond correctly to the change of situation.

Thanks @thehejik
Tested on several CI and working as expected.
Merging


Geo lastools qgis

Added lastools.md and qgis.md

Leave  .DS_Store file out from the commit

computing/connecting.md is not present in this branch.
It is now in the master branch so test should be ok after merge.


Bugfix deploy

Coverage remained the same at 100.0% when pulling b52d8c432851d3f3eb51ce8035fe9a667db6db94 on bugfix-deploy into 868b6702d20cb910defe9a0cdb8bfaa57112812a on develop.


Improve API example/sample scripts for 0.54+ compatibility

This ticket holds the tasks for improving the sample-api-scripts for 2022 alpha trading using 0.54+ Vega release compatibility.
The resulting code will aim to:

[ ] Support the move to docs.vega.xyz (docusaurus)
[ ] 0.54+ Vega code releases, inc data-node APIs
[ ] BC new builder curriculum
[ ] Feedback and suggestions from 2 years+ of supporting the sample-api-scripts with community and internal users on Fairground testnet

Related #142

Related #143 #144 #145 #146 #147 #148 #149 #150 #151 #152 #153 #154 #155 #156 #157 #158 #159

Completed by #163


Placeholder for Spotlight 3 upgrade

Upgrade to Spotlight 3, which uses Blacklight 7.

As part of this upgrade we'll be able to (and maybe have to) remove the lines added in https://github.com/pulibrary/pomegranate/pull/838
We ignored this one deprecation: https://github.com/pulibrary/pomegranate/issues/837

Step 1: Read any documented release notes to see if something is likely to break.
Step 2: Create tickets for any deprecations that exist from a clean test run.
Step 3: Try just upgrading the gem, see how hard this is going to be. Create follow-on tickets if we're going to be able to parallelize this work.
Related to https://github.com/pulibrary/dpul/issues/872

we're upgrading from

spotlight 2.9.0
blacklight 6.24.0

Do this in a long-running branch.


Merge remote-tracking branch 'refs/remotes/origin/service/engine' int…

…o msalem

merge with service engine


Neuroml hdf5 import error

User: "when I tried to run the very first tutorial I ran into an error. When it tries to load 'sim' from 'netpyne', I get the following error:
ImportError: No module named hdf5.DefaultNetworkHandler
I think it has something to do with import/export of NeuroML networks etc. I have NeuroML (especially pyNeuroML) installed. So I am not sure what the problem is. Do I have to update pyNeuroML? Is there a workaround, since I do not plan to convert/import to/from NeuroML at the moment?
Commenting out the 'from neuromlFuncs import *' line in 'sim.py' worked. If I am not going to use any NeuroML functionality, this workaround should not cause any problems, right?"

It's most likely to do with an earlier version of pyNeuroML. The latest is on PyPI, so you could just upgrade with:
sudo pip install --upgrade pyneuroml


Updated translations

@GabrielInTheWorld can you check why the motion state.name is not translated (in motion list and motion detail view)?

It looks like some of your last translation fixes are not rebased correctly by your rework branch. E.g. the translation of input values in meeting config is missing again...


Gradle Continuous Mode Infinite Loop

org.springframework.experimental.aot = 0.11.1
If I run in continuous mode:
./gradlew -t test

It runs and re-runs the tests infinitely due to:
new directory: /home/jw/projects/kotlin-bars/server/build/generated/sources/aotTest
new file: /home/jw/projects/kotlin-bars/server/build/generated/sources/aotTest/org/springframework/aot/TestContextBootstrapInitializer.java
new file: /home/jw/projects/kotlin-bars/server/build/generated/sources/aotTest/org/springframework/aot/TestContextBootstrapInitializer0.java

I tried on commandlinerunner-gradle sample and can't reproduce, could you please share a reproducer?

Might be something unique in my setup.
Use this repo:
https://github.com/jamesward/kotlin-bars
Run:
./gradlew -t :server:test

I can reproduce with your sample, not sure yet what triggers it. Could be Kotlin specific or multi-module specific for example.

@bclozel Could you please give a try to James sample to see if you see something obvious that we should fix in the Gradle plugin or document?

Spring Native is now superseded by Spring Boot 3 official native support, see the related reference documentation for more details.
As a consequence, I am closing this issue, and recommend trying your use case with latest Spring Boot 3 version. If you still experience the issue reported here, please open an issue directly on the related Spring project (Spring Framework, Data, Security, Boot, Cloud, etc.) with a reproducer.
Thanks for your contribution on the experimental Spring Native project, we hope you will enjoy the official native support introduced by Spring Boot 3.


Create Power BI page on storefront.

https://github.com/orgs/equinor/projects/37#card-47266590

I'll wait until we have zeroheight in place if that is happening soon.

Added a page for Power Platform and Power BI in zeroheight.
https://zeroheight.com/0b0c666ab/v/latest/p/917e28-power-bi


Write integration test for multi-hop channels

Summary
The test can probably be written as an NaryConnectionTest<3>. It seems like we probably also need to modify the core channel logic in ibc-relayer to make it possible to create channels with custom numbers of connection hops.
Depends on:

[ ] https://github.com/cosmos/ibc/pull/836

For Admin Use

[ ] Not duplicate issue
[ ] Appropriate labels applied
[ ] Appropriate milestone (priority) applied
[ ] Appropriate contributors tagged
[ ] Contributor assigned/self-assigned

Closing this as the listed PR that this work depends on has been closed as un-planned.


Handle overlapping thumbs for MultiSlider

When overlapping values for the MultiSlider are allowed, but they cannot pass each other, and two or more sliders are at the min or max value of the slider bar, the event to move one of the sliders can be given to the 'wrong' underlying slider. This means that the slider that receives the drag mouse event is not allowed to move past the other slider. Therefore, at 'min' or 'max', the order in which overlapping thumbs receive mouse events has to be carefully orchestrated.

The demos with passing restrictions set to 'true' indeed reveal that thumbs can get stuck. The dispatcher has to become 'smarter' to select the thumb that receives the mouse event (click, drag). Note that the location of the mouse (left or right for a horizontal slider; above or below for a vertical slider) determines for a mouse click which thumb should move. Dragging should work when the thumbs are not in their min or max position, but when three thumbs are on top of each other, and the 'middle' one is selected, it can not go above, nor below the other two. So, also in these cases, we need to resolve the thumb that has the ability to move.

This is a lot more complicated than I originally thought... Except for a few simple cases (see below), determining which slider to move when a user clicks in the neighborhood of a number of overlapping sliders is for sure not straightforward...

Simple case 1: getPassing() && getOverlap() is true, which means: no restrictions. Move any slider.
Simple case 2: no overlapping sliders closest to the mouse click. Move the closest slider.

The cases become complicated when there are multiple overlapping closest sliders and !getPassing() || !getOverlap(). Here, we need to choose which slider can move. When overlapping sliders are at the minimum or maximum position, moving freedom to check is unidirectional. When sliders are overlapping in the middle, moving freedom to check is bidirectional.
The slider to move is not only dependent on blocked positions directly higher or lower than the slider position, but also on the sequence number of the sliders (remember, sliders cannot pass each other). See the below example:
Suppose, sliders 1, 2 and 3 are overlapping halfway on the slider (we assume a standard left-right slider), and we have !getPassing():

slider 1 can only move left. When moving right, it would illegally pass slider 2 and violate 1<=2.
slider 2 cannot move at all. When moving left, it would violate 1<=2; when moving right it would violate 2<=3.
slider 3 can only move right. When moving left it would illegally pass slider 2 and violate 2<=3.
Return: either slider 1, and a left direction, or slider 3 and a right direction. This can be dependent on where we click with the mouse(!).

Suppose, sliders 1, 2 and 3 are overlapping on the low side of the slider (which can be left, right, top or bottom, depending on the direction and whether the scale is inverted or not; here we assume a standard left-right slider), and we have !getPassing():

slider 1 cannot move at all. It cannot move left. When moving right, it would illegally pass slider 2 and violate 1<=2.
slider 2 cannot move at all. It cannot move left; when moving right it would violate 2<=3.
slider 3 can move right. It cannot move left. When moving right, 1<=2 and 2<=3 are preserved.
Return: slider 3, and a right direction.

Suppose, sliders 1, 2 and 3 are overlapping on the high side of the slider (which can be left, right, top or bottom, depending on the direction and whether the scale is inverted or not; here we assume a standard left-right slider), and we have !getPassing():

slider 1 can move left. It cannot move right. When moving right, 1<=2 and 2<=3 are preserved.
slider 2 cannot move at all. It cannot move right; when moving left it would violate 1<=2.
slider 3 cannot move at all. It cannot move right. When moving left, it would illegally pass slider 2 and violate 2<=3.
Return: slider 1, and a left direction.

Can a slider directly left or right of the overlapping sliders pose a limit on moving left or right?
Take:
          2
          3
         156
=====================

Sliders 2, 3 and 5 are on top of each other. One notch down, slider 1 is present (it cannot, e.g., be slider 4 since that would have violated 2<=4 earlier), and one notch to the right, slider 6 is present (it cannot, e.g., be slider 1 or 4 because that would have violated 4<=5 earlier). Suppose we click on the location of sliders 2, 3 and 5. What are the movement options?

slider 2 can only move left. When moving right, it would illegally pass slider 3 and violate 2<=3. Note that by moving left, it does not violate any passing rule. Still, 1<=2 is honored when sliders 1 and 2 are overlapping. Of course, slider 2 cannot move any farther left after that, since then it would violate 1<=2.
slider 3 cannot move at all. When moving left, it would violate 2<=3; when moving right it would violate 3<=5.
slider 5 can only move right. When moving left it would illegally pass slider 3 and violate 3<=5. Note that by moving right, it does not violate any passing rule. Still, 5<=6 is honored when sliders 5 and 6 are overlapping. Of course, slider 5 cannot move any farther right after that, since then it would violate 5<=6.
Return: either slider 2, and a left direction, or slider 5 and a right direction. This can be dependent on where we click with the mouse(!).

What can we learn from these examples?

There are no restrictions posed by sliders directly to the left or right of an overlapping slider.
The slider with the lowest number can always move 'left' and the slider with the highest number can always move 'right', where left and right have to be correctly interpreted for horizontal and vertical, inverted and non-inverted sliders.

The overlapping thumbs have now been completely handled. UI updates caused a problem for a long time, especially after the mouse cursor lost focus during a drag event, which led to a slider thumb being drawn at the last location. No code except setUI(getUI()) could force the thumb to redraw.
The current solution to this problem is to 'emulate' a mouse released event somewhere IN the underlying JSlider window. This forces the UI to update the thumb position:
@Override
public void mouseExited(final MouseEvent e)
{
    setBusy(false);
    // emulate a mouse release somewhere on the current slider to force correct update
    var ms = DispatcherPane.this.multiSlider;
    if (ms.getBusySlider() >= 0)
    {
        JSlider js = ms.getSlider(ms.getBusySlider());
        checkRestrictions(ms.getBusySlider());
        MouseEvent meSlider = new MouseEvent(js, MouseEvent.MOUSE_RELEASED, e.getWhen(), 0, 10, 10, 1, false,
                MouseEvent.BUTTON1);
        js.dispatchEvent(meSlider);
        ms.fireFinalValueChanged();
    }
    setBusySlider(-1);
}

With these changes, the unit tests work, and the demo that checks passing and overlap restrictions work as intended.


Smokescreen camo

Adjust supervisorctl to make smokescreen upgrade itself correctly on new releases, and add camo to the profile.
Testing plan: Stood up a new smokescreen host.

Merged, thanks @alexmv!


How to get the Coord after moving the map?

Hi Guys Maybe it's a simple question
But I would like to capture the coords and put in a hidden field..
Can anyone help me?

I am a newb too. I think there is a getCenter() function you can use though with leaflet. I haven't made it that far yet :)

Tks! :)


Update Pages “PrePurchaseTimberInspectionPage”

Automatically generated by Netlify CMS

👷 Deploy Preview for chic-shortbread-66a66b processing.

Name
Link

🔨 Latest commit
a9cf827240d9130cfc560c5b3b94ed3c3f4cf995

🔍 Latest deploy log
https://app.netlify.com/sites/chic-shortbread-66a66b/deploys/655fd7639265bb00088403c6


Update propeller to 0.5.14

TL;DR
Update propeller to 0.5.14 to pickup branches fixes.
Type

[X] Bug Fix
[ ] Feature
[ ] Plugin

Are all requirements met?

[X] Code completed
[X] Smoke tested
[X] Unit tests added
[X] Code documentation added
[X] Any pending items have an associated Issue

Codecov Report

Merging #149 (d471f92) into master (26785a4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #149   +/-   ##
=======================================
  Coverage   61.79%   61.79%
=======================================
  Files         105      105
  Lines        7534     7534
=======================================
  Hits         4656     4656
  Misses       2286     2286
  Partials      592      592

Flag
Coverage Δ

unittests
61.79% <ø> (ø)

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

Continue to review full report at Codecov.

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

Codecov Report

Merging #149 (d471f92) into master (26785a4) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #149   +/-   ##
=======================================
  Coverage   61.79%   61.79%
=======================================
  Files         105      105
  Lines        7534     7534
=======================================
  Hits         4656     4656
  Misses       2286     2286
  Partials      592      592

Flag
Coverage Δ

unittests
61.79% <ø> (ø)

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

Continue to review full report at Codecov.

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


mozilla file input click fix

file input click was not working in some mozilla browser versions, because of the selector that had been changed changed by current commit that was previously returning not the file input but an 'md-errors-spacer'

I fix this by myself on newest release ! but thanks anyway !


[INFORMATION SHARE] A web based kubectl tool.

Hi there,
We developed a web based kubectl tool, which enables you to manage kubernetes credentials and run kubectl command in web browser.
https://github.com/webkubectl/webkubectl
Hopefully it's useful for you guys.

Thanks for your sharing! That looks promising.
However, github issue is for bug reporting and feature requesting, closed due to irrelevance, feel free to reopen this issue if you have any problem using kubectl-debug.


iOS integration Error

@SpertsyanKM, I am testing the purchases for iOS, and getting these outputs:
1- I tried on a real device (iPad pro iOS 16) and (designed for Macbook iPad) and getting the same error logs.
2- I tried on a simulator (iPad, iPhone...) and the same output is given.
3- Sometimes the logs give an extra output for the storekit file saying that Failed to fetch storekit file but I was not able to get that extra line in further testings and forgot to record it.
4- On android, everything is functional if that helps.
5- The app is published for external testers and IAP is not working too, the server recorded similar outputs.
All tests are within sandbox environment and sandbox registered apple ids and using iOS 16.
Note: using qonversion_flutter version 5.0.1.
2023-01-15 20:02:48.533788+0200 Runner[27043:144514] ❎ Try to fetch user receipt...
2023-01-15 20:02:51.970205+0200 Runner[27043:144514] <SKReceiptRefreshRequest: 0x600000287040>: Finished refreshing receipt with error: Error Domain=ASDErrorDomain Code=500 "Failed to write receipt to URL: file:///Users/user/Library/Containers/com.app.name/Data/StoreKit/sandboxReceipt" UserInfo={NSDebugDescription=Failed to write receipt to URL: file:///Users/user/Library/Containers/com.app.name/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x600000dab240 {Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “StoreKit” in the folder “Data”." UserInfo={NSFilePath=/Users/user/Library/Containers/com.app.name/Data/StoreKit, NSUnderlyingError=0x600000dab810 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}, AMSServerErrorCode=0}
2023-01-15 20:02:51.970678+0200 Runner[27043:144514] ⚠ Receipt not found
2023-01-15 20:02:54.170340+0200 Runner[27043:198157] [connection] nw_resolver_start_query_timer_block_invoke [C103.1] Query fired: did not receive all answers in time for api.qonversion.io:443

Hello, Hassico! Thanks for contacting us.
Could you please provide us with the steps to reproduce your issue, as I wasn't able to reproduce it myself?
Also, kindly note, that you will not be able to test purchases on an iOS simulator, only on a real device.


[build] Add cmake option to enable/disable Java components build

Currently, if JNI is detected, the build always attempts to compile the Java runtime and tests. This patch adds a cmake option ONNX_MLIR_ENABLE_JAVA to enable (by default) or disable the Java components build.

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@jenkins-droid test this please

(merged with the latest to start the CIs).
@gongsu832 do you mind looking into this feature, and see if it interact with how our CI works when testing for java, Thanks

Can one of the admins verify this patch?

@gongsu832 I assumed that you approved the PR? You left your LGTM as a comment and not approval.

Jenkins Linux s390x Build #13425 [push] [build] Add cmake option... started at 08:36

Jenkins Linux amd64 Build #13399 [push] [build] Add cmake option... started at 07:36

Jenkins Linux ppc64le Build #12419 [push] [build] Add cmake option... started at 08:45

Jenkins Linux amd64 Build #13399 [push] [build] Add cmake option... failed after 1 hr 15 min

Jenkins Linux s390x Build #13425 [push] [build] Add cmake option... passed after 1 hr 26 min

Jenkins Linux ppc64le Build #12419 [push] [build] Add cmake option... passed after 1 hr 46 min