WIP: anonymizer

This is just a work in progress.

Very nice! I like this approach overall.
You've probably already thought through some of this, but what could we do to mitigate the effects of changes to log lines over time? One significant one that jumped out at me was the changes to 03/04 log lines from 2018 to now:
03|2018-01-10T22:39:30.8360000-05:00|12345678|JLGarber|17|46|94ce|2508|0|9d676b7c08ce13221483fd7dd306acae
03|2020-05-25T12:22:09.8540000-04:00|12345678|JLGarber|17|50|0|29|Server|0|0|100000|100000|10000|10000|0|0|-1.653331|18.39634|-2.37337|3.126688||Hash
For summons, there's a slightly different difference:
03|2018-01-11T21:07:29.6550000-05:00|4000afcd|Garuda-Egi|0|3c|4b72|2288|OWNERID|HASH
03|2020-05-25T12:22:09.8540000-04:00|40080d26|Topaz Carbuncle|0|1a|OWNERID|0||1400|1011|590|590|10000|10000|0|0|33.21568|39.45135|1.2|2.956841||HASH
Other than that, the only other thing I would note for now is that it might be nice to have the option to anonymize players as "Player1-PlayerN" rather than "partially-random-cat-name string", for human-readability purposes.

You've probably already thought through some of this, but what could we do to mitigate the effects of changes to log lines over time? One significant one that jumped out at me was the changes to 03/04 log lines from 2018 to now:

Yeah, this is something that worries me a little.  It's along the same lines as hashes not appearing in older ones.
I wonder a little about having a version parameter that would attempt to autodetect from log lines or could be specified directly.  Then if we knew the version, we could have some set of logDefinitions broken out by version, and include only the valid ones.  Maybe they could be sparse sets, such that they'd only include elements that changed from a previous version.

Other than that, the only other thing I would note for now is that it might be nice to have the option to anonymize players as "Player1-PlayerN" rather than "partially-random-cat-name string", for human-readability purposes.

Except 1 isn't a valid character in a player name.  I mean, yes, maybe it doesn't matter, but it would break anybody with a regex that was trying to match player names and didn't include (invalid) numbers.  I would maybe also argue that player ids also cover the "Player N" angle, since they start from 10FF0000 and count up.

I wonder a little about having a version parameter that would attempt to autodetect from log lines or could be specified directly. Then if we knew the version, we could have some set of logDefinitions broken out by version, and include only the valid ones. Maybe they could be sparse sets, such that they'd only include elements that changed from a previous version.

I think that's reasonable. Obviously we can't 100% rely on the header containing the log version to be present, but I think for the vast majority of cases it would be a safe assumption. The 253 line doesn't really seem to have changed much:
253|2018-01-11T19:15:10.5906001-05:00|FFXIV PLUGIN VERSION: <IP_ADDRESS>, DELAY MODE: FastSleep|HASH
253|2020-05-25T12:22:05.4887389-04:00|FFXIV PLUGIN VERSION: <IP_ADDRESS>|HASH

Except 1 isn't a valid character in a player name. I mean, yes, maybe it doesn't matter, but it would break anybody with a regex that was trying to match player names and didn't include (invalid) numbers. I would maybe also argue that player ids also cover the "Player N" angle, since they start from 10FF0000 and count up.

I'm skeptical that that first use case matters. I guess someone might search for player names with a negative-lookup for digits? But I feel like most people in a position to be using both regex and this anonymizer would be able to search by line field instead.
As for the "player IDs cover it" point, it's possible that it's just me, but I find it really hard to differentiate random-looking information visually. There have been plenty of cases, for me (Sophia comes to mind,) where it's a lot easier to inspect things for patterns visually rather than work out how to do it programmatically.
What if instead we were to do something like PlayerAAA-PlayerZZZ? I don't know, I find this much more difficult:
04|2018-01-11T22:45:23.1120000-05:00|10FF012D|X'xzzrtd Tia|6|a|a8|ea|0|01234567012345670123456701234567
04|2018-01-11T22:45:23.1120000-05:00|10FF00E6|X'xzzrqk Tia|5|10|174|d1|0|01234567012345670123456701234567
04|2018-01-11T22:45:23.1120000-05:00|10FF0131|X'xzzrth Tia|18|46|8402|4aad|0|01234567012345670123456701234567

As compared to:
04|2018-01-11T22:45:23.1120000-05:00|10FF012D|PlayerAAA|6|a|a8|ea|0|01234567012345670123456701234567
04|2018-01-11T22:45:23.1120000-05:00|10FF00E6|PlayerAAB|5|10|174|d1|0|01234567012345670123456701234567
04|2018-01-11T22:45:23.1120000-05:00|10FF0131|PlayerAAC|18|46|8402|4aad|0|01234567012345670123456701234567

It's entirely possible that it's mostly a me problem, and if that's the case, no big deal, I'll just modify it for myself. If it's not too much effort to make it an option, though, I think it's worth considering.

What if instead we were to do something like PlayerAAA-PlayerZZZ?

I think you want both a forename and surname here, and preferably want some way to keep the names valid but also decently identifiable. I think Player A -> Player Z doesn't buy enough potential names, and Aa -> Zz would be unfortunate if you incremented on the right-most character then incremented the left-most character once you've exhausted all options, since Player Aa and Player Ab aren't super distinguishable? I'd say you could get around this by having it randomly give you one of the 256 potential options, but you'd have to store them in a dictionary or something. Overall, pretty low cost, but also kind of bleh?
There's also the fact that if you used alpha-only, you have... not great... combinations at both 2 and 3-letter combinations, and at 4-letters you're getting into a slew of interesting words that could litter your code.
I do potentially agree though that while player names are pretty fun, it does make it less legible; but, I wonder how much that matters?

Lalafell name generator incoming

Lalafell name generator incoming

Helping wherever i can 😉
Array.prototype.random = function() { return this[Math.floor(Math.random() * this.length)]; }

function generateLalafellName() {
    const consonants = 'B,C,D,F,G,H,J,K,L,M,N,P,Q,R,S,T,V,W,X,Z'.split(',')
    const vowels = 'A,E,I,O,U,Y'.split(','); // I know, Y is not technically a vowel

    let firstConsonant = consonants.random().toLowerCase();
    let secondConsonant = consonants.random().toLowerCase();

    let firstVowel = vowels.random().toLowerCase();
    let secondVowel = vowels.random().toLowerCase();

    let fname = firstConsonant.toUpperCase() + firstVowel + firstConsonant + firstVowel + secondConsonant + secondVowel;
    let lname = fname.charAt(2).toUpperCase() + fname.slice(3);

    return `${fname} ${lname}`;
}

Ok, I think this is looking pretty reasonable at the moment.  I need to do a bit more checking to make sure these anonymized logs can still be imported.  I think I need to include all the combatants in a split log as well for ACT to be able to figure out where the combat starts, and there's also a few issues where parsed messages don't end up having names correctly, e.g. [18:23:18.663] 1E:10FF000C: loses the effect of Dualcast from .
Output looks like:
$ node split_log.js -f /d/ffxivlogs/log/Network_20510_20200716.log -lf
2020-07-17
   1) 01:08:02  1m53s Mist                      [Zone]
                      ~Syrcus Tower~
   2) 01:11:07    45s The Ladder of Ascension   [Unseal]
   3) 01:12:27  1m56s The Gathering             [Unseal]
   4) 01:14:51  1m10s The Braid                 [Unseal]
   5) 01:16:24  1m24s The Ring of the Protector [Unseal]
   6) 01:18:16    56s The Golden Sacristy       [Unseal]
   7) 01:19:38   2m8s The Final Curtain         [Unseal]
   8) 01:22:15   3m7s The Emperor's Throne      [Unseal]
   9) 01:29:07  4m17s Il Mheg                   [Zone]
  10) 01:34:01  5m33s Containment Bay (S1T7)    [Win]
  11) 01:40:43    44s Il Mheg                   [Zone]
  12) 01:42:31 11m20s Lakeland                  [Zone]
                      ~Castrum Abania~
  13) 01:58:14  1m52s Terrestrial Weaponry      [Unseal]
  14) 02:03:31  1m36s Project Aegis             [Unseal]
  15) 02:09:01  2m21s The assessment grounds    [Win]
  16) 02:13:04  2m41s Lakeland                  [Zone]

$ node split_log.js -f /d/ffxivlogs/log/Network_20510_20200716.log -lf 8
Wrote: SyrcusTower_TheEmperorsThrone_20200717_012215_3m7s.log

$ node split_log.js -f /d/ffxivlogs/log/Network_20510_20200716.log -lz
2020-07-17
  1) 01:05:53   4m2s Mist
  2) 01:09:54 16m36s Syrcus Tower
  3) 01:26:30  2m25s Mist
  4) 01:28:55  4m29s Il Mheg
  5) 01:33:23  6m37s Containment Bay (S1T7)
  6) 01:40:00  1m27s Il Mheg
  7) 01:41:27 12m23s Lakeland
  8) 01:53:50 18m12s Castrum Abania
  9) 02:12:02  3m43s Lakeland

$ node split_log.js -f /d/ffxivlogs/log/Network_20510_20200716.log -lz 8
Wrote: CastrumAbania_20200717_015350_18m12s.log

I think there could be some more cleanup to skip overworld zones, but I think this is fine for now.  I think it's plausible to reshare the encounter_tools.js with #1387 and not duplicate that logic in a third place.
The follow-up from this is to make a webpage where folks can drop a log in and do this logic, but I'll probably land this first.
The real follow-up is to then create a log repository of various logs across all content that people can refer to for trigger, timeline, and reference purposes.

Ok, fixed the ACT issues.  It really needs all of the combatant lines there to know what to do with players and encounter starts.
I think this is ready to go, if anybody has any other feedback?

Good enough.  We can fix it in post if anybody has thoughts.


Retain original unaltered BOM

Especially for XML BOMs, there can be additional information, like extensions and signatures, that are stripped when serializing/deserializing using the core spec data models. This should likely have a separate endpoint to indicate that you are retrieving the original, unaltered BOM.

Available in v1.1.0


Update how-to-write-a-resolver doc

Changes
The service account name and namespace for resolvers were the old one used in the resolution repo.
Now both service account and namespace used for resolvers should be how-to-write-a-resolver.
Signed-off-by: Chuang Wang<EMAIL_ADDRESS>
Submitter Checklist
As the author of this PR, please check off the items in this checklist:

[ ] Has Docs included if any changes are user facing
[ ] Has Tests included if any functionality added or changed
[ ] Follows the commit message standard
[ ] Meets the Tekton contributor standards (including
functionality, content, code)
[ ] Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
[ ] Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
[ ] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes
NONE

@abayer Please take a look. Thanks!

/kind documentation

/approve


Entity model isn't enhanced with enabled groovy support

Environment

Platform version: 7.0.BETA1

Description of the bug or enhancement

Minimal reproducible example

Create new project using CUBA STUDIO
Extends User entity
Enable Groovy support for the project
Assemble and start project
Test project: sample70.zip

Expected behavior
Entity User should be enhanced
Actual behavior
User entity isn't enhanced. Exception in the log:

Exception Description: The attribute [id] of class [com.company.sample70.entity.ExtUser] is mapped to a primary key column in the database. Updates are not allowed.
	at org.eclipse.persistence.exceptions.ValidationException.primaryKeyUpdateDisallowed(ValidationException.java:2551) ~[org.eclipse.persistence.core-2.7.2-2-cuba.jar:na]
	at org.eclipse.persistence.mappings.foundation.AbstractDirectMapping.writeFromObjectIntoRowWithChangeRecord(AbstractDirectMapping.java:1298) ~[org.eclipse.persistence.core-2.7.2-2-cuba.jar:na]
	at org.eclipse.persistence.internal.descriptors.ObjectBuilder.buildRowForUpdateWithChangeSet(ObjectBuilder.java:1776) ~[org.eclipse.persistence.core-2.7.2-2-cuba.jar:na]
	at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.updateObjectForWriteWithChangeSet(DatabaseQueryMechanism.java:1043) ~[org.eclipse.persistence.core-2.7.2-2-cuba.jar:na]
	at org.eclipse.persistence.queries.UpdateObjectQuery.executeCommitWithChangeSet(UpdateObjectQuery.java:84) ~[org.eclipse.persistence.core-2.7.2-2-cuba.jar:na]
	at org.eclipse.persistence.internal.queries.DatabaseQueryMechanism.executeWriteWithChangeSet(DatabaseQueryMechanism.java:314) ~[org.eclipse.persistence.core-2.7.2-2-cuba.jar:na]

Please check 6.10 version too

This issue happens now with latest release 7.0.3

@clumsym76 could you provide a sample to reproduce the problem?

Hello dear Cuba team, pls find the attached sample.
sample.zip

@clumsym76 it seems that your problem is not related to enhancing and groovy support, because groovy support is not enabled in the sample project.
I've extended the User entity and enabled Groovy support to check the case and everything is ok:
groovy-support-test.zip
Please create a topic on our support forum if the problem will not be solved: https://www.cuba-platform.com/discuss/

Thx, I see, I'll create a new topic then


Add text field when selecting "no" for "Did you feel safe with this person's behavior?" during review

We should give users the opportunity to anonymously provide additional details if they select "no" when answering the question "Did you feel safe with this person's behavior?" when leaving a review for a user, OR if their score using the slider scale is <0.25. This will:

Prevent false-positives where people accidentally select "no" (this currently happens on a regular basis) or accidentally don't move the slider.
Help support more easily and accurately identify problematic users.
Encourage users to provide more anonymous feedback (rather than "reporting", which seems extreme to some).

In either case, the following should happen after the user presses the button:

User should be taken to a new page with a free text box and text above the box that should read:

Please provide our safety team with details so we can keep Couchers safe for everyone. Anything you type below will be kept private. It will not be seen by [USERNAME] and will not be shown on the website. You will have a chance to leave a public reference on a different page.

The text field should be optional, and there should be a "back" button and a "continue" button at the bottom. Clicking continue submits the form and takes the user to the page where they can leave their public reference.

The text submitted via the form should be included in the notification sent to<EMAIL_ADDRESS>and stored on the backend. The notification should be similar to the current content/user "report" notification.
Components:

[ X ] Backend changes to enable appending the submitted text to the DB
[ X ] Backend changes to enable notification of support at<EMAIL_ADDRESS>(similar mechanic as reports currently work)
[ ] Frontend changes to adjust current behavior
[ ] Frontend changes to add new page with text field
[ ] UI/UX Testing

This has been implemented a looong time ago in backend: #2307

Going through tickets for new project board. Am I correct this still needs the frontend done? @aapeliv @jesseallhands ?

Yes, and it's an important one for our safety goal.

is this is missing the UI/UX, I guess should be moved to the backlog and considered not ready?

This is designed. Here are the desktop designs:

@jesseallhands I feel this tickets it's a mix of different ideas/problems, the title says Add text field when selecting "no" for "Did you feel safe with this person's behavior?" during review but I see a lot of screenshots, some tickets related the feedback slider and other comments, I believe this should be broken down into smallers/more specific tickets.... you want me to do it?

Sorry, I should have clarified: I just posted the whole flow for context. This issue is just for adding the text box / updating the wording of the existing text.

note to me: split this ticket

@bakeiro Feel free to edit it if you see fit! I was just making sure stuff I was moving from the old upcoming to the backlog were still relevant.

@nabramow and @bakeiro I edited this issue and the design section to be more clear. I will also update the design screenshots a bit because I realized it makes sense to just have one "submit private feedback" page rather than 2. Updating the flow for the slider section of the reference flow can be handled on a separate github issue (which I'm composing right now).


nuke-graph-directory.sh: Improve subvolume search

This change allows btrfs subvolumes to be found in additional system configurations. The old logic failed to correctly identify subvolumes when the root fs was mounted as a subvolume that was not the btrfs filesystem root.
Should also fix problems discussed recently in #7423
For reference, my system is mounted with the root filesystem as a btrfs subvolume named root. An excerpt of btrfs subvolume list is shown below. The current script tries to delete /root/var/lib/docker/btrfs/subvolumes/... which fails because of the /root/ at the beginning.
This change should be safer in that find will never go outside of the search directory as btrfs subvolume list was doing.
ID 9093 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/56cce85c15604d98da0bded7307511f9ee7589cbafe42ef1e8b23c5bbd0c5b48
ID 9094 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/e6fa3a93184391d1f316310a3e0a679e4778a742912f99738ff044cec24feeb5
ID 9095 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/606b386f540e415f3a7ba765aaa8f1c69d339600e4ad7e849d675097bdc6bdec
ID 9096 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/7d36c9e99386e369dd938132b4651ef0b6df9fadeabd95aac7e66939e8b4e7c4
ID 9097 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/596c7098712cb929c6a6d92bfb7c90b0383df60fc981380e989ff06b732342b1
ID 9098 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/3250152b04288d6c5705f7fdb7bc52be14a61fef7c38a1d1ec963244c5d48985
ID 9099 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/ffa3e9a09957609336cfe8e3b093d7cebeb178d2a04115755eb0df8d8892b8b4
ID 9100 gen 353259 top level 2870 path root/var/lib/docker/btrfs/subvolumes/c9b1d22d43eb601fd00b80960c18d305b7e2a1f10a99bdcc19473544db9f43b3

See also: http://stackoverflow.com/questions/25908149/how-to-test-if-location-is-a-btrfs-subvolume

ping @vdemeester @tianon PTAL

ping @tianon @jfrazelle

Interesting!  I like the approach!  Does btrfs subvolume delete do anything dangerous on other filesystems if we happen to have an inode number of 256? (or does it simply fail/ignore?)

I didn't dig into the btrfs progs source, but my quick test on a directory yielded the result below. I figured that since we're using the btrfs tools to try and delete a subvolume, even if the tools don't fail out the ioctl will.
$ sudo btrfs subvolume delete dir
ERROR: not a subvolume: dir

Fair enough!  Approach LGTM, just a small question about whether the link in the comment should be to the question or to the answer. :+1:

That makes sense to me. Linking to the answer gives the correct context.
I wasn't sure what your squash policy is, but I just pushed an amended commit since it's a trivial change.

LGTM, thanks! :+1:

ping @vdemeester @vbatts could you have a quick look as well? I don't run BTRFS, so can't verify :smile:

LGTM


Start a specific track from a playlist

I have the following track:
const tracks = [
    {
        id: "166898571529",
        ...
    },
    {
        id: "166898571539",
        ...
    },
    {
        id: "166898571549", // <--- I need to start song play from here
        ...
    },
    {
        id: "166898571559",
        ...
    },
]

My users start playing songs when they tap a song. On a playlist they can tap any song whatever they want and any position. So, is there a way (from this lib) to start a song as I described above in comment and when the current song ends the track list continue playing next track<PHONE_NUMBER>59 ?
PS: I tried insertBeforeId but as I referred in https://github.com/react-native-kit/react-native-track-player/issues/170#issuecomment-470998449 it doesn't work.

I guess I would try to split the logic of the playlist.
Maybe 2 playlist would do the trick. One playlist in the state in order to be shown to your users, and the second one built in RNTP.
When your user tap on a song, I would removeUpcomingTracks() on the player, then add the song.

Yep, that’s the trick. I did something like that.

it solve my problem
 const addRadioToTrackPlayer = useCallback(
    async (radios: Radios, radioIndex: number) => {
      const radio = radios[radioIndex];

      const currentTrack = {
        id: radio.title_song,
        url: radio.radio_stream,
        title: radio.radio_name,
        artist: radio.title_song,
        artwork: `https://www.radioair.info/images_radios/${radio.radio_logo}`,
      };

      const playlists = radios.reduce(
        (acc: { before: any; after: any }, radio, index) => {
          const track = {
            id: radio.title_song,
            url: radio.radio_stream,
            title: radio.radio_name,
            artist: radio.title_song,
            artwork: `https://www.radioair.info/images_radios/${radio.radio_logo}`,
          };

          return {
            before:
              index < radioIndex ? [...(acc.before || []), track] : acc.before,
            after:
              index > radioIndex ? [...(acc.after || []), track] : acc.after,
          };
        },
        { before: [], after: [] },
      );

      await TrackPlayer.reset();

      await TrackPlayer.add(currentTrack);
      await TrackPlayer.play();
      await TrackPlayer.add(playlists.before, currentTrack.id);
      await TrackPlayer.add(playlists.after);
      const queue = await TrackPlayer.getQueue();

      console.log(queue);
    },
    [],
  );

const playAudio=async (item:AudioItem)=>{
//check if the Track was added
var list= await TrackPlayer.getQueue()
let selectedIndex=0
let selectedTrack=list.find((track,index) => {
if(track.id==item.id)
{
selectedIndex=index
return true
}
});
if(selectedTrack == undefined)//not added then add to the queue
{
await TrackPlayer.add({
id: item.id,
url:encodeURI(item.fileName),
title: item.displayName,
artist: 'Track Artist',
artwork: require('~/assets/play.png')
});
list= await TrackPlayer.getQueue()
selectedIndex=list.length-1;
}
// skip to selected index then play
TrackPlayer.skip(selectedIndex)
await TrackPlayer.play();
}

Yep, that’s the trick. I did something like that.

Could you share you solution?


Unknown type: "AWSDateTime".

Describe the bug
I am getting a "Unknown type: "AWSDateTime" error when using the library with AWS Amplify
To Reproduce
Steps to reproduce the behavior:

Generate a .graphql schema with AWS Amplify
Configure 'graphql-code' to generate typescript
Attempt code generation with 'graphql-code'

Expected
The typescript code generates correctly
Actual
An "Unknown type: "AWSDateTime" error is thrown

@hirenumradia see: https://github.com/dotansimha/graphql-code-generator/discussions/4311


Pre-release info is shown in two locations

Testing #138068
The existence of a pre-release version is shown in two locations:

IMO moving the "Switch to.." button down to the "This extension has a Pre-Release version" message would simplify the UI (and would make the "pre-release" become more prominent in the UI)

Here is the latest UI

This is as per our initial UX design and I like that the buttons are all together like in the tool bar. Another option would be to remove the message The extension has Pre-Release version available because Switch to Pre-Release Version button is obvious that the extension has a pre-release.
CC @isidorn @misolori

If we want to keep the "sea of buttons" then lets drop the additional message.

Removed the pre-release text in the editor given that the button conveys the message and also reduces the clutter of messages in the editor.

Thanks @sandy081
Makes sense to remove the duplication. I like keeping the 3 buttons, there is enough space and the clutter is not that bad.


Styling of popovers breaks with latest antd version

Describe the bug
When using react-js-cron in conjunction with the latest version of antd (4.6.3 as of writing this), the styling of popovers is broken (the entries aren't shown in a grid). The package.json only specifices >=4.1.0 as the version for this peer dependency. This problem doesn't arise when using antd 4.2.5.
To Reproduce
Codesandbox: https://codesandbox.io/s/reat-js-cron-5chdk
Steps to reproduce the behavior:
Click on any dropdown
Expected behavior
Items in the popover should be displayed in a grid.
Screenshots
With antd 4.6.3:

With antd 4.2.5:

Additional context
The layout breaks since there is an extraneous div inside the grid container instead of the grid-items. Somehow the way the items are rendered within the popover has changed between these two versions (seeing the additional rc-virtual-list classes that are present when using 4.6.3).

Hi,
Thanks for the report 👍
I will investigate the problem and try to make a fix.

This issue has been fixed with react-js-cron version 1.1.0.
Thanks a lot for finding this bug and let me know if there is something else that cause a problem now.
Be sure to read the changelog before using new version 😉


Use gcc:5.5 image since 5.4 isn't supported anymore

According to https://hub.docker.com/_/gcc 5.5 is the oldest supported
version.

Hmm I think the CI failure is related to https://unix.stackexchange.com/questions/508724/failed-to-fetch-jessie-backports-repository.


Added Chocolatey as Windows install method in the readme

Updated the readme to also include Chocolatey as an install method for Windows, instead of only listing Scoop.

Thank you! Ref. e3bf3bc9712b12e9222faafc94df3fd285c26bf3


terminal crash in splash screen

Does this issue occur when all extensions are disabled?: Yes/No

VS Code Version: 1.73.1
OS Version: Darwin x64 21.6.0

Steps to Reproduce:

open terminal crash in splash screen

/gifPlease

Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, .gif files are preferred as they are displayed inline on GitHub. You may find https://gifcap.dev helpful as a browser-based gif recording tool.
If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording (Developer: Toggle Screencast Mode in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue.
Happy coding!

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.
Happy Coding!


hotfix to mitmproxy missing start_server_playback() parameter added.

Hi Max,
I've just backported the fix in mitmproxy's start_server_playback() from PR [#439] to add the missing parameter (replay_ignore_payload_params) which is present in mitmdump but was missing in mitmproxy.
Regards
Marcelo

Good find. Thanks!


test: manifests testing on each PR

On each PR test that osbuild don't break the image generation by testing against the manifest-db that the produced image-infos are still the same as the one stored.
This replaces the old image_test imported from composer https://github.com/osbuild/osbuild-composer/blob/main/test/cases/image_tests.sh . This has for advantages:

we have up to date image-infos and manifests
we don't rely on diff to diff image-infos
we don't run on Openstack anymore on the CI.

Hmm, yest something is not quite right yet with that one. I can make everything in a bash script as you are proposing. Let's try out and see how it goes.

Personally I think that it would be easier to comprehend, but you'll see once you rework it. I'm also open to discussion, it just seemed that the single Bash script would be still reasonably short so it should not be too bad to merge all the scripts. Another reason to not do it would be that some of them are called from more than one place, but I didn't see this happening anywhere...

All looks good from my PoV, however there are some fishy lines in the test case log...
Such as https://gitlab.com/redhat/services/products/image-builder/ci/osbuild/-/jobs/2704738533#L2350
rhel_90-x86_64-edge_installer-boot FAIL: Invalid manifest: validation failed
rhel_90-x86_64-edge_installer_with_users-boot FAIL: Invalid manifest: validation failed
rhel_90-x86_64-edge_raw_image-boot FAIL: Invalid manifest: validation failed
rhel_90-x86_64-edge_simplified_installer-boot FAIL: Invalid manifest: validation failed

This is probably something to follow up on probably in the https://github.com/osbuild/manifest-db repo. I would expect the test case to fail in such case, because otherwise it ignores potential issues and reports success... In addition to that, it is not clear from the log, if manifests without corresponding image-info were successfully built and image-info was generated for them, but then not compared (because of the missing baseline) or that they were not built at all...

There exist manifests from composer that are invalid. We could decide to remove them from the DB and fix them because fixing them is another task.
Then you have cases where in the DB there is a manifest, but no image-info, this can be for several reasons. The first one is that they have not been regenerated yet and they are imported from composer. Once they will be, more comparison will occur.
In the log, it's quite clear the reason of the failure, you have:
FAIL: image-info mismatch when the image info do not mach
FAIL: invalid manifest when osbuild refused to parse the manifest
For a success it will wite on the console:
`Build & Comapre: SUCCESS" that means that the image-info was build and compared successfully.
Ignoring the builds with missing image-info is a corner case that needed to be taken into account.

I will split this PR in two parts, the first one with only the first commit that enables the testing against the manifest-db. Then I'll make a follow-up removing the tests coming from composer.

Yes that's bad news. I have SeLinux context difference between the image info I'm building here and the ones on the manifst-db's CI. I need to hunt that down..

So I think that, one of the reasons is that I've made a mistake in the Schutzfile of manifest-db. And centos-9 isn't linked to the right version of OSBuild. I have a PR to fix that: https://github.com/osbuild/manifest-db/pull/38
But this does not explain everything yet.


Graph widget: keep history of queries

Request: a way to quickly recall previously entered cypher queries.
Right now only the one most recent query is stored.

Yes, we definitely need this feature.


Kanban Board ?

Do you have Kanban Board for this project?
You can create on Github and if it is public then people can see the progress and new features.

Hey @jbr1989!
Not yet, but it's a good idea - we'll look to add some.
Originally, we were bumping the version number with some release notes, although most things are not around the core functionality, and are more about games coming in, and sometimes going back out as the devs tighten things up!
Also, bits and bobs of information in the weekly Patreon blog are all free to read or comment on.
Later today there will be a Blog Post on your contribution!


Etcd management does not clean up old/stopped docker containers

Etcdadm runs docker for awscli actions periodically.  It does not use --rm so these stopped containers grow over time and eventually will fill the root disk.  We just need to use --rm on the docker run to prevent this.  PR incoming.

Closing this as the fix #641 has been merged.
@jeremyd Thanks for the report and the fix 👍


Add Sendable conformances (except FileDescriptor)

This adds Sendable conformances to all public types, as well as the necessary internal types (SystemString and SystemChar).
Whether or not FileDescriptor should be Sendable is currently being discussed in #112.
This PR splits off FileDescriptors conformance to have the possibility to land the other conformances earlier.

@swift-ci please test

@lorentey is there any further availability dance needed for these?

I don't think so -- the Sendable conformance will be back deployable as it has no ABI impact!


add releases also in tar.xz tar.gz tar.zst

This is very unnecessary as .tar.gz and .zip files are provided by GitHub for those who would prefer not to use Lzip and for the other formats I would refer you to https://www.nongnu.org/lzip/xz_inadequate.html.


added shootingstar

I have added shootingstar.py to the hooman folder.

I have changed the code according to the provided requirements can you please review and merge it. PR-https://github.com/Abdur-rahmaanJ/hooman/pull/61/commits
Thanks,
Jagathi


add missing feature gate on ConfigExt for no-features build

Motivation

Fixes #1548
Solution
In kube/src/lib.rs:L197,

Before
pub mod prelude {
    #[allow(unreachable_pub)] pub use crate::client::ConfigExt as _;
    ...
}

After
pub mod prelude {
    #[cfg(feature = "client")]
    #[allow(unreachable_pub)]
    pub use crate::client::ConfigExt as _;
    ...
}

Re-committed to pass rust-fmt!

I'll do a patch release with this shortly.


Make API searchable

It's very hard to use the API without guidance. Please provide the full list of functions or a search option.

I found the 'file' link in documentation somewhat helpful...

Good idea, I'll add this to my TODO list for the webpage.
2016-01-20 13:49 GMT+01:00 Wouter Hager<EMAIL_ADDRESS>
I found the 'file' link in documentation somewhat helpful...
—
Reply to this email directly or view it on GitHub
https://github.com/cruppstahl/upscaledb/issues/68#issuecomment-173194869
.

@cruppstahl great! I should've written "I find it very hard to use the API". I'm fairly new to C.

I tried to provide many samples, a tutorial and also have sufficiently good documentation in the header file (at least for an open source project). I think the samples might be the best starting point. If C becomes too frustrating then feel free to drop me a mail (chris@crupp.de), I don't mind helping.


Add an empty pg_role table

Summary of the changes / Why this improves CrateDB
We currently don't have roles that map nicely to PostgreSQL roles, so
the table is empty for now.
Checklist

[x] Added an entry in CHANGES.txt for user facing changes
[x] Updated documentation & sql_features table for user facing changes
[x] Touched code is covered by tests
[x] CLA is signed
[x] This does not contain breaking changes, or if it does:

It is released within a major release
It is recorded in CHANGES.txt
It was marked as deprecated in an earlier release if possible
You've thought about the consequences and other components are adapted
(E.g. AdminUI)

changelog entry is missing

changelog entry is missing

Ah right, added one.


Expanding settings toggles them on

Hello,
I have noticed that if I expand a setting in the ui (such as "Variation Seed" or "Refiner", the setting is enabled, even if I have not set any values.  This causes an error with some settings that are not yet implemented, If I forget to turn them off (Scorers, for example).
Would it be possible to not have them auto-enable when just exanding them, but require actually activating the toggle?  Or maybe there is an option I'm just missing.
Thanks

+1
This is something I find bit annoying and difficult to undo.
I'm always itchy to expand and take a look what's inside a section, to make sure there is nothing I want to touch, then I collapse them, not realizing some of the features are toggled on automatically.
Possible to decouple expand/collapse and enable/disable toggle? Or put it as an option?

I've been unsure about how to make the UX for this quite right - minimal clicks to handle things while still being clear in behavior.
I've at this point just given up and gone ahead and disentangled them - it's now two separate controls.
Also if you have a closed-but-enabled group there's an extra bit of highlight to draw attention if you go looking for what's been accidentally activated.


Submit VCell <IP_ADDRESS>

id: vcell
version: <IP_ADDRESS>
specificationsUrl: https://github.com/virtualcell/vcell/releases/download/<IP_ADDRESS>/biosimulators.json
specificationsPatch:
version: <IP_ADDRESS>
image:
url: ghcr.io/virtualcell/biosimulators_vcell:<IP_ADDRESS>
digest: "sha256:10caecb4952a830c8306700dd0d9b7c21a99f51010edc47624ad722811c86741"
validateImage: true
commitSimulator: true

Thank you @jcschaff for your submission to the BioSimulators simulator validation/submission system!
The BioSimulators validator bot is validating the specifications of your simulator, validating your Docker image, and committing your simulator to the BioSimulators registry.
We will discuss any concerns with your submission in this issue.
A complete log of your simulator submission job will be available for 90 days here. The results of the validation of your tool will also be saved as a JSON file. A link to this file will be available for 90 days from the "Artifacts" section at the bottom of this page.

- You (@jcschaff) do not have permissions to update the specifications of Virtual Cell. Only the members of @biosimulators/VCell can update the specifications of Virtual Cell. Please contact the members of this group to request permissions to update Virtual Cell.


Update library download error

Describe the bug
When I click Update Library button in the plugin, I get an error message:

To Reproduce
Steps to reproduce the behavior:

Open the plugin
Click on Update Plugin
Error message appears
See error

Expected behavior
JLCPCB stock file is downloaded.
KiCad Version
Windows - KiCAD 6.0.11

Update your plugin version, since 2023.05.01 the parts db is generated differently!


official integration with Zod

Hi.
I love Kysely and use it in a bunch of projects. By accident I stumbled upon Drizzle which seems similar but not quite as mature. One nice thing that project has though is a quite nice integration with Zod: https://orm.drizzle.team/docs/zod
Are there any plans to introduce something like that in Kysely as well?

There's no plan to add zod integration. I think there are some users that use zod with kysely. It's worth asking around in discord.


use existing filament table query instead of generic model query

Now it uses the customised TableQuery instead of getting a generic query from the model, and respects aggregate columns, sorts, etc.
Further suggestion: Currently, it doesn't automatically add aggregate columns if you have counts or other aggregate methods on table columns but they're not defined in getTableQuery. We can tackle this in column related PRs.

I see. Do you think we should keep track of where columns are being generated from, and use this method only if it's fromTable?

And also add a method to customise the query regardless of the source of columns?

This was on my list as well. Offer a ´->modifyQuery()´ function which accepts a callback.

I see. Do you think we should keep track of where columns are being generated from, and use this method only if it's fromTable?

I'd love to just configure the right query when using ->fromTable() instead of storing that separately.

I'd love to just configure the right query when using ->fromTable() instead of storing that separately.

Please correct me if I'm wrong, but fromTable is not concerned with the query at all. It just gets the columns from the table schema.
So, my suggestion is we add a columnsSource attribute to withColumns trait, and store the source (table, form, model, custom) as a string or an enum.
Then in the query method, we check if the source is table and if so we use the getTableQuery instead of a fresh query from the model.

This was on my list as well. Offer a ->modifyQuery() function which accepts a callback.

We can add a query attribute to ExcelExport and store the custom query, and if it's not available fall back to the above logic.
What do you think?

@pxlrbt Any thoughts please?

I guess a $columnsSource property would be fine for me.

@pxlrbt this should do it.

How about this one @pxlrbt? You happy with this? This one shouldn't need much more to do.

Yes. This one is fine. I want to have a look at the rest next week and release them together.

Ah, great, thanks for the update.

@pxlrbt any updates this week?

I said this week, and it's only Tuesday. Please give me some time 😅

Sorry, didn't make it this week. Need to set up some testing Resources again.


update the google.golang.org/protobuf Apis

Signed-off-by: Nitin Goyal<EMAIL_ADDRESS>

Was there any particular requirement for this package's upgrade?

Yes there is a CVE https://bugzilla.redhat.com/show_bug.cgi?id=2268166


[SPARK-40421][PS] Make spearman correlation in DataFrame.corr support missing values and min_periods

What changes were proposed in this pull request?
refactor spearman  correlation in DataFrame.corr to:

support missing values;
add parameter min_periods;
enable arrow execution since no longer depend on VectorUDT;
support lazy evaluation;

Why are the changes needed?
to make its behavior same as Pandas
Does this PR introduce any user-facing change?
yes, API change, new parameter supported
How was this patch tested?
added UT

Merged into master, thanks @HyukjinKwon


istiod memory extremely high when status enabled

Bug description
Istiod seems to use very high memory when status is enabled:
  Warning  Evicted    14m                kubelet, gke-isito-status-dev2-default-pool-1c967e5c-00n2  The node was low on resource: memory. Container discovery was using 12699692Ki, which exceeds its request of 2Gi.

Here's the memory usage graph for a different instance of istiod:
 As you can see, the memory usage shoots up very quickl. At the same time there are tens of thousands of logs in that instance with the following message:
2020-11-10T21:40:57.082159Z	warn	status	Status reporter istiod-57b957694c-qhvmh has not been heard from since 2020-11-10 21:39:56.708601786 +0000 UTC m=+1529.711956004, deleting report.

[ ] Docs
[ ] Installation
[ ] Networking
[X] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
[ ] Upgrade
Expected behavior
istiod usage stays below requests (2Gi)
Steps to reproduce the bug
So far I've been able to reproduce this using a knative mako benchmark. I'm working on a more readily reproducible repro.
Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
❯ istioctl version --remote
client version: 1.7.2
control plane version: 1.8-alpha.75c9f6e71c76c73a3cf538d2311bd761f39728e5
data plane version: 1.8-alpha.75c9f6e71c76c73a3cf538d2311bd761f39728e5 (3 proxies)
❯ istioctl version --short
client version: 1.7.2
control plane version: 1.8-alpha.75c9f6e71c76c73a3cf538d2311bd761f39728e5
data plane version: 1.8-alpha.75c9f6e71c76c73a3cf538d2311bd761f39728e5 (3 proxies)

How was Istio installed?
TAG=$(curl https://storage.googleapis.com/istio-build/dev/1.8-dev)
wget https://storage.googleapis.com/istio-build/dev/$TAG/istioctl-$TAG-linux-amd64.tar.gz
tar -xvf istioctl-$TAG-linux-amd64.tar.gz
./istioctl install --set tag=$TAG --set hub=gcr.io/istio-testing --set values.pilot.env.PILOT_ENABLE_STATUS=true --set values.global.istiod.enableAnalysis=true

Environment where bug was observed (cloud vendor, OS, etc)
GKE + Knative

/cc JRBANCEL mitchconnors

/cc @JRBANCEL @therealmitchconnors

FYI, I don't have access to the linked picture. Please, include it directly inside the issue: see https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/file-attachments-on-issues-and-pull-requests

I eventually was able to repro this without mako.

Create a GKE cluster (3-node, 1.16.13-gke.401, e2-standard-4)
Install istio:

TAG=$(curl https://storage.googleapis.com/istio-build/dev/1.8-dev)
wget https://storage.googleapis.com/istio-build/dev/$TAG/istioctl-$TAG-linux-amd64.tar.gz
tar -xvf istioctl-$TAG-linux-amd64.tar.gz
./istioctl install --set tag=$TAG --set hub=gcr.io/istio-testing --set values.pilot.env.PILOT_ENABLE_STATUS=true --set values.global.istiod.enableAnalysis=true

Install knative following the official instructions for Istio: https://knative.dev/docs/install/any-kubernetes-cluster/
Create a large amount of knative services. I created one every 15 seconds and let it run for a few hours: watch -n 15 'kn service create "helloworld-go-$RANDOM" --image gcr.io/knative-samples/helloworld-go --env TARGET="Go Sample v1"'

This is basically what the mako benchmark I was using does; that benchmark is working fine on previous versions of Istio.

The kn command hangs indefinitely for me.  I can't get it to run even once.  What istio objects does the kn command create on the backend?  Perhaps we can reframe this repro in terms of istio objects, rather than knative?

The Knative Ingress creates two VirtualServices; one for ingress and one for mesh; I wasn't sure how to properly recreate the scenario outside of knative but I'd be happy to help. This is what the two VSes for a given route look like:
❯ k get vs -l serving.knative.dev/route=basic-zxc6c -o  yaml
apiVersion: v1
items:
- apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  metadata:
    annotations:
      networking.internal.knative.dev/rollout: '{"configurations":[{"configurationName":"basic-zxc6c","percent":100,"revisions":[{"revisionName":"basic-zxc6c-00001","percent":100}]}]}'
      networking.knative.dev/ingress.class: istio.ingress.networking.knative.dev
      serving.knative.dev/creator: system:serviceaccount:default:prober
      serving.knative.dev/lastModifier: system:serviceaccount:default:prober
    creationTimestamp: "2020-11-24T18:36:10Z"
    generation: 1
    labels:
      networking.internal.knative.dev/ingress: basic-zxc6c
      serving.knative.dev/route: basic-zxc6c
      serving.knative.dev/routeNamespace: default
    name: basic-zxc6c-ingress
    namespace: default
    ownerReferences:
    - apiVersion: networking.internal.knative.dev/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: Ingress
      name: basic-zxc6c
      uid: e9717d97-1caf-4574-a58e-7d15e9f0be40
    resourceVersion: "121842033"
    selfLink: /apis/networking.istio.io/v1beta1/namespaces/default/virtualservices/basic-zxc6c-ingress
    uid: 0b5eb29c-d59a-4f2a-aa15-25d2926cd415
  spec:
    gateways:
    - knative-serving/knative-ingress-gateway
    - knative-serving/knative-local-gateway
    hosts:
    - basic-zxc6c.default
    - basic-zxc6c.default.example.com
    - basic-zxc6c.default.svc
    - basic-zxc6c.default.svc.cluster.local
    http:
    - headers:
        request:
          set:
            K-Network-Hash: 1041653b491c48f59ee5fa1233652a17551addcc7fc44fa7ce64f704b7d8d4c9
      match:
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - knative-serving/knative-local-gateway
        headers:
          K-Network-Hash:
            exact: override
      - authority:
          prefix: basic-zxc6c.default.svc
        gateways:
        - knative-serving/knative-local-gateway
        headers:
          K-Network-Hash:
            exact: override
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - knative-serving/knative-local-gateway
        headers:
          K-Network-Hash:
            exact: override
      route:
      - destination:
          host: basic-zxc6c-00001.default.svc.cluster.local
          port:
            number: 80
        headers:
          request:
            set:
              Knative-Serving-Namespace: default
              Knative-Serving-Revision: basic-zxc6c-00001
        weight: 100
    - match:
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - knative-serving/knative-local-gateway
      - authority:
          prefix: basic-zxc6c.default.svc
        gateways:
        - knative-serving/knative-local-gateway
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - knative-serving/knative-local-gateway
      route:
      - destination:
          host: basic-zxc6c-00001.default.svc.cluster.local
          port:
            number: 80
        headers:
          request:
            set:
              Knative-Serving-Namespace: default
              Knative-Serving-Revision: basic-zxc6c-00001
        weight: 100
    - headers:
        request:
          set:
            K-Network-Hash: 1041653b491c48f59ee5fa1233652a17551addcc7fc44fa7ce64f704b7d8d4c9
      match:
      - authority:
          prefix: basic-zxc6c.default.example.com
        gateways:
        - knative-serving/knative-ingress-gateway
        headers:
          K-Network-Hash:
            exact: override
      route:
      - destination:
          host: basic-zxc6c-00001.default.svc.cluster.local
          port:
            number: 80
        headers:
          request:
            set:
              Knative-Serving-Namespace: default
              Knative-Serving-Revision: basic-zxc6c-00001
        weight: 100
    - match:
      - authority:
          prefix: basic-zxc6c.default.example.com
        gateways:
        - knative-serving/knative-ingress-gateway
      route:
      - destination:
          host: basic-zxc6c-00001.default.svc.cluster.local
          port:
            number: 80
        headers:
          request:
            set:
              Knative-Serving-Namespace: default
              Knative-Serving-Revision: basic-zxc6c-00001
        weight: 100
- apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  metadata:
    annotations:
      networking.internal.knative.dev/rollout: '{"configurations":[{"configurationName":"basic-zxc6c","percent":100,"revisions":[{"revisionName":"basic-zxc6c-00001","percent":100}]}]}'
      networking.knative.dev/ingress.class: istio.ingress.networking.knative.dev
      serving.knative.dev/creator: system:serviceaccount:default:prober
      serving.knative.dev/lastModifier: system:serviceaccount:default:prober
    creationTimestamp: "2020-11-24T18:36:10Z"
    generation: 1
    labels:
      networking.internal.knative.dev/ingress: basic-zxc6c
      serving.knative.dev/route: basic-zxc6c
      serving.knative.dev/routeNamespace: default
    name: basic-zxc6c-mesh
    namespace: default
    ownerReferences:
    - apiVersion: networking.internal.knative.dev/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: Ingress
      name: basic-zxc6c
      uid: e9717d97-1caf-4574-a58e-7d15e9f0be40
    resourceVersion: "121842030"
    selfLink: /apis/networking.istio.io/v1beta1/namespaces/default/virtualservices/basic-zxc6c-mesh
    uid: 38d047ac-886c-4168-8bd6-0bd6b106021e
  spec:
    gateways:
    - mesh
    hosts:
    - basic-zxc6c.default
    - basic-zxc6c.default.svc
    - basic-zxc6c.default.svc.cluster.local
    http:
    - headers:
        request:
          set:
            K-Network-Hash: 1041653b491c48f59ee5fa1233652a17551addcc7fc44fa7ce64f704b7d8d4c9
      match:
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - mesh
        headers:
          K-Network-Hash:
            exact: override
      - authority:
          prefix: basic-zxc6c.default.svc
        gateways:
        - mesh
        headers:
          K-Network-Hash:
            exact: override
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - mesh
        headers:
          K-Network-Hash:
            exact: override
      route:
      - destination:
          host: basic-zxc6c-00001.default.svc.cluster.local
          port:
            number: 80
        headers:
          request:
            set:
              Knative-Serving-Namespace: default
              Knative-Serving-Revision: basic-zxc6c-00001
        weight: 100
    - match:
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - mesh
      - authority:
          prefix: basic-zxc6c.default.svc
        gateways:
        - mesh
      - authority:
          prefix: basic-zxc6c.default
        gateways:
        - mesh
      route:
      - destination:
          host: basic-zxc6c-00001.default.svc.cluster.local
          port:
            number: 80
        headers:
          request:
            set:
              Knative-Serving-Namespace: default
              Knative-Serving-Revision: basic-zxc6c-00001
        weight: 100
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

Interestingly it looks like the Status field is gone despite it being enabled in the operator. Probably a symptom of the memory issue:
❯ k get IstioOperator -n istio-system installed-state -o=jsonpath={.spec.values.pilot.env.PILOT_ENABLE_STATUS}
true

Based on debug session with Artur, we were seeing too many goroutines on the stack due to k8s getting backed up.  This caused eviction, which, coupled with the failure of k8s garbage collection, meant that the new instance would hit stack problems faster than the last.  Rinse and repeat this cycle for a week and you have a very messed up cluster.
I am working on a patch that will have much more nuanced goroutine handling when k8s is slow to respond, and Artur is testing the patch in his environment now.


Ensure filters and date range changes trigger autorun if applicable

Migrated from GitLab: https://gitlab.com/meltano/meltano/-/issues/1796
Originally created by @derek-knox on 2020-02-25 16:10:49

When date ranges https://gitlab.com/meltano/meltano/-/merge_requests/1481 lands, update both QueryFilters and DateRangePicker (any anything else query related that isn't already) to properly trigger autoruns if the autorun flag is on

View 2 previous comments from the original issue on GitLab


Puppet 6.6: Cannot execute Bolt tasks as the node does not meet the minimum compatability requirements

Puppet AIO 6.6 renamed the task wrapper to execution wrapper: https://github.com/puppetlabs/pxp-agent/commit/eb3ab563a17cef32efed3e9a69d56a3e38194b94
This results in an error during task runs:
mco tasks run mcollective_agent_bolt_tasks::ping --message "Hello"
Cannot execute Bolt tasks as the node does not meet the minimum compatability requirements

As a test you can set data like this:
https://github.com/choria-io/mcollective-choria/blob/4fefe905163faae9745a2dcae977a98610e83947/module/choria/data/FreeBSD.yaml#L2-L3
This will both let you tell us if it still work and get you going quicker :)
wanna give it a go?

@ripienaar: thanks, I've did a workaround with a symlink. But this is obviously the better solution.
Set the path in puppet_aio/6.yaml and it's working fine now.

Hit into same issue with puppet 6 (agent 6.9.0, server 6.6.0). Fixed by adding wrapper path as below:
mcollective_choria::config:
  tasks.wrapper_path: /opt/puppetlabs/puppet/bin/execution_wrapper


Configure clang-tidy CI check

Cherry-pick of #1028 to the opengl-2 branch.

I killed redundant pipelines to not waste CPU.


Does it support model upgrade timely in a non-Kubernetes-native way?

Now, I want  to only use the MLServer in production env (i.e. in a non-Kubernetes-native way). But I not found releted introduction about the model upgrade scene.
The function like this in Tensorflow servering as follow:
https://www.tensorflow.org/tfx/serving/serving_advanced

Now imagine v1 and v2 of the model are dynamically generated at runtime, as new algorithms are being experimented with, or as the model is trained with a new data set. In a production environment, you may want to build a server that can support gradual rollout, in which v2 can be discovered, loaded, experimented, monitored, or reverted while serving v1. Alternatively, you may want to tear down v1 before bringing up v2. TensorFlow Serving supports both options -- while one is good for maintaining availability during the transition, the other is good for minimizing resource usage (e.g. RAM).

Thanks.

Hey @WiFeng ,
Sure thing.
If you want to keep a single instance of MLServer, you can use the dynamic load / unload endpoints to load new versions of your model (or new models altogether). You can find below a few resources to help you get started:

Example loading new models: https://mlserver.readthedocs.io/en/latest/examples/model-repository/README.html
The spec is aligned with Triton's, which you can find here: https://github.com/triton-inference-server/server/blob/main/docs/protocol/extension_model_repository.md

Thanks for you comment.


OpenAPI schema references wrong API version

Expected Behavior
OpenAPI schema matches the corresponding Tekton API version (e.g. v1, v1beta1, etc).
Actual Behavior
OpenAPI spec says v0.17.2
https://github.com/tektoncd/pipeline/blob/bffd16573facc997bea083f4426b59325cadd5ac/pkg/apis/pipeline/v1beta1/swagger.json#L6
https://github.com/tektoncd/pipeline/blob/bffd16573facc997bea083f4426b59325cadd5ac/pkg/apis/pipeline/v1/swagger.json#L6

Thanks @wlynch - if we keep swagger.json there it should be correct, thanks for pointing this out.
I don't think we use it anywhere today, what we use and publish to tekton.dev/docs is https://github.com/tektoncd/pipeline/blob/main/docs/pipeline-api.md. Still, we may want to provide it for our users.
As a side, we also have https://github.com/tektoncd/pipeline/blob/main/docs/api-spec.md which is outdated and not used anymore.

/cc @abayer I believe you did some work in this area


Microsoft.KeyVault/vaults/secrets (2018-02-14)

Describe the noise
Resource type
Microsoft.KeyVault/vaults/secrets
apiVersion
2018-02-14
Client
PowerShell
Relevant ARM Template code
{
	"type": "secrets",
	"name": "nepeters",
	"apiVersion": "2018-02-14",
	"dependsOn": [
		"[resourceId('Microsoft.KeyVault/vaults', 'nepeters')]"
	],
	"properties": {
		"value": "nepeters"
	}
}

Expected response
I expected no noise since the template has not been modified since the resources were deployed.
Current (noisy) response
Resource and property changes are indicated with these symbols:
  - Delete
  + Create
  ~ Modify
  = NoChange

The deployment will update the following scope:

Scope: /subscriptions/3762d87c-ddb8-425f-b2fc-29e5e859edaf/resourceGroups/whatif-kv3

  ~ Microsoft.KeyVault/vaults/nepeters/secrets/nepeters [2018-02-14]
    - location:         "eastus"
    - properties.attributes:

        created:<PHONE_NUMBER>
        enabled: true
        updated:<PHONE_NUMBER>

    + properties.value: "nepeters"

  = Microsoft.KeyVault/vaults/nepeters [2018-02-14]

Resource changes: 1 to modify, 1 no change.

Additional context
Parent resource Microsoft.KeyVault/vaults validates without issue or noise.

The fix for masking value and removing the read only properties created and updated has been committed to an internal repo and is awaiting deployment. We are still working for the fix for the default property enabled.

The fix for the read only properties has been deployed to all public regions. The fix for the enabled property has been committed to an internal repo and is awaiting deployment (should be live in all public regions by end of next week).

@neilpeterson, all the fixes should now be deployed to all public regions. Can you confirm it's working as expected for you?

We are closing the issue. Feel free to reopen it if you still see the noise.


The answer returns as in the attached image. Is it because I didn't name the file?

Given that I have followed all the steps from adding the AI model and select the uploaded file.
Uploading HBR.pdf…

While in the terminal

Yes unfortunately it doesn't understand meta question currently. Meaning it has no conception of file, it only knows the content of the files. We will incorporate the ability to understand meta questions in future updates.


Removing sync mode

After searching for an alternative solution, we've decided to remove synchronous updating (sync mode) from Vue Test Utils.
tl;dr
We will remove sync mode in the next beta version. Test code will change from this:
it('render text', (done) => {
    const wrapper = mount(TestComponent)
    wrapper.trigger('click')
    wrapper.text().toContain('some text')
})

To this:
it('render text', async () => {
    const wrapper = mount(TestComponent)
    wrapper.trigger('click')
    await Vue.nextTick()
    wrapper.text().toContain('some text')
})

Background
By default, Vue batches updates to run asynchronously (on the next "tick"). This is to prevent unnecessary DOM re-renders, and watcher computations (see the docs for more details).
When we started Vue Test Utils, we decided to make updates run synchronously. The reasoning was that synchronous tests are easier to write, and have improved error handling.
For context, the decision was made just after async/await had been released in node 7.6, so asynchronous tests often looked like this:
it('render text', (done) => {
    const wrapper = mount(TestComponent)
    wrapper.trigger('click')
    Vue.nextTick(() => {
        wrapper.text().toContain('some text')
        wrapper.trigger('click')
        Vue.nextTick(() => {
            wrapper.text().toContain('some different text')
            done()
        })
    })
})

Because of this decision Vue Test Utils runs updates synchronously by default. That was a mistake.
Why?
Sync mode causes bugs that don't exist when Vue runs normally. This is frustrating for users, and bad functionality for a testing framework that's intended to give you confidence that your code will work in production.
We went through three different approaches to implement sync mode. Each had problems. The final attempt was to reimplement synchronous updates in Vue core, but there were still bugs caused by synchronous updates.
Solution
The solution is to remove sync mode entirely from Vue Test Utils and rely on the user explicitly waiting for updates to be applied:
it('render text', async () => {
    const wrapper = mount(TestComponent)

    wrapper.trigger('click')
    await Vue.nextTick()

    wrapper.text().toContain('some text')

    wrapper.trigger('click')
    await Vue.nextTick()
    wrapper.text().toContain('some different text')
})

This will be a big change for many test suites. You have two choices:

Refactor tests to run asynchrnously
Keep Vue Test Utils locked at beta.28

We recommend that you update your tests in order to benefit from future features of Vue Test Utils. This will also make your tests more robust since Vue will perform updates in the same way as it does in production.
To make the migration as smooth as possible, so we'll provide documentation and guides to help you write tests asynchronously with Vue.nextTick.
Finally, I'm sorry for the work this change will require. I was a large part of the driving force for running in sync mode by default, and I underestimated the problems that it would cause.
Going forward, this will improve the stability of Vue Test Utils, and we'll be able to release a stable API as v1.

Thanks for the explanation and better now than after v1.
Just as a thought, wouldn't recommending something like this be better to make it also work when localVue is used:
await wrapper.vm.$nextTick()

Or is that irrelevant?

You can use either, they're the same function

As much as I liked it, thank you for sharing the detailed explanation and changing it in the beta rather than causing more refactoring work later. Also thank you for creating an issue prior to changing it! ❤

Hey @eddyerburgh! I could be talking complete nonsense, but would it be possible to await that next tick in the wrapper.trigger to keep the test code cleaner?
i.e. instead of
wrapper.trigger('click');
await Vue.nextTick();

do
await wrapper.trigger('click');

Yes that's a good idea, I was thinking the same thing 👍

can you please adjust the release https://github.com/vuejs/vue-test-utils/releases/tag/v1.0.0-beta.29 and place this under breaking changes?

@sagalbot @eddyerburgh I don't think this was included in v1.0.0-beta.29: https://github.com/vuejs/vue-test-utils/compare/v1.0.0-beta.29...dev
https://github.com/vuejs/vue-test-utils/pull/1141 was merged on 9th of February while v1.0.0-beta.29 was already tagged on the 2nd.

await wrapper.trigger('click');

I feel like that's conflating two things: triggering the event, and flushing to the DOM. What if a tester wanted to do more than just trigger a click event before the next tick?
I'd suggest instead either sticking with the original trigger/await nextTick pattern, or adding a new method, something like:
await wrapper.triggerAndNextTick('click');

... but with a less terrible name!

Fair point. I would imagine there could be some interesting points of inspiration to take from the async utilities/patterns of dom-testing-library that is popular with the React flavour of react-testing-library. https://testing-library.com/docs/api-async

What a change; this also broke wrapper.setProps({})
So before:
wrapper.setProps({
   prop: someValue,
});
expect(wrapper.vm.prop).toEqual(someValue);

would trigger changes (dom, watchers, computed, etc) in the component, but now you have to do
wrapper.setProps({
   prop: someValue,
});

await wrapper.vm.$nextTick();
expect(wrapper.vm.prop).toEqual(someValue);

Imo this change should be reflected in the docs asap!

Is this change in 1.0.0-beta.29? I'm fighting #1163 and trying to figure out the best way forward.

 I had to update the test-utils, and now I'm getting all sorts of errors on tests that where succeeding before. There is something really wrong with the DOM updates when ran with test-utils. Are there other things I can check to resolve these issues?

What a mess, release notes are telling lies then....

@dietergeerts I don't see this mentioned in the release notes. 🤔

Are there other things I can check to resolve these issues?

It probably helps to create a new issue with reproduction steps and the error message.

https://github.com/vuejs/vue-test-utils/releases/tag/v1.0.0-beta.29

Use Vue async mode, this has caused bugs and will be reverted (see #1137)

@eddyerburgh I agree with @dietergeerts that this entry in the release notes could have some clarification. It reads as if Use Vue async mode is handled by this issue while it is actually https://github.com/vuejs/vue-test-utils/pull/1062.

Just to keep you guys up-to-date: When reverting to beta.28, all my problems are resolved.
The issue I had was that certain test cases where failing because other test cases where included in the run, for no apparent reason. it's very strange. We always use createLocalVue to have each test really isolated.

Bad news fellows..
Today I updated vue, vue-template-compiler and @vue/test-utils tills the latest versions and got into situation where bound values (declared data property) within templates didn't update. Did anyone stumble upon with this?

await wrapper.trigger('click');

I feel like that's conflating two things: triggering the event, and flushing to the DOM. What if a tester wanted to do more than just trigger a click event before the next tick?

Would they not still be able to do that?
trigger('click')
doSomethingElse()
await localVue.nextTick()

If they don't await the trigger, then everything should work as before, no?

@vvanpo They would still be able to do that, sure. But conceptually, it's mixing two different concepts. The trigger method, I would argue, is simply responsible for dispatching events, and (probably) should know nothing about the task queue/tick mechanism. IMO, the two concepts should remain separate, for simplicity.

Are there any updates on this? We just had a lot of troubles when testing with Vuetify and finally got the tests stable and independently after disabling the sync mode. This could have saved us a lot of effort...

This is quite confusing now - when do we need to do await? For every DOM update? I'm having a bit of trouble getting my head around what this change means - see here for an example of some confusion. When using vue-router, and doing router.push, this will change the DOM (obviously). So should I be doing await router.push()? Or is this a race condition (as the OP of that issue talks about).

Is there a time frame for when we can expect the docs to be updated to reflect this change? In the meantime, does anyone know of any good tutorials that will help us learn how to use async mode correctly?

Sync mode has been released in beta.30

With beta.30 I'm having difficultly  testing the <transition> afterLeave hook,  All other hooks I can test, but for some reason can't get the afterLeave handler tested (i.e. we emit an event in the afterLeave hook, and no matter how many nextTick's we wait, that emitted event never appears as emitted (expect(wrapper.emitted('event-after-leave')).toBeDefined())

We pinned to beta.29 to resolve until we could await all the right places. Totally appreciate the lib and contributions, and the removal of "sync mode" is a better design decision, TBH. A major version bump for this BC-breaking change would have been nicer.
We got hit with the<EMAIL_ADDRESS>bug at the same time, so it was a Fun Time ™

Trusting your users to be able to understand async testing and recommending tools like https://www.npmjs.com/package/wait-for-expect would probably go a long way to avoid some of the headaches caused here.

@eddyerburgh you say "sync mode has been released" - do you mean removed, reenabled, or something else? I was under the impression that sync mode was removed as of beta.29

@stuheiss sync mode was removed in v1.0.0-beta.30 (it's still available in v1.0.0-beta.29) and the docs have been updated.
@eddyerburgh should this issue be closed now?

With beta.30 I'm having difficultly testing the <transition> afterLeave hook, All other hooks I can test, but for some reason can't get the afterLeave handler tested (i.e. we emit an event in the afterLeave hook, and no matter how many nextTick's we wait, that emitted event never appears as emitted (expect(wrapper.emitted('event-after-leave')).toBeDefined()). All other transition hook events fire ok (beforeEnter, afterEnter, etc) Note: we had the transition stub set to false in order to test the hooks previously)
Not sure if this is related to the sync changes or not.

How do you stub transition in your tests?

@xiaosu we were disabling the beta.29 transition stub (to use the real transition):
const wrapper = mount(SomeComponent, {
  stubs: {
    transition: false
  }
})

But now that transition is not subbed at all, it should just work as before, but the after-* hooks no longer run.

Is there a way to pin docs online at a certain version?
The reason I ask is that when using Vuetify, tests can blow up when running in sync mode usually with an error like TypeError: Cannot read property '$scopedSlots' of undefined. This is because when testing form validation DOM nodes are inserted/removed depending on the validation outcome. When testing synchronously some variable is undefined, whereas by waiting for the nextTick the DOM batch is processed and all is well. For those having the same issue with Vuetify see https://github.com/vuetifyjs/vuetify/issues/9151 or https://github.com/vuetifyjs/vuetify/issues/9820.
However when reading through the docs of @vue/test-utils I couldn't find any reference to sync yet my repo was still at beta.29. This was confusing for me when different forums posts on how to fix my tests from blowing up was to set a mounting option that didn't exist according to the docs. It took more googling to find this issue.
I support the idea of removing sync updates because it goes against the grain of Vue, and Node JS in general, so I'm glad that it's gone. However I think it would be helpful for people to be able to view the docs online for the version of the library they're using. Especially for breaking changes like this.

The only way I see is to point to that version on Netlify.


Add TypeScript typings

Been using these typings in a commercial project for some years now, haven't had any problems with them 👍

ping @bengourley ☺

Seems like the package is no longer maintained.

@bengourley I'd be happy to jump on as a maintainer if you no longer have time with this :)

I created my own package for this, fixes all the issues in this package + typescript + few utils functions too.
https://github.com/sirajalam049/currency-code-symbol-map

@LinusU thanks for the contribution!
I added a minor change, because there was a warning:
Top-level declarations in .d.ts files must start with either a 'declare' or 'export' modifier.

Merging it now and will publish it soon.

@LinusU thanks for the contribution!
I added a minor change, because there was a warning:
Top-level declarations in .d.ts files must start with either a 'declare' or 'export' modifier.

Merging it now and will publish it soon.

Released in v5.0.0

Released in v5.0.0


Handle SIGTERM properly

Signed-off-by: Li Yi<EMAIL_ADDRESS>Fix #182
Tested in Mac/Linux
$ cargo run -- -c examples/modules.toml
    Finished dev [unoptimized + debuginfo] target(s) in 1.03s
     Running `target/debug/wagi -c examples/modules.toml`
No log_dir specified, using temporary directory /var/folders/jh/x0hxxwzn7j7fhmlh3q3k17x40000gp/T/.tmp9evE6D for logs
Ready: serving on http://<IP_ADDRESS>:3000

In the separated terminal
$ kill -15 PROCESS_ID

Sorry for the lack of reply - I've been away.  Thanks for this - I'll take a look!


Using Gradient Accumulation

Hello Thanks for your great work.
I need to use gradient accumulation on batches due to RAM constraints. The training loop involves iterating over two modalities. I am concerned about the implications of using gradient accumulation in this scenario. Is it possible and recommended to use gradient accumulation with multiple modalities in an iterator?
 with torch.cuda.amp.autocast(enabled=config.fp16):
            loss_dict = model(image, text)
            loss = sum(loss_dict.values()) / config.accumulate_grad_batches
        scaler.scale(loss).backward()
        accumulated_batches += 1
        if accumulated_batches % config.accumulate_grad_batches == 0:
            if config.optimizer.max_grad_norm > 0:
                scaler.unscale_(optimizer)
                torch.nn.utils.clip_grad_norm_(model.parameters(), config.optimizer.max_grad_norm)

            scaler.step(optimizer)
            scaler.update()
            optimizer.zero_grad()  # Reset gradients only after optimizer step
            scheduler.step()  # Step the scheduler as per your original strategy
            accumulated_batches = 0

Good question! Can you try to use a small batch? From my previous experience, the results are similar.
Besides, if you want to use gradient accumulation, I think the multiple modalities in an iterator will be a good baseline, but some papers argue that single modalities in an iterator will be better. If you want to realize it, a simple strategy is to split the input data manually.

Thank you for your response. I have another question regarding the extra_num_query_tokens. Specifically, I'm interested in understanding if you've tested the scenario where this parameter is set to 0. How does this compression of visual tokens affect performance?

There is an ablation in our paper. And 0 extra query lead to poorer performance on MVBench

Hi, we will close this issue.
Feel free to contact us if you have other questions.


F#

Hi there :)
Since I think that F# is fully C# compatible and due to the fact that this implementation works via types, is it likely that F# is fully supported.
It would be nice to have some examples since this is surely interesting for a lot of devs.

It will probably be compatible since C# and F# compile to the same intermediate language. F# isn't familiar ground for me, but you could elaborate on the docs with a pull request if you like.

I am currently not in the community involved anymore, while F# is a superset of C#, so it is probably very simple to transfer the implementation. Tons of thanks!


DocumentJS error in windows

c:\Users\justi\dev\place-my-order\node_modules\documentjs\node_modules\q\q.js:126
                    throw e;
                    ^
 Error: EEXIST: file already exists, mkdir 'c:\Users\justi\dev\place-my-order\node_modules\documentjs\site\static\build\99914b932bd37a50b983c5e7c90ae93b'

weirdly this does not happen if I call node_modules\.bin\documentjs

This was fixed a while back, the guides fully work on Windows (including running DocumentJS).


Cursor disappears when opening new split window for maximized vim

Cursor highlighting disappears when I open split windows in a maximized vim (gvim) session. See the below screenshots. In the first screenshot, the cursor is highlighted as a dark grey filled rectangle. In the second screenshot, I've issued a vertical split. The right split is the current split, and the cursor is no longer highlighted.
The problem only occurs for vertically maximized vim windows.

does this happen without airline?

I just tried with a minimal working example, where this does not happen. So it seems there is a conflict between vim-airline and some other plugin or functionality I'm using. I'll look into this problem myself.

@lervag Is your bug the same as https://github.com/vim/vim/issues/480? did you manage to fix it?
I use set guioptions-=L as a workaround.


Autodetect list of available language

This would avoid to maintain the list manually.

Should probably come from https://phet.colorado.edu/en/simulations/translated

@midik This would fix #38 as well, isn't it?

This would fix #38 as well, isn't it?
yes, I think so.


Finalize CommitPacketV2 function

Once we have finalized the structure for PacketV2,  we need to investigate what the final CommitPacketV2 function should do, up until now we have done something similar to what was done with Packet(V1).

Will be closed by https://github.com/cosmos/ibc-go/pull/7544


Containerize

Added dockerfile to do the below
Java 8 based on eclipse-temurin
Spark 2.4.8
Cassandra-Data-Migrator packaged jar
DSBulk
CQLSH

Fixes #43


Not working in latest streamlit version

Environment
Python version: 3.11.6
Streamlit version: 1.28.0
Streamlit-modal version: I have tried both with main branch and 0.1.0 PyPI versions.
What happens?
Even when using the example code in the README.md:
import streamlit as st
from streamlit_modal import Modal

import streamlit.components.v1 as components

modal = Modal(
    "Demo Modal",
    key="demo-modal",

    # Optional
    padding=20,    # default value
    max_width=744  # default value
)
open_modal = st.button("Open")
if open_modal:
    modal.open()

if modal.is_open():
    with modal.container():
        st.write("Text goes here")

        html_string = '''

HTML string in RED

        '''
        components.html(html_string)

        st.write("Some fancy text")
        value = st.checkbox("Check me")
        st.write(f"Checkbox checked: {value}")

The modal does not open and gets stuck in some infinite loop, reaching python recursion limit and breaking.
I don't know if this has to do with the experimental_rerun deprecation…
Are you having the same issue?
Thanks.

I merged a fix regarding the experimental_rerun a couple of hours ago. Are you sure you tested against the latest main branch?

Yea pretty sure, first I was getting a deprecation warning, then the warning was gone but modals did not work.
Again i think it has to do with last streamlit version 1.28, 1.27 is working fine :O

I just tested it with current main branch, streamlit 1.28 and python 3.10 and it works fine. Do you see any errors?

No, it just enters in an infinite loop of some kind until it reaches recursion limit.
I do not have time to investigate further and with streamlit 1.27 I am fine, if in the future the issue persists I will reopen the issue.
Thanks :)


TK8 and OpenStack

Kazimierz Sroka wrote to me:
I'm trying to set up kubernetes cluster using https://github.com/kubernauts/tk8 at v0.4.3.
I configure everything properly and after running tk8 cluster openstack --create terraform complete successfully but I can not ssh into bastion.
I am sure I am using correct key (there's only one on the openstack and when I create a new VM manually I can ssh properly). I am getting Permission denied when trying with root, centos, ubuntu or whatever i put in cluster.tfvars.
Could you help me debug this or point to someone who can?
I noticed that openstack folder was removed from master branch, why is that?

I'd like to add that tk8 cluster openstack --install fails with the same error, ansible is not able to ssh into VMs.

We could use infraly's implementation (pure kubeadm with ansible only):
https://github.com/infraly/k8s-on-openstack

OpenStack support is no more in our focus, perhaps later with Terraform Rancher Provider (?).


prometheus/exporters/collectd: fixed authFile

Motivation for this change
The option authFile was present before, but it was apparently ignored
Things done

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

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Notify maintainers

@exyi Still interested in getting this merged? If you don't respond or aren't interested anymore I will just close it in a few weeks.

Sorry, I forgot about this. I applied the suggested changes, but I don't know how to test it. If this isn't something you'd want, feel free to close it, I don't really care if it gets merged or not.

There is no point in doing this, if you don't test it.

Ok, but the bug should get fixed somehow  #245364


no project file

In the repos readme its said that there is a project inside the game folder.
But there is no godot project file.
Please add the project file.
Thank you.

This project uses Godot 1.1, so the project file is called engine.cfg.


Handle object files with .*.o patterns when running Linker Script Generator (IDFGH-11962)

Currently, only .o, .*.obj and .obj patterns are taken into account. It would be great to have object files with the .*.o extension pattern (e.g. file.cpp.o) also processed as they're quite widespread in third-party integrations.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

sha=bd56ca48be81763872d1562822b94843eed12fdc

@valeros We plan to merge this, thanks for the fix! After merging this internally, it'll appear on master, soon.


How to get current offset, consumer group id and running log of one task?

@artiship You can get the current offset in Lenses or use the Kafka command line tools and the log of Connect will go wherever you configured the log4j.properties


"list" command gives me a "vdf: unknown pack type 101" error

Hello. I have not been using protonutils for a while and just downloaded the latest version. Upon running list, the program gives me the following error: vdf: unknown pack type 101. Any thoughts? I manually edited ~/.steam/steam/config/config.vdf recently, deleting some unused compatibility tool mappings (entries under "CompatToolMapping"), but that can not be it…

PS: Older versions produce the error as well, though written differently.

protonutils is reading different VDF files on list. Would you send the following files for me to debug with, please? (You can send them to<EMAIL_ADDRESS>
~/.local/share/Steam/config/loginusers.vdf
~/.local/share/Steam/appcache/appinfo.vdf
~/.local/share/Steam/config/config.vdf
~/.local/share/Steam/steamapps/libraryfolders.vdf
~/.local/share/Steam/userdata/1227399972/config/localconfig.vdf
~/.local/share/Steam/userdata/1227399972/config/shortcuts.vdf

One command that creates a tarball containing all those files is:
tar cf ~/protonutils-debug.tar ~/.local/share/Steam/config/loginusers.vdf ~/.local/share/Steam/appcache/appinfo.vdf ~/.local/share/Steam/config/config.vdf ~/.local/share/Steam/steamapps/libraryfolders.vdf ~/.local/share/Steam/userdata/*/config/localconfig.vdf ~/.local/share/Steam/userdata/*/config/shortcuts.vdf

~/protonutils-debug.tar would contain all relevant files, then.
Thanks for reporting and helping to debug this!

@crlmahlberg, do you have the chance to send debug info, please? If you are hesitant to share the files, I can also generate a binary with more debug output but that's probably taking more iterations.

Hi @nning, thanks for your answer. I'm a bit hesitant when it comes to sharing data TBH, but I would be happy with a binary that has a more verbose debug output. Thanks for your efforts!

I prepared a branch with added debug logging (see #29).
CI generated a development binary with that feature:
https://github.com/nning/protonutils/suites/6695814930/artifacts/254295941
Run it like DEBUG=1 ./protonutils list, then it should output the steps it takes and the last few lines should show what your problem is connected to.


Use 3 arguments listxattr() on non-macOS Unix

In order to support *BSD especially.
Fixes #157
I love erdtree so much, it's quite fast and readable!!

@iquiw Thanks!
The patch fixes the build.


scootapi/setup: framework to setup a cloud scoot

scootapi/setup makes it easy to setup a cloud scoot. This framework should (eventually) replace swarmtest. It makes it easy to build a binary with an interface like:
bin/setup-cloud-scoot --strategy local.local
bin/setup-cloud-scoot --strategy local.local --workers 3
bin/setup-cloud-scoot --strategy local.local --workers 3 run bin/scootapi run_smoke_test
I'd recommend looking at (in this order, and with annotations):
setup.go (entry point to library)
cmds.go (low-level plumbing used throughout to run commands)
sched.go (strategy to start a local scheduler)
workers.go (strategies for a local scheduler to talk to workers, either in-memory or running locally)
builder.go (how to build binaries)
ports.go (how to wait for a server to start, to prevent race conditions)
main.go (constructing the objects and then handing off control to setup.go)
This also required changing some other stuff:

scheduler: change how we read config
workerserver: take addresses instead of ports
cluster/local: change how we parse the output from ps

https://phabricator.twitter.biz/D9233

I'm not sure I'm understanding the changes correctly and this appears to be a significant chunk of functionality, so I started a confluence page to document (my understanding of) the design. (https://confluence.twitter.biz/display/EE/Cloud+Scoot+Test+Harness) to document the design (as I understand it).  I've put my comments on the bottom of that page.  Also, am I able to see the github repo/branch that has all the changes? (this would be easier than looking at diffs)
I like the refactoring's direction.

Keep in mind that we will be discussing the virtues of the original code vs the new code tomorrow at the tech meeting. I like the direction of the new code as well but I'm of the opinion that there is such a thing as too much modularization. Ultimately I want whatever changes the group wants.
On Wed, Oct 5, 2016 at 7:50 AM -0700, "Jeanette Bruno"<EMAIL_ADDRESS>wrote:
I'm not sure I'm understanding the changes correctly and this appears to be a significant chunk of functionality, so I started a confluence page to document (my understanding of) the design. (https://confluence.twitter.biz/display/EE/Cloud+Scoot+Test+Harness) to document the design (as I understand it).  I've put my comments on the bottom of that page.  Also, am I able to see the github repo/branch that has all the changes? (this would be easier than looking at diffs)
I like the refactoring's direction.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Current coverage is 70.27% (diff: 7.14%)

Merging #130 into master will decrease coverage by 0.24%

@@             master       #130   diff @@
==========================================
  Files            60         60
  Lines          2551       2560     +9
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           1799       1799
- Misses          660        669     +9
  Partials         92         92

Powered by Codecov. Last update cf32dd3...0227fd6

"move the setup code into the swarmtest folder / package to make it more clear that this is all code related only to this tool/script"
Do we want to keep the swarmtest name? I think we'll use this just at the start of the day for "let me talk to prod scoot", so I thought we'd move away from that. That's why I made the new package.

(also, I agree with the weirdness of putting setup for workers in scootapi). Were you going to address that or would that involve scattering setup in multiple places?

Is this waiting on anything?


Submitted assignments still showing active

Several ninjas (refining tab only), have reported that after submitting an assignment, they still see the assignments as 'active' in the queue. Attached is one example (IDs 917 and 1409). Assignments cannot get pushed to the review stage as a result.

Adding more examples here:

Fixed by fixing timestamp comparisons. Closing.


No such file or directory

ERROR in ENOENT: no such file or directory, scandir 'C:\users\name\react-form-builder\node_modules\node-sass\vendor'
@ ./css/application.css.scss 4:14-122 13:2-17:4 14:20-128
I am also getting the Error<EMAIL_ADDRESS>install: node-gyp rebuild error which I cant solve on npm install - so maybe related.

git clone the repo
npm install
npm install missing dependancies
npm run

npm rebuild node-sass does not fix the issue -  ERROR in ENOENT: no such file or directory, scandir 'C:\users\name\react-form-builder\node_modules\node-sass\vendor'
@ ./css/application.css.scss 4:14-122 13:2-17:4 14:20-128

npm rebuild node-sass did actually solve issue
//Open powershell as Admin
npm install --global --production windows-build-tools
//download repo
git clone git@github.com:blackjk3/react-form-builder.git
//cd into repo & install node-gyp locally
npm install --global node-gyp
//install dependencies
npm install
//May need to rebuild sass after install
npm rebuild node-sass
//start http://localhost:8080/
npm start

Closing through inactivity


Clipping still possible when pass though blocks is disabled

When pass through blocks is disabled, despite player can not move through blocks, clipping still possible, because restriction applied too late, so player could move slightly into the block, that is enough for blocks to become transparent.

I really don't know what to do about this issue. My testing does not bring up this issue because I run my test server on my computer giving me 0 ping. I have put the priority to high if that could help. If you have any ideas feel free to reach out and let me know.

I've Made some research and figured out that besides wall-clipping, that is reverted by plugin (when player forced back after trying to clip into wall) there is another problem - vanilla spectator has no collision model, so when you come close to the wall, even not trying to clip into - you can see through when watching down. This looks very similar to vanilla survival sand-bug (may be still exist? don't know). Another problem is that coordinates are at feet, but camera - 1 block higher, so coordinates must be corrected bu +1, now you can just simply fly into roof with no problem and plugin think it is legal.
For now the only Idea I have - is to check some sort of a circle around the player instead of real coordinates to hold them out of the wall.

I changed the eye level so that should help with some of the clipping

Currently working on fix. Already fixed walls, but have some trouble with top block. It still clipping, cause when you move up - you move at about 0.4 per event (as my F3 says - it jump between .005 and .4).
You could look at my fork current state in clipping branch.

I changed the eye level so that should help with some of the clipping

Could you push your comment, so I can use it in my fix, please?

Going to close this issue due to most of it being fixed and inactivity.


issue in starting wg service

its my wg-dashboard.service :
[Unit]
After=netword.service
[Service]
WorkingDirectory=/root/wgdashboard/src
ExecStart=/usr/bin/python3 /root/wgdashboard/src/dashboard.py
Restart=always
StartLimitInterval=1
[Install]
WantedBy=default.target
whats wrong with it?

Hi @Salarsdg , what would happen if you run this directly in your terminal?
/usr/bin/python3 /root/wgdashboard/src/dashboard.py

I have the same thing, I have the latest version of WGDashboard and if I reboot or shutdown and start the machine it starts WDDashboard but I can't start the WG server and I have to manually enter the interface to start it.

I had the same problem.
What I discovered was the following:

the old version was in /wgdashboard/src
the new (updated) version was in /WGDasboard/src
This also seems to be the case in your screenshot: the first line references WGDashboard/src
But your config file references wgdashboard/src --> this is a different folder!
--> Update the file wg-dashboard.service so it references the correct folder WGDashboard/src

@donaldzou in my case if I restart the machine wgdashboard starts without problem but my vpn profile in my case wg0sv does not start so if I am in remote and I restart the server I can not connect, I have to be in my network locally, enter wgdashboard and start it manually as you see in the image.

@donaldzou in my case if I restart the machine wgdashboard starts without problem but my vpn profile in my case wg0sv does not start so if I am in remote and I restart the server I can not connect, I have to be in my network locally, enter wgdashboard and start it manually as you see in the image.

With version 4.1 You can enable auto-start. Can you try that?


--cli not working

Just tried to use "yo nm --cli" as my first foray here, but no cli.js appears...
I'm a bit of a node/npm/yeoman noob here, but can't see that I am doing anything wrong...
I believe I am using the latest, fresh versions of everything, recently installed.
What gives?

Quick service. Thanks! Will try again.


ExtendedFingerDetector doesn’t work with OpenXR

Open XR Leap Provider and ExtendedFingerDetector.cs with the Unity plugin v5.11.0.
The issue is that ExtendedFingerDetector doesn't seem to work with the OpenXR provider while it does with the Leap XR Service Provider. All fingers are detected as extended whatever their position.
To reproduce

Open the example scene Capsule Hands (OpenXR).
Add Extended Finger Detector script to any hand Capsule Hand Left and/or Capsule Hand Right.
Check detector's activation state with Gizmos or On Activate() and On Deactivate() events.

Unfortunately the OpenXRProvider does not support a few features that are provided through the LeapC interface.
The OpenXR Leap Provider does not currently support the following hand properties (and will return fixed values):
•	Hand and Finger: FrameId
•	Hand: Confidence
•	Hand: GrabAngle
•	Hand and Finger: Id & HandId will always return 0 and 1 for the left and right hand respectively
•	Hand and Finger: TimeVisible
•	Finger: IsExtended

This is now being worked on

@Ronan-V this (and a few other OpenXR missing features) should be going through QA next week and will hopefully make it into 5.13.0.


Update node-sass (to work correctly with Node > 6.5.0)

Also update some other outdated deps.
Tested via npm link on couple of my projects

@jtangelder @jhnns sorry for mentioning you guys directly but this stops everyone to upgrade to node > 6.5.x so it may be a crucial issue.

The caret (^) symbol already does this. https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004

Yes but npm install won't update dependancies. So if you use nvm things will break.

This is also an issue when you use Nexus, Artifactory, etc. because they will cache deps and when you run `npm i' cached old deps will be installed.

Sorry, I don't understand this. Why can't people use node > 6.5 with the sass-loader? In fact, I'm using node 7.1.0 and everything is working fine (I've also tested it with node 6.9.0).
Besides that: Changing the peerDependencies is an unnecessary breaking change imho.

Ok. we'll just clean Nexus' repo for now


pull request for e2e test at 01/18/2017 17:56:15

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


[KARAF-6379] Updating CXF + Commons IO

I would appreciate to review such kind of change. I'm preparing a new major Cave release and this kind of change might have an impact. Thanks !

@jbonofre ok, sorry for this...