1.0: QUESTION:

From the documentation it is not clear which version of k8s will be used. Looking at the providers folder, it appears that the k8s version for AWS, GCE, and DigitalOcean is coming from some config variable which itself is nowhere documented and unknown where it would come from. For OpenStack, the corresponding YML files seem to have version 1.2.0 hardcoded which is really old and outdated.
It would be great to have some documentation how the k8s version is being determined and which k8s version are even supported.

The version is set by an option in the tube config. https://github.com/supergiant/supergiant/blob/master/pkg/model/kube.go#L74
A known working version is set for each provider. You can play with adjusting this. I would like to develop a slightly more elegant way of pairing cube version configuration with their build artifacts: https://github.com/supergiant/supergiant/tree/master/config/providers

Hi Mike - thanks for the time to answer this. However, I don't think you got my question, or I was simply not clear enough - my apologies for that.
So, let me try to re-phrase more specifically.
I am aware of the configuration setting in https://github.com/supergiant/supergiant/blob/master/pkg/model/kube.go#L74 since I found that. It looks like the "default" setting is k8s version 1.5.1.
I also found the yml files for the different provider. That's when this question actually was formed. For example, in the OpenStack provider (https://github.com/supergiant/supergiant/blob/master/config/providers/openstack/master.yaml) the k8s version is hard-coded to "K8S_VERSION=v1.2.0" which, as I mentioned, is quite old. Unfortunately, there is no mention anywhere why this specific version is hardcoded there and if it s possible to upgrade to version 1.5.1 for the OpenStack provider.
Also, as an example, in the GCE provider, the K8S_VERSION seems to be set via variable substitution with "K8S_VERSION=v{{ .GCEConfig.KubernetesVersion }}". Unfortunately, there is no mention of where this ".GCEConfig.KubernetesVersion" comes from. Maybe this is some standard golang feature but I am not that much familiar with golang (my apologies) since I am just starting to get into it.
I think, it would be great if such "trivial" things could be documented somewhere without people, such as me, having to dig through source code and possibly having to learn some specific features of a programming language, such as go.
And finally, since there is such a strong coupling between supergiant and k8s, IMHO, I believe it is an absolute must to document the k8s versions supergiant will be using and/or work on, don't you think so too.

The reason that this version is hardcoded, is that the OpenStack provider has not been updated yet to accept the template option that the other providers use. Our development bandwidth is limited, so we have been focusing on requests first. I will treat this issue as a request and push this up my priority list.  I agree on the documentation. Unfortunately it just comes down to time. We hope to be able to remedy this in the next few weeks as we have more time to focus on it. Right now we only have 3-4 contributors, so the more contributors we can get will speed things up.

For anyone reading this. Any suggestions, even how to better organize/produce documentation for our project as we code is greatly appreciated.

Thanks for this further update and your candor - much appreciated.

Closing due to age


oc-id login screens look weird in Chef Server 12.1.0-rc.1

The oc-id login screen appears different in 12.1.0-rc.1 and has a broken image at the top,  this may confuse or scare our users

ping: @chef/chef-visual-interaction

The changes to the look are by design and are part of overall efforts to improve the look and feel of all Chef applications. They are not going away and will continue to change and improve.
For that broken image, do you see any 404 messages in your browser console? It looks like it's failing to load the logo image. Please open a separate issue for that (though I believe it's probably fixed in #319.)

@smith I'm reopening this issue per our discussion.   To close this issue I'd have the following criteria:

#319 gets merged and validated in an omnibus build
Release notes and Changelog get updated with a very prominent note about the visual change to the login screen

I think that at the very least the broken images should be a 12.1 blocker.  The release notes are easy to update and I agree we should make note to any visual changes to the login screen.

Do we consider this addressed? For @irvingpop's #1 concern, #319 was merged, and I believe #344 addressed @irvingpop's  #2 concern. I would close this, but having been out, I'm unsure if we consider this addressed.

hey @mmzyk thanks for the update.  do you know if rc3 would reflect the changes?   If so, I can take it for a spin and validate.

@irvingpop Yes, if this was fixed RC3 would reflect the changes.

I loaded RC3 and brought up the oc-id signin page and it looks fine, so I'm closing this out. @irvingpop feel free to double check behind me.

Hey @mmzyk confirming this resolved. One thing I did find: on the oc-id signin page, the "SIGN UP" link takes you to https://manage.chef.io/signup rather than the local server.

@irvingpop Yeah, that's a regression from being too over eager in applying chef-web-core conventions. I've created https://github.com/chef/chef-server/issues/363 as an issue to get this fixed.


Twilight support

First of all, thank you for this wonderful theme.
Just wanted to check if Twilight support would be possible for this. At the moment, the dimmed space is just black. I'll post pictures of current vs expected to show you what I mean.
Thanks once again!

This what you can do for now.
solarized.setup {
  transparent = true,
  theme = 'vscode',
  mode = 'dark',
  highlights = function(colors)
    return {
      Twilight = { fg = colors.secondary, bg = 'NONE' }
    }
  end,
}

Sorry, i didnt see the issue until now, update the colorscheme and see if is everything is working.

Works great now! Thank you so much and have a nice day.


[Python] Daily work (BigCat)

The issue is to track daily work item that needs track:
https://github.com/msyyc/file-storage/blob/release-issue-status/published_issues_python.csv
https://github.com/msyyc/file-storage/blob/release-issue-status/release_python_status.md

count test coverage and multiapi/singleapi : https://github.com/Azure/azure-sdk-for-python/pull/22260


Update versions for Vagrant and VirtualBox.

Update version of Vagrant from 1.8.6 to 2.0.2.
Update version of VirtualBox from 5.1.8 to 5.2.6

Merged, after a small update to the commit message and removing one of the hand-warnings against using version 1.8.7 (that was only really necessary when that was the latest version).
Thanks for the prompt fix @amanagr!


[BUG] Save to directory does not work on android 13

Describe the bug
When download handling is set to "Save to directory" on an Android 13 device and you try to choose a download path, you are redirected to the permissions pages of Fritter.
I am pretty sure what it is looking for is "Scoped Storage". If the handling is set to "Always ask", downloading a file will trigger for a file browser to open, which allows saving of files.
When viewing the permissions page of fritter, no scoped storage is available.
To Reproduce
Steps to reproduce the behavior:

Have Fritter installed on Android 13
Got to Settings/General
Set Download handling to "Save to directory"
Click Choose under Download path

Screenshots

Device
Pixel 7, Android 13, Grapheneos (latest stable), english, 3.0.0-beta4

This should only happen when the "Storage" permission has been explicitly denied or removed. In your second screenshot, it doesn't look like that permission has been granted. Please can you try again, with the Storage permission explicitly granted?
I've seen this happen before in Android 12 (with other apps), where permissions seem to get revoked at random... I'm not sure what causes it.

Upgraded to v3.0.0-beta5, nothing has changed and the storage permissions do not show up. Can't modify permissions like the user above, due to missing root permissions.
So I guess orient yourself based on that ^ message. Since all I can say, is that the app "does not request storage permissions" be as it may.


[ MP Presentation ] Building Robust Applications with the MicroProfile APIs

I will be presenting "Building Robust Applications with the MicroProfile APIs: A Live Coding Event" at the TCF IT Professional Conference  (ITPC) as detailed below:

Friday, March 19, 2021
9:00am
via Zoom

Please visit my Portfolio page for details...
Please also note that the ITPC page will be updated for 2021, but I wanted to submit this in a timely manner.
Thanks!
Mike.

Hi @mpredli01
Thank you for the ticket. Can you please provide:

a tweet for this media push?
Name of speaker
twitter

When I have this I will push it out on twitter.
Thanks
Ryan

Hi Ryan:
Sorry it took me so long to reply.
Here's the proposed tweet for my upcoming MicroProfile talk.
.@mpredli https://twitter.com/mpredli will be presenting "Building Robust
Applications with the @MicroProfileIO https://twitter.com/microprofileio
APIs: A Live Coding Event" at the @TCFfestival
https://twitter.com/tcffestival IT Professional Conference, Friday, March
19 at 9:00am. http://princetonacm.acm.org/tcfpro/ #shareMPknowledge
I will put this in the marketing repo as well.
All the best,
Mike.
On Thu, Feb 25, 2021 at 11:26 AM Ryan St. James<EMAIL_ADDRESS>wrote:

Hi @mpredli01 https://github.com/mpredli01
Thank you for the ticket. Can you please provide:

a tweet for this media push?
Name of speaker
twitter

When I have this I will push it out on twitter.
Thanks
Ryan
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/microprofile-marketing/issues/402#issuecomment-786027789,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AA63D7CZ5E7GVBNO4L27BTTTAZ22BANCNFSM4YEQVSSQ
.

--
Code, Test, Write, Cycle, Run, Drink,
Sleep ... Repeat
Director, Garden State JUG https://javasig.org
Java Queue Editor, InfoQ https://www.infoq.com/
About Me http://about.me/mpredli/
@mpredli https://twitter.com/mpredli
redlich.net/
Laissez Les Bon Temps Rouler
he/him/his
https://medium.com/gender-inclusivit/why-i-put-pronouns-on-my-email-signature-and-linkedin-profile-and-you-should-too-d3dc942c8743

Hi Ryan:
Sorry it took me so long to reply.
Here's the proposed tweet for my upcoming MicroProfile talk.
.@mpredli will be presenting "Building Robust Applications with the @MicroProfileIO APIs: A Live Coding Event" at the @TCFfestival IT Professional Conference, Friday, March 19 at 9:00am. http://princetonacm.acm.org/tcfpro/ #shareMPknowledge
All the best,
Mike.

all set. it will go out the week before and the day before.


ZFSBootMenu on encrypted removable drive

I'm using ZFS on root with ext2 boot partition inside a LUKS volume on a USB drive (Arch Linux), but I would like to migrate to ZFSBootMenu. I'm wondering if it is possible to have GRUB opening the USB partition encrypted with LUKS where the initramfs with ZFSBootMenu is stored?
Is it possible to have ZFSBootMenu on an encrypted drive? I've never used rEFInd so I don't know if it can open encrypted drives like GRUB does or if ZFSBootMenu can work with GRUB.

I don't believe that GRUB plays nicely with ZFSBootMenu. Your best bet is to build a custom ZBM image that includes support for LUKS to unlock the volume that holds your pool. We've had reports of people successfully booting LUKS-encrypted ZFS pools with such configurations in the past.
Nothing about the ZFSBootMenu image needs to be encrypted, so you can put the images on an EFI System Partition, even on another disk if necessary. Our wiki includes directions for booting from an ESP on a USB thumb drive that you should be able to adapt to Arch.
Also, note that you can make the ZBM image a self-contained UEFI executable, which will allow you to skip a loader like rEFInd altogether. Just tell your firmware to boot the ZBM bundle and you're ready to go.

Ohh that's a shame because I would have to give the LUKS headers of my main disk to the initramfs and I prefer to have it behind a passphrase and it doesn't seem to be possible without GRUB support.

You don't have any unencrypted space on the disk? Usually it's a good idea to leave an EFI system partition on a volume and then put the LUKS volume on a partition that fills the rest of the disk.

You don't have any unencrypted space on the disk? Usually it's a good idea to leave an EFI system partition on a volume and then put the LUKS volume on a partition that fills the rest of the disk.

I don't have any unencrypted space on the disk I have my root pool. I encrypted the entire disk with LUKS. I have an unencrypted EFI partition on a USB drive together with an encrypted /boot partition. The only thing that is unencrypted is the EFI partition. The LUKS header that is necessary to open the main disk is located in the encrypted /boot.
I use GRUB to decrypt the encrypted boot partition that has the initramfs with the LUKS header and the initramfs decrypts the main disk and imports my ZFS pool.
To use ZBM I would have to leave the initramfs unencrypted and that means the header for the main disk would also be exposed.

You can use ZFSBootMenu without exposing secrets in your setup, but it will take a little bit of scripting. ZFSBootMenu supports early hooks that are run before attempting to import any pools. You can write a simple hook that knows how to unlock your /boot (which can't be used as /boot with ZFSBootMenu, but can be used to store the secrets you need to unlock the device holding your root pool) by prompting for a passphrase, then reading the contents of /boot to unlock the LUKS volume. Once your LUKS volume is unlocked by any means, the script can exit and ZFSBootMenu should be able to continue its normal process of importing the pool and booting from it.
We have a simple demo at https://github.com/zbm-dev/zfsbootmenu/blob/master/contrib/luks-unlock.sh which doesn't do quite what you want, but may give you some hints about how you would use an early hook to interact with your LUKS setup.

I see. I was wondering if I can make the grub efi executable load the ZBM initramfs and kernel? It could work like what I am doing now but instead of Grub loading the initramfs and kernel of my installation it would load ZMB's and I would just move my /boot to the default root dataset for ZBM to load it.  Does it work?


Design System - Cards - ds-card w/header and footer

id=phantom-ds-card-content-type-title-subtitle-image-text-links
Header padding - Update T, B, L, R Padding: 16px
ds-card-text - Update T, L, R Margins: 16px, Bottom Margin: 8px
Use "ds-btn ds-btn-link" instead of current "ds-card-link
ds-btn ds-btn-link - Update T, L, R Margins: 8px, Bottom Margin: 12px
*Remove "cap" from image
Thx,
Ismael

@jdrf-digitaldesigner I believe these have been resolved from previous tickets. Can you confirm?

Confirmed. Thx!


📃: add my mern project "Paisa-Pal" is expense tracking application

🔴 Title  :Paisa-Pal
🔴 Tech stack :  MERN stack (MongoDB, Express, ReactJS, and Node.js).
🔴 Objective : To provide users with an easy-to-use platform for tracking and managing their daily, weekly, or monthly expenses while offering insightful analysis to help them manage their finances more effectively.
🔴 Summary : Paisa-Pal is a comprehensive expense tracking application designed with the MERN stack. It enables users to seamlessly create, update, and delete expenses while providing visual insights into their spending patterns over time. With a user-friendly interface and analytical tools, it helps individuals gain better control of their finances.
📸 Screenshots:

✅ Details to Include When Taking the Issue:
Name : MD REHAN
Participant Role :- GSSOC, Hacktoberfest

Happy Contributing! 🚀
Wishing you all the best on your open source journey. Enjoy! 😎

Sorry, someone is already working on this. Do not be demotivated and raise a new issue.


🔮[New Component] LabelGroup

LabelGroup - Just like there is a ButtonGroup which sets the styles when Buttons should be rendered together, we should think about something similar for Labels.
In addition to the margin between the labels, this should also flex-wrap. Here is an example of the behavior today:

@dmarcey I've started building this out this morning, and I think in this case we should just wrap this line in a Flex component instead of putting the flex-wrap on the LabelGroup because in that case the user would have to put the rest of the line they want to wrap inside of LabelGroup which doesn't feel great! Let me know if that's what you were thinking in regards to wrapping

Yeah, I was thinking the same thing. I think that just having the margins should be good enough to start with at least. Thanks!


d_levenshtein fails with cyrillic words

Builded release v0.1.3
d_levenshtein fails with cyrillic words, while levenshtein works fine.
import polars as pl
from polars_ds import StrExt
word_pairs=pl.DataFrame(
    {
        "char1":['Иванко'],
        "char2":['Петрунко']
    }
)
word_pairs=word_pairs.with_columns(pl.col("char1").str_ext.d_levenshtein(pl.col("char2"),parallel=True).alias("distance_ds"))
print(word_pairs)

Here is error:
thread '<unnamed>' panicked at /home/symbioz/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rapidfuzz-0.3.0/src/details/growing_hashmap.rs:118:19:
index out of bounds: the len is 8 but the index is 61
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The plugin panicked which is unrecoverable. Polars will abort
Aborted

This was fixed in RapidFuzz
https://github.com/maxbachmann/rapidfuzz-rs/issues/4
Localy rebuilded with rapidfuzz 0.3.2 and it works fine now.

This was fixed in RapidFuzz
https://github.com/maxbachmann/rapidfuzz-rs/issues/4
Localy rebuilded with rapidfuzz 0.3.2 and it works fine now.

Thank you. I am on vacation rn and will update it once I come back

closed https://github.com/abstractqqq/polars_ds_extension/pull/25


disable-Welcome-page-e2e-test

Signed-off-by: Chunxi Luo<EMAIL_ADDRESS>https://github.com/open-cluster-management/backlog/issues/13723

This is weird, this failed test cases is passed last time, still looking at the root reasons, here just disabled all Welcome-page-e2e-test

I think this should be resolved by merging https://github.com/open-cluster-management/grc-chart/pull/45


Attempt to retrieve the API key from GCE metadata if not present or the default value in the config files was left unedited.

So if the value is left as "STACKDRIVER_API_KEY" (literal) it will look it up?
I think it would be better to have an explicit "try to detect" case like we do with the instance ids, that way we can hard-set them when debugging configs and then switch them over to detect.

Correct. The idea is that we can reuse the existing configs without creating a combinatorial explosion of boolean options.
We can still hard-set them when debugging configs -- any value but "STACKDRIVER_API_KEY" will be used verbatim.
Am I missing something?

I just don't think that value is very clear, and if a literal value is going to trigger a special case I'd rather have it look like it will "DETECT_FROM_METADATA" or some such.

Sure, I can change it to "DETECT_FROM_METADATA", but that would require the users to either edit the config anyway after downloading it (something I think we want to avoid) or pull from a different config directory (adding more sets of configs for us to maintain). Should I go with the latter option and add another set of directory trees to jmxtrans-config-stackdriver?

To avoid proliferation, let's just go with the default value.  It will be a user education thing I guess, which it was going to be anyway.

Thanks. So, is this ready to merge?

Yes, if it has been tested successfully in both states (special value and valid API key).

Just tested with and without the API key in the (Cassandra) config. The data was sent to GCM and displayed. I can haz LGTM?

On second thought, also changed it to get the key from metadata if it wasn't present in the config at all. PTAL.

LGTM.

Thanks, merged.


VSCode on Linux opens on wrong display(system)

VSCode Version:

1.41.0
9579eda04fdb3a9bba2750f15193e5fafe16b959
x64

OS Version:
Arch linux (updated sometime last week)

Steps to Reproduce:
1.Connect to a linux system, which supports forwarding X connections, and with a SSH client that can host forwarded X connections.  (I use Mobaterm, from a windows system... that is, the system connecting to the linux system should also be a separate system.)  Start Code in some directory.
2.Login as the same user directly on the computer.  I am using wayland with weston for the gui; and in a terminal, I can start code in some other directory, but it did not appear.  (It does, but on the wrong system, when I did it the first time I would say '... did not appear but, I later got back to the other system, and noticed two new VS code editors open.
So, not only open on the wrong display, but the display on the wrong physical computer.
Does this issue occur when all extensions are disabled?: Yes

@d3x0r does that happen with any other electron app?

/needsMoreInfo

@kieferrm  It is possible it's any electron app; I have Atom installed... but I won't be able to test for a few days (while I'm on the road).
to codebot; I left the template in, and attempted to complete as much of it as I could; I don't know which sentence of that reporting guideline I'm failing.

Sorry missed this, thanks @d3x0r for opening the electron issue, will continue the discussion there.

Closing as the issue hasn't seen movement in upstream for a while, you can use our remote development suite as a workaround.


MM-8701 Load client config after logging in

This is for an upcoming security improvement to only provide a limited version of the client config to non-logged-in users, so we need to be sure to pull down the complete client config after logging in.
Any thoughts on whether we need the version check here or not? It's not like it hurts to pull the client config twice on an older server.
Ticket Link
https://mattermost.atlassian.net/browse/MM-8701

Related to this: the server emits configuration change websocket events. Do we need to sanitize those as well?

No, we don't need to sanitize the websocket events since you only get those when you're logged in. I didn't think to check that earlier so good catch.

@grundleborg Changes have been made


Colour output

basically pr #17 and #18 combined

Do the Travis CI tests test build output and fail because it's different from before or have I broken something?

Do the Travis CI tests test build output and fail because it's different from before or have I broken something?

You can check the travis log behind the details link. I presume it's visible for you too (should be). From the travis log, we can see that you have not included colorama in the requirements.txt.

ModuleNotFoundError: No module named 'colorama'

Manually merged in ff2f06f7d786b1a7df066bf87ad2cc4e48713d6d


Added prebuild-check make target

This change introduces a check target called prebuild-check which checks for required tools (git, hg, go, and glide) and also if the project is living inside the correct path which is $GOPATH/src/$PACKAGE_NAME.

This change is

Makefile, line 61 [r1] (raw file):

.PHONY: clean-generated
clean-generated: prebuild-check

Do I really need Go to clean?

Comments from Reviewable

Makefile, line 122 [r1] (raw file):

endif
# Check that the code is located in $GOPATH/src/github.com/almighty/almighty-core
ifneq ($(GOPATH)/src/$(PACKAGE_NAME),$(shell pwd))

This assumes GOPATH is only a single location. It can be a List
``make prebuild-check
Makefile:123: *** The code and this Makefile must live here "/home/aslak/.gvm/pkgsets/go1.6.2/almighty:/home/aslak/.gvm/pkgsets/go1.6.2/global/src/github.com/almighty/almighty-core" and not here "/home/aslak/.gvm/pkgsets/go1.6.2/almighty/src/github.com/almighty/almighty-core".  Stop.
`

---

*Comments from [Reviewable](https://reviewable.io:443/reviews/almighty/almighty-core/57)*
<!-- Sent from Reviewable.io -->

Review status: 0 of 3 files reviewed at latest revision, 2 unresolved discussions.

Makefile, line 61 [r1] (raw file):
Previously, aslakknutsen (Aslak Knutsen) wrote…
> Do I really need Go to clean?

The check doesn't do any harm and should be modified so that it can run efficiently without disturbing anything. And yes, you need go to run clean. Because otherwise you would have nothing to clean.
To keep things simple I'd have prebuild-check be executed all the time without any exception.

Comments from Reviewable

Review status: 0 of 3 files reviewed at latest revision, 2 unresolved discussions.

Makefile, line 122 [r1] (raw file):
Previously, aslakknutsen (Aslak Knutsen) wrote…
> This assumes GOPATH is only a single location. It can be a List
>
> ``make prebuild-check
> Makefile:123: *** The code and this Makefile must live here "/home/aslak/.gvm/pkgsets/go1.6.2/almighty:/home/aslak/.gvm/pkgsets/go1.6.2/global/src/github.com/almighty/almighty-core" and not here "/home/aslak/.gvm/pkgsets/go1.6.2/almighty/src/github.com/almighty/almighty-core".  Stop.
> `
>
> ```

You're right. I'll fix that.

Comments from Reviewable

Review status: 0 of 3 files reviewed at latest revision, 2 unresolved discussions.

a discussion (no related file):
Windows complains:
Makefile:123: *** The code and this Makefile must live here "C:\Users\thomas\code\ALM/src/github.com/almighty/almighty-core" and not here "/cygdrive/c/Users/thomas/code/ALM/src/github.com/almighty/almighty-core".  Stop.

Comments from Reviewable

Review status: 0 of 3 files reviewed at latest revision, 2 unresolved discussions.

a discussion (no related file):
Previously, tsmaeder (Thomas Mäder) wrote…
> Windows complains:
>
> Makefile:123: *** The code and this Makefile must live here "C:\Users\thomas\code\ALM/src/github.com/almighty/almighty-core" and not here "/cygdrive/c/Users/thomas/code/ALM/src/github.com/almighty/almighty-core".  Stop.
>

I'm sick of windows.

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 2 unresolved discussions.

a discussion (no related file):
Previously, kwk (Konrad Kleine) wrote…
> I'm sick of windows.

@tsmaeder: Fixed in 4ca8a5b3811c44cc59052ee070d12cef3d478690

Makefile, line 122 [r1] (raw file):
Previously, kwk (Konrad Kleine) wrote…
> You're right. I'll fix that.

Fixed in 4ca8a5b3811c44cc59052ee070d12cef3d478690

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 3 unresolved discussions.

Makefile, line 125 [r3] (raw file):

endif
	# Check that the code is located in $GOPATH/src/github.com/almighty/almighty-core
	go build .make/check-gopath.go

If we write tools in go, wouldn't it make sense to put them in an installable package?

Comments from Reviewable

Review status: 0 of 5 files reviewed at latest revision, 3 unresolved discussions.

Makefile, line 125 [r3] (raw file):
Previously, tsmaeder (Thomas Mäder) wrote…
> If we write tools in go, wouldn't it make sense to put them in an installable package?

In principle yes, but the check_gopath tool is just for building the install-able product.  So I'm not sure.

Comments from Reviewable


Enable opening links in browser instead of internal browser

Is your feature request related to a problem? Please describe.
Now when I click links in Google Keep they always open in an internal browser which is useless since I don't have access to saved accounts and other features I use within my regular browser. Instead I'm forced to copy the link URL and paste it in the browser.
Describe the solution you'd like
Either an easy to find setting or open in browser by default
Additional context
I'm sure I've just missed a setting somewhere, but I wasn't able to find it in the settings window so either I'm just blind or it's not discoverable enough.

Quote:
mundo03 commented on Apr 28, 2020
workaround: Control + click (or whatever equivalent is on osX) will open the link in a browser with no issues.
https://github.com/getferdi/ferdi/issues/321


cuckoo_miner not compiling on Raspberry Pi 3 Jessie/GCC 6.3

Fur tracking purposes.
On a standard Raspberry Pi 3 (arch: armv7) where I "up-fitted" Jessie with GCC 6.3.0 (I can't use Stretch because of its wifi issues). Probable cause: hard-coded x86 compiler flags (-m64 -mavx2) in some build scripts.
Full build log here:
https://gist.github.com/oriste/6890a1d1b820704c036fb6d33d7a7c3e

Seeing this too
running: "cmake" "/home/pi/.cargo/git/checkouts/cuckoo-miner-4752934f0f1f2bfe/d017db6/src/cuckoo_sys/plugins" "-DBUILD_CUDA_PLUGINS=FALSE" "-DCMAKE_INSTALL_PREFIX=/home/pi/grin/target/release/build/cuckoo_miner-bba6cbfbce89fa3d/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC -march=armv7-a" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC -march=armv7-a" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_BUILD_TYPE=Release"
-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/pi/grin/target/release/build/cuckoo_miner-bba6cbfbce89fa3d/out/build
running: "cmake" "--build" "." "--target" "" "--config" "Release" "--"
Scanning dependencies of target mean_compat_cpu_16
[  5%] Building CXX object CMakeFiles/mean_compat_cpu_16.dir/cuckoo/src/mean_miner.cpp.o
CMakeFiles/mean_compat_cpu_16.dir/build.make:62: recipe for target 'CMakeFiles/mean_compat_cpu_16.dir/cuckoo/src/mean_miner.cpp.o' failed
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/mean_compat_cpu_16.dir/all' failed
Makefile:83: recipe for target 'all' failed

--- stderr
c++: error: unrecognized command line option ‘-m64’
make[2]: *** [CMakeFiles/mean_compat_cpu_16.dir/cuckoo/src/mean_miner.cpp.o] Error 1
make[1]: *** [CMakeFiles/mean_compat_cpu_16.dir/all] Error 2
make: *** [all] Error 2
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2

@yeastplume @tromp

Seems -m64 is not needed. Will take it out of my Makefile. Once Yeastplume updates this should no longer be a problem...


Updated gif to reflect new changes

Changed the gif for the new layout.
I hope the width and height are alright :)
fixes: #144

Hi @IncredibleZuess, thanks for the PR!
Btw, the image is too small compared with the previous one.
This PR will be closed in favor of #145  (Respecting creation time and issue owner)
I hope you will contribute on any of the issues we still have open.

@GuillemPM Ah yeah, I thought so.
No worries :)
I am definitely going help out here
Really cool project!!!


Add GIMP rules for floating windows

There were no rules in applications.json for the gimp-[version number].exe executable for some basic floating windows such as:
New File

Preferences

Input Devices

and many more...
Basically every window which title doesn't:

Contains "GNU" (main page when the program's opened)
Ends with "GIMP" (a file or project opened -since it follows the "Descriptive Title Format convention"- and main page in some languages)

So I added this to my applications.json:
  "GIMP" : {
    "floating" : [
      [
        {
          "kind": "Exe",
          "id": "gimp",
          "matching_strategy": "StartsWith"
        },
        {
          "kind": "Title",
          "id": "GNU",
          "matching_strategy": "DoesNotContain"
        },
        {
          "kind": "Title",
          "id": "GIMP",
          "matching_strategy": "DoesNotEndWith"

        }
      ]
    ]
  },

(I could rely only in the Title because Class names were all the same: gdkWindowToplevel 🫠)
So, the floating windows now behave properly:
New File

Preferences

Input Devices

This is really cool! Thanks for doing the investigation 🙏
Feel free to open a PR for this now

Neat 😃. Done #133


GameData Changes

Description
Added Loader back to GameData page along with styling changes to lineup Typography. Adjusted reducers to reset loading state to false on some pages.
Fixes # (issue)
Type of change
Please delete options that are not relevant.

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Change Status

[ ] Complete, tested, ready to review and merge
[ ] Complete, but not tested (may need new tests)
[ ] Incomplete/work-in-progress, PR is for discussion/feedback

How Has This Been Tested?

[ ] Test A
[ ] Test B

Checklist

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] My code has been reviewed by at least one peer
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes
[ ] There are no merge conflicts

We got a loading bar


Does it work in not so deep architectures?

Thanks for your greate job.Do you have any experiment of ReZero applied in different layers of transformers, like 1 layer Transformer layer and it performance , 2 layer Transformer layers and it performance, and so on.Does it make convergence faster in not so deep net?Thank you.

In our paper, we experimented with Transformers with 12 layers and found speed increase. We have not tried shallower models, but we hypothesize it should also bring speed improvements.

Thanks you.I'll try  in my project later which is not so deep.

Any update @wotulong on shallower models?


introduces compactMode which minimises the table's width by abbreviating

Working on a 12" MacBook here so every pixel counts! Especially when holding the same currency across three or four exchanges...

Added a milestone here: https://github.com/benmarten/CryptoETF/projects/1#card-7180659


DB not showing despite Show all databases enabled.

Am I doing something wrong or is this a problem with DBeaver? Dunno how to read the contents of my new db.
(I created the DB before opening the connection so it's not an old cache problem I reckon.)

Hello @dredshep,
Can you check Query Manager and show the queries in it? Make sure the queries are fully visible (there should not be any sensitive data).
Do avoid including unrelated queries, simply clear everything, then connect to your DB and expand very top folder to see all the databases.

there is no update on an issue for a long time.
If it is still actual - feel free to reopen it with additional info to reproduce the issue.


ISPN-2886 CDI creates CacheManagers with custom names

Added Cache Manager name to global configuration in CDI Extension. This prevents throwing JmxDomainConflictException when deploying on Wildfly using Library mode.
Ticker URL: https://issues.jboss.org/browse/ISPN-2886
Additional changes:

Upgraded Shrinkwrap resolvers to more recent version
Cleaned up code throwing JmxDomainConflictException
Added additional parameter to the JmxDomainConflictException message

I get these failures
Tests in error:
GreetingServiceIT.testGreetMethod » Runtime Could not inject members
GreetingServiceIT.testGreetMethodCache » Runtime Could not inject members

Yes, I overlooked those tests. I'll add necessary changes. Thanks for checking it.

Additionally removed test-unstable profile (unused)

Integrated, thanks @slaskawi


Speedups and enhancements for GitHub Actions CI workflows

This PR addresses a few issues currently affecting continuous integration workflows for this repo:

step-security/harden-runner actions taking too long. Fixed by upgrading all usages of this action to the latest version.
(Side note: it's worth mentioning that the gains from "Prepare for QA" would be more substantive if we enabled Dependabot, since
"Prepare for QA" step doesn't provide an effective Node cache. This was happening because although actions/setup-node persists the Yarn cache between steps, it does not include node_modules – presumably because reusing node_modules across different versions of Node can cause problems. A separate usage of actions/cache has been added to implement the following caching behaviors:

The cache key is created by hashing the contents of yarn.lock.
When "Prepare for QA" starts, it attempts to restore a node_modules cache created from the current state of yarn.lock. If this results in a cache miss, then a new cache is created after installing dependencies. When a cache hit is possible, yarn install only takes about 10 seconds to complete. This behavior ensures that a node_modules cache always exists after "Prepare for QA" completes.

Important note: We should bear in mind that this could cause problems if yarn install creates a corrupt node_modules for some reason, which would normally be fixed on a subsequent run of yarn install. While this shouldn't happen, it might(?). In these cases, the cache would need to be manually deleted from GitHub. A safer alternative would be to never restore cache in "Prepare for QA" and instead always build a fresh one, although this would slow things down (similar to the status quo).

Each dependency of "Prepare for QA" restores the node_modules cache and does not run yarn install.
Altogether, these changes shave about 2 minutes of runtime from the Continuous Integration workflow. Given the consideration I noted above regarding cache spoilage, it might be justifiable to re-add a yarn install step to these dependent jobs, which would run after cache restoration. In most cases, it would merely add ~10 seconds to each job (basically how much time it takes for Yarn to decide not to do anything), but the benefit would be that it would give Yarn a chance to fix things in case the node_modules cache was spoiled.

@as1729 curious for your thoughts here.

Test coverage reports get cut off in PR comments.

"Terraform Summary" and "QA Summary" PR comments now provide a direct link to the workflow at the top, since they currently disappear when a comment is truncated due to length.
Each test suite's coverage report is posted to a different step summary, in addition to the "QA Summary" comments left on PRs. This ensures that all 3 coverage reports can still be viewed, even if the "QA Summary" comment is truncated.
*.sdl.ts files are excluded from Jest coverage collection, since they are not tested and otherwise taking up space in the coverage reports.

Altogether, these changes reduce Continuous Integration workflow execution by about 8-10 minutes (and up to 12 minutes, according to some hasty napkin math). Most of this is due to upgrading the step-security/harden-runner action, which is a good argument for enabling automatic dependency upgrades for this repo 🤓
PS - You won't see any of these gains on this PR, because we only run GitHub actions using the base branch configuration. For a preview of the effective changes, see #475.

@as1729 I noticed a few times in #475 that the API-side test suite was a little flaky – here's one example. Is this a known issue, or should I look into whether that's unique to the changes introduced by this branch?

Is this a known issue, or should I look into whether that's unique to the changes introduced by this branch?
This is a known issue captured in #476 and @greg-adams is working to resolve it.

Given the consideration I noted above regarding cache spoilage, it might be justifiable to re-add a yarn install step to these dependent jobs, which would run after cache restoration. In most cases, it would merely add ~10 seconds to each job (basically how much time it takes for Yarn to decide not to do anything), but the benefit would be that it would give Yarn a chance to fix things in case the node_modules cache was spoiled.

If its a 10second time-add and gives us higher confidence that we won't be dealing with corrupt packages it seems reasonable .However, I'm not able to think of any reasons why these packages might get corrupted from one step to the next. If you think there are several ways this could happen that is out of our control, I'm good with adding a redundancy here.

which is a good argument for enabling automatic dependency upgrades for this repo 🤓

💯  agreed. I thought @dependabot was already in this repository? example:  #439

Given the consideration I noted above regarding cache spoilage, it might be justifiable to re-add a yarn install step to these dependent jobs, which would run after cache restoration. In most cases, it would merely add ~10 seconds to each job (basically how much time it takes for Yarn to decide not to do anything), but the benefit would be that it would give Yarn a chance to fix things in case the node_modules cache was spoiled.

If its a 10second time-add and gives us higher confidence that we won't be dealing with corrupt packages it seems reasonable .However, I'm not able to think of any reasons why these packages might get corrupted from one step to the next. If you think there are several ways this could happen that is out of our control, I'm good with adding a redundancy here.

My thinking is that if a package is broken on NPM and then updated without a version bump (rare, but it happens), our cache would be stuck on the broken package. Maybe network availability is another risk, although I'm not sure if Yarn would complete successfully if that were the case.
Maybe we leave as-is for now and keep this as a back-pocket strategy if we lose confidence in passing around node_modules.

which is a good argument for enabling automatic dependency upgrades for this repo 🤓

💯 agreed. I thought @dependabot was already in this repository? example: #439

We have Dependabot enabled for security updates (when a known vulnerability has a compatible patch) but not for general dependency updates.


Update CONTRIBUTORS

Perhaps this is helpful... if not throw it way ;-)
I've searched for all resolved/closed Jira tickets where "Fix Version = 4.15.0". Then I extract all volunteers that are currently not listed and add it to the "Apache Flex SDK 4.15.0." section.
List of currently not listed volunteers with issue id, ordered by issue id (descend):
[x], Olaf Krüger, FLEX-35003
[x], Konstantin Elstner, FLEX-34954
[x], Benjamin Chalupka, FLEX-34891
[-], goratz, FLEX-34769
[x], Aleksey, FLEX-34753
[x], Alexander Doroshko, FLEX-34751
[x], Alessandro Palombaro, FLEX-34744
[x], Devin, FLEX-34741
[-], Tamás Nepusz, FLEX-34727
[-], Carlos Monteiro, FLEX-34581
[x], Steve Wright, FLEX-34028
[-], Paul Hastings, FLEX-33908
[x], Curtis Aube, FLEX-33537
[x]: Listed in RELEASE_NOTES
[-]: NOT listed in RELEASE_NOTES

Thanks for that but looks like it may need some modification. Generally people are only to contributors if code they supplied goes into a release and not just raised a bug.

Ok, don't know this but it makes sense ;-)
Sorry for wasted time!
Olaf

Thanks for double checking - we do sometimes miss people out.


BP-2478 Conflict with Amasty Order Atttributes extension

Amasty Order Atttributes extension add custom checkout fields. When I select Buckaroo (iDeal) as payment methods all those checkout fields coming from Amasty extension are visible in the checkout but not saved to the quote. Probably they are overwritten when placing the order. When other default payment method is selected this isn`t a case

@bojandavkov Thanks for your issue. Could you please send me an e-mail with the issue your facing, please attach a video. We officially do not support Amasty yet, nevertheless i know the integration your working on and we have resources available to help you out a.s.a.p.
<EMAIL_ADDRESS>

@bojandavkov We fixed the issue and it's currently in testing fase. You can check the commits here: https://github.com/buckaroo-it/Magento2/pull/717/commits if you want to test yourself.

Released in v1.46.0


Documentation. Wrong link to bind-address configuration setting in influxdb 1.5

Link to bind-address configuration setting in Influxdb 1.5 documentation leads to Influxdb 1.4
URL for relevant page?
https://docs.influxdata.com/influxdb/v1.5/administration/backup_and_restore/
This is how it works now:
At the root level of the InfluxDB config file (`influxdb.conf`), uncomment the `bind-address` [configuration setting](https://docs.influxdata.com/influxdb/v1.4/administration/config/#bind-address-127-0-0-1-8088) on the remote node.

This is how it should be:
At the root level of the InfluxDB config file (`influxdb.conf`), uncomment the `bind-address` [configuration setting](https://docs.influxdata.com/influxdb/v1.5/administration/config/#bind-address-127-0-0-1-8088) on the remote node.

Thanks for the heads-up @juris, this link has been fixed and will be deployed soon.


[Bug]: math-shepherd-mistral-7b-prm does not support the 'embedding' task. Supported tasks: {'generate'}

Your current environment
I thought math-shepherd-mistral-7b-prm has already supported 'embedding' task according to this PR
Model Input Dumps
No response
🐛 Describe the bug
Any way to use math-shepherd-mistral-7b-prm in embedding mode?
Before submitting a new issue...

[X] Make sure you already searched for relevant issues, and asked the chatbot living at the bottom right corner of the documentation page, which can answer lots of frequently asked questions.

Which version of vLLM are you using? This is not in the latest release, so you have to use vLLM from main branch.


intern: set finalizer before storing uintptr in valMap

Signed-off-by: Matt Layher<EMAIL_ADDRESS>Updates #13.

@bradfitz done, PTAL and merge when ready.

@bradfitz done, PTAL and merge when ready.


fix builtins plugins from leaking vars

fix #461

The implementation decides where to insert the created identifier based on the input code.

Even after fixing this, the mangler doesn't rename the identifier properly. Related - https://github.com/babel/babili/issues/425

If I'm reading the tests correctly this still leaks some vars. Unless it can detect it's in module mode it would be better not to try to convert top level builtins.

[Update]
Running mangler on exit fixes the #425 issue.

Works now for functions at same level.


run model.train() on models before training

see https://pytorch.org/docs/stable/generated/torch.nn.Module.html#torch.nn.Module.train

Do we need this? I never see HF docs asking us to manually set this? I think the Trainer would automatically do this.


why this speed difference ?

https://github.com/image-js/core/blob/e6cb9aa14c584edd03dade57eade96a42768a5cb/benchmark/grey.js#L15-L20
The 'red' is 6 times slower than 'grey' while it is indeed different approaches but the 'red' algorithm seems easier to calculate. @targos Any idea why this difference in speed ?

because you put the algorithm 'lightness' instead of 'red' ?

Yes seems the main reason indeed :(


PBH 4337 Module

Use the latest release of safe-modules as older version use v6 of account-abstraction.
remove --via-ir in foundry.toml as it causes stack too deep in safe modules
support signature verification in both off-chain simulation and on-chain execution

TODO: Fork safe-modules inside worldcoin GH and add virtual modifier to _validateSignatures
original impl of _validateSignatures - https://github.com/safe-global/safe-modules/blob/main/modules/4337/contracts/Safe4337Module.sol#L275-L299

Note: I need to disable --via-ir else i get stack trace too deep. Removing this from foundry causes the PBHVerifier tests to fail. Any suggestions?


pip install - ERROR: Failed building wheel for numpy

Hello, i'm on page 5 and attempted to install the requirements.txt but I am receiving an unusual error. (See error.txt below).
error.txt
I can install the numpy version 1.24.2 but the requirements.txt calls for 1.20.1. I played around with this a bit and can't install 1.20.1 and I altered the requirements.txt file to have version 1.24.2 with no luck. I also removed/commented the line out but it still errors out.
FWIW I'm running on an Apple M1 MacBook. I don't know if there's some sort of incompatibility issue here.
python = 3.9.6
pip = 23.0.1
wheel = 0.38.4

@BenZhen14 Thanks a lot for reporting.
I'm not sure why this is happening. I just tested on a Mac, with Python v3.9.2, and installed the packages with no problem.
Can you please check your virtual environment? Or maybe start a new one from scratch?

@eliasdabbas Out of curiosity, are you using an Intel or ARM based Mac? I only ask because I have two Apple Silicon Macs and it failed on both.
I started from scratch on both Macs but unfortuantely, I ran into the same issue.

I'm using an Intel-based Mac. I doubt this would be the reason, but I don't really know.
Can you please share the exact steps you took (including the virtual environment), so I can double check?

This is indeed really strange...
Thanks again for letting me know, and I'll check to see what might be the solution for this.
Hope you enjoy the book!


[Documentation] How to access CMS databases outside of CERN

Brief summary of issue

Instructions to access the CMS databases outside of CERN have  been written to the GEM DAQ Expert TWiki page. Since the guide is the GEM software reference, a link should point to the TWiki section.
Types of issue

[ ] Bug report (report an issue with the code)
[x] Feature request (request for change which adds functionality)

Expected Behavior
A link should point to the TWiki page. But where? This is sysadmin job and there is no section dedicated how to setup a DAQ machine.
Context (for feature requests)

Using the upstream GEM software requires access to the CMS database. Since the databases are not accessible from outside the CERN GPN, a tunnel must be setup.
Your Environment

Version used: https://github.com/cms-gem-daq-project/sw_utils/commit/08ecb25104661cb3473e1dddea2d2da4a9ca9bb0

Documented in the CMS GEM DAQ website.


Can't run tests due to uncaught error

I haven't made any changes to my projects except running yarn install, but now I can't run any tests using Cucumber, while normal Cypress tests run fine.
I tested creating the Google example files and get the same error.
An uncaught error was detected outside of a test:
Uncaught TypeError: Cannot read property 'native' of undefined.
Here's the full error log;
` Running:  Google.feature                                                                  (1 of 1)

An uncaught error was detected outside of a test

0 passing (193ms)
1 failing

An uncaught error was detected outside of a test:
Uncaught TypeError: Cannot read property 'native' of undefined

This error originated from your test code, not from Cypress.
When Cypress detects uncaught errors originating from your test code it will automatically fail the current test.
Cypress could not associate this error to any specific test.
We dynamically generated a new test to display this failure.
at Object. (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:59549:35)
at Object.361../caller.js (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:59835:4)
at o (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:265)
at http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:316
at Object.360../lib/async (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:59533:13)
at o (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:265)
at http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:316
at Object. (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:16149:16)
at Object.178.bluebird (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:16155:4)
at o (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:265)
at http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:316
at Object.177.../formatter/builder (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:15896:26)
at o (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:265)
at http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:316
at Object.206../cli (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:18507:12)
at o (http://localhost:35739/__cypress/tests?p=cypress/integration/Google.feature-026:1:265)
`

Would you be able to create a simple reproduction in a fresh repository? Also, what version of our plugin do you have installed?

I made this:

It installed the latest version 2.3.0. If run as is, the tests fail. I included another lock file, working_yarn.lock from an earlier project. If it's used with yarn --pure-lock I got it to work. It's also 2.3.0 so perhaps the issue is one of the dependencies.

Thanks a lot! this will be very helpful. I should be able to disect this today:)

Thanks !
Same issue on our project. Everything was working fine several hours ago.

well, that just became even higher priority.. ;)

On our project :
cypress-cucumber-preprocessor :
package.json : "^1.19.0"
package-lock.json : "1.19.2"

can confirm this is blocking everything. I am using Cypress 4.2.0, with this webpack config:
module.exports = {
  resolve: {
    extensions: [".ts", ".js"],
  },
  node: { fs: "empty", child_process: "empty", readline: "empty" },
  module: {
    rules: [
      {
        test: /\.ts$/,
        exclude: [/node_modules/],
        use: [
          {
            loader: "ts-loader",
          },
        ],
      },
      {
        test: /\.feature$/,
        use: [
          {
            loader: "cypress-cucumber-preprocessor/loader",
          },
        ],
      },
      {
        test: /\.features$/,
        use: [
          {
            loader: "cypress-cucumber-preprocessor/lib/featuresLoader",
          },
        ],
      },
    ],
  },
};

NOTE: I tried removing all Typescript and it still fails instantly on parsing .feature files.
plugins.js:
/* eslint-disable @typescript-eslint/no-var-requires */

// ***********************************************************
// This example plugins/index.js can be used to load plugins
//
// You can change the location of this file or turn off loading
// the plugins file with the 'pluginsFile' configuration option.
//
// You can read more here:
// https://on.cypress.io/plugins-guide
// ***********************************************************

// This function is called when a project is opened or re-opened (e.g. due to
// the project's config changing)

const fs = require("fs");
const wp = require("@cypress/webpack-preprocessor");
const coverageTask = require("@cypress/code-coverage/task");

const webpackConfig = require("../webpack.config");
const autoRecord = require("./auto-record/plugin");

module.exports = (on, config) => {
  const options = {
    webpackOptions: webpackConfig,
  };
  on("file:preprocessor", wp(options));
  on("task", coverageTask);
  autoRecord(on, config, fs);
};

cypress.json:
{
  "baseUrl": "http://<IP_ADDRESS>:8085",
  "reporter": "junit",
  "ignoreTestFiles": [
    "*.hot-update.js",
    "**/integration/**/*"
  ],
  "testFiles": "**/*.{feature,features,ts}",
  "integrationFolder": "cypress/e2e",
  "videosFolder": "cypress/e2e/videos",
  "sceenshotsFolder": "cypress/e2e/screenshots",
  "viewportHeight": 1000,
  "viewportWidth": 1400,
  "reporterOptions": {
    "mochaFile": "results/junit-[hash].xml"
  }
}

Looks like the issue happens since this change in browserify resolve
https://github.com/browserify/resolve/commit/535ec22acf6d5cc4fa3665ab6dbb6755519e6deb#diff-688ede0ee2da1fa3d89f2fc485f39273R8
typeof fs.realpath.native === 'function' ? fs.realpath.native : fs.realpath;

fs.realpath is undefined
I'm digging into how to pingpoint that version to an older versoin for us or if there is something else we can do

@lgandecki confirmed this fixes it! I added:
    "resolve": "1.15.1",

to our package.json resolutions field and now it works:

great! We might need to add this to the README.md for now..

As @cellog mentions above, adding
"resolutions":  {
    "resolve": "1.15.1"
}

in your package.json should help for now.
I've also opened a PR for more permanent solution:
https://github.com/browserify/resolve/pull/220

@mramsden that is for npm users. yarn uses resolutions natively. Definitely worth mentioning with a link to the docs for both solutions. Thanks so so much for the quick resolution!

Are you mocking out fs? fs.realpath has been in node since v0.1.31 - if your fs implementation lacks it, then it's broken. The solution is to fix your fs implementation.

@ljharb thanks for stopping by. :-)
That portion of the code runs and fails in the browser not in node. We are not mocking it in any way. I thought that changing the sync/async modules of resolve package would be a quick and safe change.
Anyway - Thanks to your comment I went back to the code to take another look. I noticed it was the import of cucumber that was causing the failure. Even if we import "pure" functionality of cucumber, requiring the main cucumber module that reexports its internals and APIs brings a lot of baggage, including it's cli, which brings bluebird, which brings the resolve package that now fails in the browser. When I changed all the cucumber imports to point to the files we actually need it clicked. And it will be probably be much faster as well. So definitely a win. I'd hope for some kind of a treeshaking as I'm not that comfortable with relying on a specific structure of a 3rd party package, but this will have to do for now.
I will release a fix shortly.

Either way, I’ll have a patch out to avoid this error for resolve in the next 10 hours.

:tada: This issue has been resolved in version 2.3.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

@lgandecki I get the same error with v2.3.1
Uncaught TypeError: Cannot read property 'native' of undefined

@id-dan works for me in the repro repo. Please verify your version with
grep version node_modules/cypress-cucumber-preprocessor/package.json

remove your yarn/package lock , remove your node_modules, make sure your version is specified as
"cypress-cucumber-preprocessor": "2.3.1"
reinstall everything and give it another try

thank you, @lgandecki
works after removing and reinstall - node_modules 😎

Thank you @lgandecki
it works nicely after removing lockfile and running yarn.

resolve v1.16.1 is released, which avoids this error.


feat: add var promtail_binary_local_dir and promtail_skip_install

Feat :

Add var promtail_binary_local_dir in order to use directly binary of promtail when download from internet is not possible
Add var promtail_skip_install in order to skip installation task when promtail is already installed

@OuiSouss
Thank you for the contribution.
As this changes the behaviour of the role - it would be great to have a scenario covering the different path of using the feature.
Have you thought of yet, what would be the best approach to add tests for your use-case?

Hello,
About this question :

Have you thought of yet, what would be the best approach to add tests for your use-case?

I haven't thought of a test case yet because I haven't mastered testing with ansible.
But, I presume that it is necessarary to test when the variable  promtail_binary_local_dir is not empty, that the directory {{ promtail_install_dir }}/{{ promtail_version }} is well created and the next task has copied the file at the good destination.
About this question :

can you elaborate on the use-case where it makes sense to skip installation?

For example, my use case for this variable is in the case, where I have already installed  and I know it is installed but I just want to change the configuration. And in the case where I made a mistake on this configuration, I just want to change it back to a normal configuration without necessarily reinstalling the tool because it is well installed.
I don't know if I'm expressing myself correctly. If not, please tell me so that I will try to rephrase it

For example, my use case for this variable is in the case, where I have already installed and I know it is installed but I just want to change the configuration. And in the case where I made a mistake on this configuration, I just want to change it back to a normal configuration without necessarily reinstalling the tool because it is well installed.

Can you clarify, if in that use-case promtail was installed via the role or not?
As mentioned previously, the role is based on the premise, that it will install promtail and manage it thereafter ( updates and configuration changes ). It is not intended to be used with externally installed promtail versions. For that specific scenario, a lightweight role only managing the configuration ( and eventually restarting a service ) should be enough.
The role is designed idempotent, so that any successive runs should not execute the download/installation steps ( but ansible will show "no changes" ) so that you can update the configuration at any point in time and the suggested variable is not required

I haven't thought of a test case yet because I haven't mastered testing with ansible.
But, I presume that it is necessarary to test when the variable promtail_binary_local_dir is not empty, that the directory {{ promtail_install_dir }}/{{ promtail_version }} is well created and the next task has copied the file at the good destination.

Can I ask that you write a scenario for testing the functionality of promtail_binary_local_dir - otherwise it will be hard to maintain this switch in the long run and ensure that it will not break when changes are required. In https://github.com/patrickjahns/ansible-role-promtail/tree/master/molecule you can see 2 simple test matrix scenarios and adapt them to testing your specific addition

I've given the concept of promtail_binary_local_dir another thought. Wouldn't it make sense to just provide a path to the zip file, so that the role performs as before, just without the download?

The role is designed idempotent, so that any successive runs should not execute the download/installation steps ( but ansible will show "no changes" ) so that you can update the configuration at any point in time and the suggested variable is not required

Yes, i forgot the aspect of indempotence. Indeed, this variable is useless. I'll remove it.

I've given the concept of promtail_binary_local_dir another thought. Wouldn't it make sense to just provide a path to the zip file, so that the role performs as before, just without the download?
Can you clarify what the added benefit of using the extracted binary is?

Exactly, it might be more logical to keep the archive, it would remove a manual task.
So, in this case we just need to add a when condition on Download promtail binaries task to check if the archive {{ promtail_tmp_dir }}/{{ promtail_version }}_promtail-linux-{{ go_arch }}.zip  exist and skip when the archive is already downloaded. Is this a best alternative before I modify the code ?

If you can place the archive in the configured "{{ promtail_tmp_dir }}/{{ promtail_version }}_promtail-linux-{{ go_arch }}.zip" path, it will already skip downloading if the file exists. See: https://github.com/patrickjahns/ansible-role-promtail/blob/master/tasks/install.yml#L61-L67
Do I understand you correctly - the main idea is, that you want to avoid that the role is required to fetch information from the internet - correct?
So we need to:

Prevent the preflight requests from fetching information from the web https://github.com/patrickjahns/ansible-role-promtail/blob/master/tasks/preflight.yml
If the path on the system for the zip file needs to be configurable, add a variable to do so and skip the download accordingly

@OuiSouss
Are you still interested in bringing this feature into the role?

@OuiSouss
Thank you for the feedback - no worries - take your time.

I worked this weekend on testing with molecule. But, I still have problems with last task, when testing if the service is up.
I will commit and push this work. Then we can discuss about it.

Feel free to also push unfinished work to share and iterate on it together

I found a way to test the systemd services but changing the image from ubuntu to centos. I don't know if this is a problem.

@OuiSouss
Can you add your test-suite to the github actions run as well at https://github.com/patrickjahns/ansible-role-promtail/blob/master/.github/workflows/test.yml#L38-L39
So we can see the results in the pipeline run and iterate over it if there are issues

Everything is ✅ - thank you so much for your contribution @OuiSouss 👏

Cool, thanks for the review.
It was very challenging make approve this PR

It was very challenging make approve this PR

Do you have any feedback to share, how I can improve the process here? Is there anything that I should personally change to accommodate contributors better?

Do you have any feedback to share, how I can improve the process here? Is there anything that I should personally change to accommodate contributors better?

I think the process is good. You are very attentive to all notification on PR. Your comments are relevant.
One little things you can add to help contributors could be a CONTRIBUTORS.md to inform about process, test ... and an extra point, you could create a template file for PR and Issues.


Add a man page

During the latest Debian package update, lintian warned that no manual page for fakemachine exists. Add a manual page so that the next import closes this warning.

What's the reason behind having the generated artefacts in git? I've seen many projects avoid that and only a few that do.

What's the reason behind having the generated artefacts in git? I've seen many projects avoid that and only a few that do.

Really at this point it's to have unity with debos and get a man page generated. It's one less thing to do at release time too. I have no preference ;-).

would be nice to improve and not have the man page in git in future at least; but ok for now

bors r+

Bors retry

bors retry


WIP - Add contracts tests for content schema

This PR implements contract testing for the newly defined contact content schema (https://github.com/alphagov/govuk-content-schemas/pull/167). We follow the 'how-to' docs from govuk-content-schema (https://github.com/alphagov/govuk-content-schemas/blob/master/docs/contract-testing-howto.md)
We move out any code that generates JSON to separate presenters in order to be more consistent with the rest of the app and make more obvious to see which attributes are being exported as JSON.
We also add the contact's organisation content_id to the links hash so that we can access the organisation in the content store. We do not remove organisation data from the details hash yet because in contacts-frontend we require the organisation.abbreviation attribute, which is currently not stored for content-store organisations.

The tests pass and this is ready to be reviewed now. :-)

This isn't actually ready to be reviewed at all. :flushed: It's back to WIP 'cause there's a mismatch between organisation content IDs in here, and organisation content IDs in the content-store which we need to work out. :disappointed:

I rebased these commits to reorder 5d87084 to be before 1ace247, which now displays correctly in git log. The commit ordering in this PR hasn't updated. We think it might be due to this.

As part of this PR, we will need to run rake contacts:register_in_content_store which will republish all contacts with their organisation's content_id to the content-store

:sunny:


Added changes to sensors.cpp for DriverFramework

This only works for DF based builds (not NuttX).
NuttX is not yet ported to DF.
Signed-off-by: Mark Charlebois<EMAIL_ADDRESS>

Before merging it would be good to understand what our timeline is for porting the existing drivers and if this is needed to unblock SITL.

I need to create an equivalent CDev class and port the NuttX drivers to have a uniformform API throughout. Otherwise both driver models will have to be supported because modules like sensors open the devices to configure and don't rely on just the uorb interfaces.

Everything starts properly with this last change. The re-scheduling is still broken. Working on that next.

@LorenzMeier This seems to work now. NuttX integration still pending, but this seems to work for SITL. Please verify.

Ok, on it!

Nice! The first impression is good.

Digging into the bus error now.

ASAN:SIGSEGV
=================================================================
==42011==ERROR: AddressSanitizer: SEGV on unknown address 0x7fff9bb61c70 (pc 0x00010976726f bp 0x00010d071e70 sp 0x00010d071e70 T4)
#0 0x10976726e in dq_rem dq_rem.c:68
    #1 0x1097662be in work_hrtthread hrt_thread.c:146
    #2 0x1097648cc in entry_adapter(void*) px4_posix_tasks.cpp:85
    #3 0x7fff9bb64059 in _pthread_body (/usr/lib/system/libsystem_pthread.dylib+0x4059)
    #4 0x7fff9bb63fd6 in _pthread_start (/usr/lib/system/libsystem_pthread.dylib+0x3fd6)
    #5 0x7fff9bb613ec in thread_start (/usr/lib/system/libsystem_pthread.dylib+0x13ec)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV dq_rem.c:68 dq_rem
Thread T4 created by T0 here:
    #0 0x109b768d9 in wrap_pthread_create (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/7.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x388d9)
    #1 0x10976457f in px4_task_spawn_cmd px4_posix_tasks.cpp:180
    #2 0x1097661a2 in hrt_work_queue_init hrt_thread.c:270
    #3 0x109763ef9 in px4::init_once() px4_posix_impl.cpp:71
    #4 0x10974e6a5 in main main.cpp:188
    #5 0x7fff927435c8 in start (/usr/lib/system/libdyld.dylib+0x35c8)
    #6 0x1  (<unknown module>)

==42011==ABORTING
Tools/sitl_run.sh: line 94: 42011 Abort trap: 6           ./mainapp ../../../../${rc_script}_${program}


can not install Jenkins, exiting :-(

Hi,
I have been having this problem whenever i try to install oneops with Vagrant, need help:
==> default: Downloading jenkins war: http://mirror.xmission.com/jenkins/war-stable/1.642.1/jenkins.war
==> default: Can not instal jenkins, exiting :-(

Hi Seeing that you are trying in Ubuntu , Could you please check if this is related to this https://github.com/oneops/setup/pull/8 ?

per slack this is resolved


Add a sandbox for PortalLink and Field

I found some related classes in /src/geometry/ and /src/mesh/, but had no idea how to add them to the scene and get them rendered. I am looking into ResonatorLink, thinking about there should be something common between them, and your demo in this will be appreciated.
Thank you.

You bring up something I've been meaning to clean up for a while... Everything in /src/geometry/ is actually from the old, deprecated THREE.js-dependent version.  I've yet to finish porting everything over to the new version, so I left that code in place until I got around to it.  Fields, and the beginnings of particle systems were things left on my todo list... I guess I should get to them.
As for portal links, they're a little tricky, since they're dynamic meshes.  Check out this little script:
https://gist.github.com/DeviateFish/f9c3a5b89eae51a9d4a8
Basically, you need to create and manage the mesh (which handles adding/removing links), then create a LinkDrawable with the proper texture for rendering.  Link meshes also have a limit to how many links they can render, which currently isn't enforced... so be careful not to try to add too many links to a mesh.
I need to figure out a better way of handling dynamic meshes in general, so if you have any ideas, let me know.

Looks like the Field is quite similar to PortalLink, I will attempt to adapt it if possible.
I have read about the Mesh and the Drawable, the design is not bad and I currently don't have a better idea on it. But if we want refactoring, there will be a lot of work to do.

I've actually debated the idea of making Links/Fields single-item constructs, rather than sets of links/fields like they are (or would be).
I think this would simplify how links and fields are created, but at the cost of making them have slightly more poor performance.
Most of how I'm doing things is reverse engineered from the game client itself; but the game client has had significant performance optimizations, so some of them have made them into this library, where they seem to cause more problems than they solve.
I think resonator links might make sense to leave as a system, but fix them to a max of 8 links per system, and configure them accordingly.
In theory, this should let them be created in the same was as inventory items/portals, etc... Just instantiate a Drawable and call it a day.
Thoughts?

If I were you, I will try to make code more readable and easy to use, unless the performance is really unacceptable.
The current implementation enlarges the GLBuffer when the count of links increases, and ends up throwing error when it is larger. And this can be solved by making them separate items. And within the limitation, I don't see any performance issue.
So as a conclusion, I will support making them items.

Sorry I didn't follow up on this earlier.
I think that's a good line of reasoning.  I'll make the link geometry less dynamic, make it one link per mesh, and call it a day.  Should greatly simplify their use.  However, it might introduce some issues with reorienting the links and such (i.e. applying transforms), so it might be worth readdressing in the future.

That's a lot of work. Thanks for your hard work.

Done in v0.17.0


Add an equivalent of workon from virtualenvwrapper

Workon does two things. When executed with no args, it lists all available projects (i.e. venvs).
More helpfully, it streamlines the activation process when opening a new shell. This is super useful if you have dozens of projects you work on regularly. A possible syntax for pipenv could look like this:
~ $ pipenv work
blog
django
requests
supersecretproject
pipenv
~ $ pipenv work requests
Moving you to the requests project and activating the shell
(requests) ~/code/requests $

(PS1's might not be right for pipenv behaviour, but you get the idea.
This streamlines the developers' flow from:
cd code/requests
pipenv shell

to just:
pipenv work requests

It's a minor enhancement but something I'd miss moving from virtualenvwrapper.

I like this idea — it would automatically CD into the directory for you, too.
Unfortunately, we don't keep that information around in the virtualenv. We could add it, but it would only work on new virtualenvs going forward...

Also, would need to think of what would happen if there are two directories called 'requests'.

okay ready

got really close to this working — but it was too slow to crawl the directory structure.

Tabling it for now — thanks for the idea!

it was too slow to crawl the directory structure.

How about making use of WORKON_HOME environment variable and looking for virtualenvs only there? This would give workon command for all people used to it from virtualenvwrapper.

We do this already for anything managed by pew.

On Oct 20, 2017, at 4:03 AM, Piotr Dobrogost<EMAIL_ADDRESS>wrote:
it was too slow to crawl the directory structure.
How about making use of WORKON_HOME environment variable and looking for virtualenvs only there? This would give workon command for all people used to it from virtualenvwrapper.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@techalchemy is correct.  This is the default with pew.

How about just maintaining index file (in ~/.pipenv/ or something)? You should support projects with PIPENV_VENV_IN_PROJECT=1 also, and simply looking at WORKON_HOME is not sufficient for that anyway.

It will be sufficient for that in the next release where we use temporary environments to make a modification to WORKON_HOME when using VENV_IN_PROJECT with pew.

On Oct 23, 2017, at 3:03 AM, Tuukka Mustonen<EMAIL_ADDRESS>wrote:
How about just maintaining index file (in ~/.pipenv/ or something)? You should support projects with PIPENV_VENV_IN_PROJECT=1 also, and simply looking at WORKON_HOME is not sufficient for that anyway.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@techalchemy Do you mean that you write symlink or something to WORKON_HOME even with VENV_IN_PROJECT?

No.  I mean what I said.
    try:
        with temp_environ():
            if PIPENV_VENV_IN_PROJECT:
                os.environ['WORKON_HOME'] = project.project_directory

            c = pexpect.spawn(
                cmd,
                args,
                dimensions=(
                    terminal_dimensions.lines,
                    terminal_dimensions.columns
                )
            )

    # Windows!
    except AttributeError:
        import subprocess
        # Tell pew to use the project directory as its workon_home
        with temp_environ():
            if PIPENV_VENV_IN_PROJECT:
                os.environ['WORKON_HOME'] = project.project_directory
            p = subprocess.Popen([cmd] + list(args), shell=True, universal_newlines=True)
            p.communicate()
            sys.exit(p.returncode)

If this is working, why is there no open pull request on this feature @kennethreitz?

@kennethreitz Is this feature still a thing? I really love Pipenv and recently converted all my projects, but an equivalent to virtualenvwrapper's workon would really add that last bit of luxury to it. You should consider adding it ;)

I'm also interested in this -- workon support would be a great convenience.

I prototyped it out, but it's not feasable, unfortunately. Rely on pew's functionality for this.

@kennethreitz @fweidemann14 @kblicharski,
I finally understood. Here is a short rosetta, for someone who is as new to pew and pipenv as me.

virtualenvwrapper + pip
pew + pipenv

mkvirtualenv
pew new

cpvirtualenv
pew cp

lsvirtualenv
pew ls

workon
pew workon

deactivate
Ctrl + D / exit

pip install
pipenv install

A few gotchas:

The cdproject equivalent from virtualenvwrapper is missing. But pew setproject can do the change to directory once.
pew new does not have a --system-site-packages option. Instead there is a separate pew toggleglobalsitepackages command.

This would be a great table to add to the docs :)
On Tue, Feb 27, 2018 at 10:47 PM Ashwin Vishnu<EMAIL_ADDRESS>wrote:

@kennethreitz https://github.com/kennethreitz @fweidemann14
https://github.com/fweidemann14 @kblicharski
https://github.com/kblicharski,
I finally understood. Here is a short rosetta, for someone who is as new
to pew and pipenv as me.
virtualenvwrapper + pip pew + pipenv
mkvirtualenv pew new
cpvirtualenv pew cp
lsvirtualenv pew ls
workon pew workon
deactivate Ctrl + D / exit
pip install pipenv install
A few gotchas:

The cdproject equivalent from virtualenvwrapper is missing. But pew
setproject can do the change to directory once.
pew new does not have a --system-site-packages option. Instead there
is a separate pew toggleglobalsitepackages command.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/535#issuecomment-369138703, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjqx5S5S0T_atTJnQi6UpGF-8XPikcks5tZPaDgaJpZM4PWVYT
.

What would be the workflow for using pew with pipenv?  I see that pipenv and pew have some overlap - which command should I be using to create the virtualenv? Should I use pew add from inside a pipenv shell? I'm new to pipenv and love it so far. Justing missing the workon functionality.

Pipenv handles virtualenv creation for you, so you just use pipenv install to create the env, then pipenv shell to get an environment or
pipenv run <COMMAND> to do something in the shell
On Fri, Mar 2, 2018 at 2:55 PM Jason Slay<EMAIL_ADDRESS>wrote:

What would be the workflow for using pew with pipenv?  I see that pipenv and pew have some
overlap - which command should I be using to create the virtualenv? Should
I use pew add from inside a pipenv shell? I'm new to pipenv and love it so
far. Justing missing the workon functionality.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/pypa/pipenv/issues/535#issuecomment-370078004, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABhjq96a3RkHgh99kZ4CEJU4PMkbC-wEks5tac32gaJpZM4PWVYT
.

Apologies. I was referring to how to use pipenv with pew to replace the functionality of virtualenvwrapper. pew also creates virtualenvs. What is the workflow for using these packages together?

To anyone that might interested, I started a light pipenv companion to help do some of the work done by workon and cdproject.
Unlike pew, it does not attempt to manage your venvs in any way. All it does is it walks WORKON_HOME env and provides a quick way activating the created venvs,  and cds into the project directories.
Venv <> project dir linking is currently done manually, similar to setprojectdir but it will be automatic once PR #1861 is merged + released.
https://github.com/gtalarico/pipenv-pipes

@gtalarico Now this is exactly what I wanted Pipenv to do, great effort mate. Going to use it for sure!

If anyone is interested in a more virtualenvwrapper way, I created pipenvwrapper
I tried pipes and pew and both are very good tools, but not the exact tools I was looking for my workflow, so I built pipenvwrapper using the base code of virtualenvwrapper.
The supported functions (simplified in some cases and no hooks support) are workon, lsvirtualenv, cdproject, cdvirtualenv, cdsitepackages, mkproject and rmvirtualenv.
"Workon" works with the venvs in $WORKON_HOME folder only, as virtualenvwrapper does.
To allow pipenvwrapper coexist with virtualenvwrapper, the function names have been renamed, but if you prefer the original ones and override virtualenvwrapper, you can do so setting an env variable in the shell startup file.
https://github.com/Peibolvig/pipenvwrapper

I’d be interested in someone convincing Kenneth (via an enhancement proposal) to allow some kind of plugin framework adoption, maybe via pluggy? No idea if that would work here, but I might put something together or provide feedback


Issues with operands on the stack in lambdas

Both SVM lambda integration targets now fail with the following messages:
failures:

---- run_lambda_ap stdout ----
	thread 'run_lambda_ap' panicked at '[fatal][ADD]: expected first operand, found None
', seax_svm/src/lib.rs:218

---- run_nested_lambda stdout ----
	thread 'run_nested_lambda' panicked at '[fatal][SUB]: expected second operand, found None
', seax_svm/src/lib.rs:231

failures:
    run_lambda_ap
    run_nested_lambda

I'm not entirely sure what's up here, but I have the strong sense that it has to do with the way lambda parameters are assembled into a closure.

This issue was fixed in 18b5459423004415efdf4f57c7e993f3697b7ae3

With that said, there is still one more weird closure building issue (closure construction is, evidentially, a Hard Problem In SVM), but it only breaks the nested lambdas target (for reasons currently unknown to me).


erro heroku

When you click on the deploy button on heroku, it can not finish deploy

Thanks for letting me know.

I don't have any time immediately to tackle this, but if you feel up to it, you could tackle it via a PR and I could help if you get stuck. I might be able to look at it this weekend.


Longest Common Subsequence in D-Dynamic Programming

Description
The longest common subsequence (LCS) is a common dynamic programming problem . LCS is defined as the longest subsequence that is common to all the given sequences, provided that the elements of the subsequence are not required to occupy consecutive positions within the original sequences.
@Lakhankumawat Can you please assign this issue to me ,I would like to work on it.
I'm a GSSoC 2022 participant.
Domain
Algorithm
Type of Contribution
Addition
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of LearnCPP.

@Lakhankumawat Can you check out the PR related to this issue.


linting feature request: no single star comments

Could I request a rule to ensure there are none of those single star comments, basically
* This is what my code does

Fails, and:
/* This is what my code does */

Passes

Hey Carus!  I've been thinking abou this.  It doesn't sound easy.  These are the initial test cases I came up with - can you think of any more?
/**
 * Examples of *message; format that SHOULD be caught
 */

/* 1. regular comment */
* some text;

/* 2. multiline comment */
*
multiline
text;

/* multiple asterisks - should start on first */
   *---------------------------------------*
   |  This uses one comment statement      |
   |           to draw a box.              |
   *---------------------------------------*;

/* 3. comment at end of statement */
libname x (work); * some text;

/* 4. comment in middle of statement */
run; *walk
; run;

/* 5. comment at start of statement */
*; run;

/**
 * Examples of *message; format that should NOT be caught
 * (this was the first)
 */

/* 2. In a string literal */
data _null_;
  string='no*no;no';
  string="not*this;either";
run;

/* 3. In a %str() block */
%let x=%str(afraid *not; sir);

/* 4. In an nrstr() block */
%let y=%nrstr(try*again;please);

/* 5. In a %put statement */
%put not * today;;

/* 6. As a macro comment */
%* this one is totally normal;

/* 7. in a LUA proc */
proc lua;
submit;
 -- hi *mum;
endsubmit;
run;

Oh wow thanks Allan,
I'll have some of our devs have a look at your cases. I just realized now my example was wrong because I didnt terminate the comment with a semicolon. I am going to leave it that way as that is the very mistake I find sneaks into our code base time and time again when we comment using the single asterisk method.

I'm wondering if we will need to build a tokenizer to make this work!

@all-contributors add @Carus11 for ideas

Hello @Carus11 @allanbowe Thanks for the idea and your input. 🙌🏽
I'll take an initial crack at implementing this at some point next week.


Errant linefeed in credentials file

In some rare cases, the credentials file that Oktaws creates has a carriage return near the end of one of the secrets
It seems to happen for unknown reasons, and when the tokens change after a time period it goes away.
but here’s a simulated example of what it looked like:
aws_session_token=IQoJb3JpZ2luX2VjEND//////////wEaCXVzLWVhc3QtMSJHMEUCIQCvSw68s4gLV5AhSf4kdl/RXeXF2ZuyOBQ00Qiqb1jrOwIgYjI50QHHlSeZEPSSWzhS51r74YqL5YfXYbDuFXtkMlMqzAIIGRAAGgw1NzI3MjQyMDczNjQiDELNBO/7JQ5V0qjw6iqpAva5RNUEAjK2ZcWKqpFxTYNd5N6Q49Cxun/NYGT/uSKxN80UBiqpRaEngle1QD6J5b0bKzG1HYcCD95GfP6nPIUtbrU15e9s3VOZS7DpGGXNi7lSDlxwOgRqjHoNHO7bgtVMdltbWEJihCqAxaKrHEXHxYYqVNKnsLd1QoHoJO3OPrN/      2qqynBCfzrn+tdqiPh05En2RdaNz2JncGJ/4lp1F6xjHaf87YVzIL+hS3v5YR59sQDGwyHs4Lfa8KGYIra8f9Qv3Ppr4KitgqINOreHDdWq8SWtScIUiLdGIvXtD71qM8ZakDtt6cmlD5w+Tss1om2wKpZWs+WFkYgLFBszlaxSkkCxqFSbArA98u/wZ58GWJTNJ0KWVDN1KqE6ejWt2DX5gFohTbjCYh/iCBjqbAcoYXfexRdkWDK0yCK5sY/G54lBpl9fCMa1m01UV4hSfhMZSayihUZxNc/r/DA0EMo1OOGhww8z5B9M2x0MWAXOyGdqqOAzCCytMkohWbzEcEYLKX9heyrWP8A9BhgnNSBVLWb+                         eX95spbTWyiWqSKQSNjWWcOEC1foJVkkVHCkLDxgfwYngWDv/V/me6
rqBYSUEW6pY30iWebEy
In this case, the token was a problem with the sandbox account.
in the above, the rqBYSUEW6pY30iWebEy needs to be joined with the rest, but there’s an \n right after the me6
Replication process: Unknown.  Running oktaws creates the issue, and I saw it happen multiple consecutive times during a specific period of time.
Command executed: "oktaws"

I believe this is because of oktaws not clearing the credentials file when writing to it


Add webhook ci enhancement

Ⅰ. Describe what this PR does
Ⅱ. Does this pull request fix one issue?

Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #786 (d017014) into master (c56c851) will decrease coverage by 0.87%.
The diff coverage is n/a.

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


test: remove redundant test for cobra library functionality

This test does not verify our code; instead, it tests the functionality of the cobra library, which is outside our scope. Additionally, the test is unreliable as it inherits arguments from the test command line, causing unpredictable behavior. It also outputs the help text directly into the test results, leading to confusing and misleading test output. Removing this test will help maintain clarity and focus on our codebase.

/ok-to-merge


SOLR-17260 ReleaseWizard should remove old minor versions from Docker Hub

https://issues.apache.org/jira/browse/SOLR-17260
This PR implements the suggested policy of deleting version N.M-2 from hub. This means that when we release 9.7, 9.5 will be marked as "unsupported" in docker hub. That is, it will still be available for pull but not advertised as "supported".

Should we remove 9.x.0 when we release 9.x.1?

Should we remove 9.x.0 when we release 9.x.1?

That already happens automatically today since the Dockerfile is x.y/Dockerfile in the repo.
So you could argue that someone using tag 9.4.0 will not get new JRE bugfix updates since the only supported 9.4 version is 9.4.1. But if they use tag 9.4 then they will get the latest. However there’s a best practice of pinning exact versions to avoid unintended upgrades in prod during e.g a normal restart; even bugfix releases can have regressions.