Font size is stuck on 11

Not sure if this is a bug or a feature (I think it's a bug), but my font size is stuck on 11.
Furthermore, attempting to change the font settings in any other way is equally as fruitless a task.
I attempted to make the change directly via inputs in the font menu (cmd-+, etc) and also tried via the Show Fonts dialog window.
Am I perhaps missing a way to activate the ability to make these edits?
I'm finding the app really fantastic otherwise. Keep up the amazing work!

Hi,
Thank you for the feedback.
Did you try the settings view? Bottom-left of the sidebar.
You can change the font size there.

It worked! That did the trick and the UI for it is nice too.
Good to know there's a workaround 😊


Unable to copy file into remote server, getting error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Hello!

Vote on this issue by adding a 👍 reaction
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already)

Issue details
I have created a VM instance in GCP, but unable to copy file into remote server. Getting the following error
error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Pulumi console log:
    Type                       Name                   Operation
+   gcp:serviceAccount:Account my-service-account     created
+   gcp:serviceAccount:Key     my-service-key         created
+   gcp:compute:Address        my-address             created
+   gcp:compute:Instance       instance               created
+   pulumi:pulumi:Stack        android-gcp-pulumi-dev created

Diagnostics:

madhank93/android-gcp-pulumi/dev (pulumi:pulumi:Stack)
error: update failed

docker-install-file (command:remote:CopyFile)
error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Code snippet:
import * as gcp from "@pulumi/gcp";
import { remote, types } from "@pulumi/command";
import { Config } from "@pulumi/pulumi";
import * as fs from "fs";
import * as os from "os";
import * as path from "path";

const config = new Config();
//const publicKey = config.get("publicKey");
const privateKeyBase64 = config.get("privateKeyBase64");

const privateKey = privateKeyBase64
  ? Buffer.from(privateKeyBase64, "base64").toString("ascii")
  : fs
      .readFileSync(path.join(os.homedir(), ".ssh", "id_rsa"))
      .toString("utf8")
      .trim();

const svcAct = new gcp.serviceaccount.Account("my-service-account", {
  accountId: "service-account",
  displayName: "Service account for Pulumi",
});

const svcKey = new gcp.serviceaccount.Key("my-service-key", {
  serviceAccountId: svcAct.name,
  publicKeyType: "TYPE_X509_PEM_FILE",
});

const address = new gcp.compute.Address("my-address", {
  region: "us-central1",
});

const network = new gcp.compute.Network("network");
const computeFirewall = new gcp.compute.Firewall("firewall", {
  network: network.id,
  allows: [
    {
      protocol: "tcp",
      ports: ["22"],
    },
  ],
});

// Create a Virtual Machine Instance
const computeInstance = new gcp.compute.Instance("instance", {
  machineType: "n2-standard-2",
  zone: "us-central1-a",
  bootDisk: {
    initializeParams: {
      image: "ubuntu-os-cloud/ubuntu-1804-lts",
      size: 20,
    },
  },
  networkInterfaces: [
    {
      network: network.id,
      accessConfigs: [{ natIp: address.address }],
    },
  ],
  advancedMachineFeatures: { enableNestedVirtualization: true },
  serviceAccount: {
    scopes: ["https://www.googleapis.com/auth/cloud-platform"],
    email: svcAct.email,
  },
  metadata: {
    "enable-oslogin": "false",
    "ssh-keys": `user:${svcKey.publicKey}`,
  },
});

const connection: types.input.remote.ConnectionArgs = {
  host: address.address,
  user: "user",
  privateKey: privateKey,
};

const copyFile = new remote.CopyFile("docker-install-file", {
  connection,
  localPath: "deploy.sh",
  remotePath: "deploy.sh",
});

const execCommand = new remote.Command(
  "exec-docker-shell",
  {
    connection: connection,
    create: "sh deploy.sh",
  },
  { dependsOn: copyFile }
);

// Export the name and IP address of the Instance
export const instanceName = computeInstance.name;

@madhank93 the error you're having is related to the authentication when connecting to the SSH server. There's a few reasons this is occurring.

The user "user" as part of the types.input.remote.ConnectionArgs is incorrect
The user "user" doesn't have  the public SSH key installed (or not deployed correctly) in its profile

Thanks for the clarification @aureq.


Fix missing pkg-config ´error due to dependencies order

vagrant@ubuntu:~$ brew install --HEAD neovim
==> Installing neovim from neovim/homebrew-neovim
==> Installing dependencies for neovim/neovim/neovim: makedepend, openssl, pkg-config, curl, cmake, xz, libtool, autoconf, automake, gettext
==> Installing neovim/neovim/neovim dependency: makedepend
Error: /home/vagrant/.linuxbrew/opt/pkg-config not present or broken
Please reinstall pkg-config. Sorry :(

I don't think this is the right place to fix that. makedepend does have a dependency on pkg-config, so why is it not installed? Or maybe your local installation was just broken?

I reproduced this issue with the following steps by installing linuxbrew according to its direction for ubuntu:
# install prereqs
sudo sudo apt-get install build-essential curl git m4 ruby texinfo libbz2-dev libcurl4-openssl-dev libexpat-dev libncurses-dev zlib1g-dev

# clone linuxbrew and add to path
git clone https://github.com/Homebrew/linuxbrew.git ~/.linuxbrew
cat >> ~/.foo <<EOF
export PATH="$HOME/.linuxbrew/bin:$PATH"
export MANPATH="$HOME/.linuxbrew/share/man:$MANPATH"
export INFOPATH="$HOME/.linuxbrew/share/info:$INFOPATH"
EOF

brew tap neovim/neovim
brew install --HEAD neovim

manually installing pkg-config fixed the problem as you would expect.


Updating / saving resources

From @IdahoEv on October 1, 2015 15:11
A couple things I'm unable to find docco on this morning:

When looking at a resource, how can I tell if it's a newly created one, or one that has been previously persisted on the backend?

How do I save an updated resource?  The only up-to-date example code I have is for saving newly created resources with .create() as follows:
save(user) {
user.confirmationLink = this.$state.href('root.inner.passwordsUpdate', {}, {absolute: true});
this.users.create(user).then((user) => {
this.$state.go('root.admin.users.index');
},
(resp) => {
return this.$lrdToast.error(resp.errors);
});
}

Copied from original issue: LRDesign/relayer#16

From @IdahoEv on October 1, 2015 16:11
I was able to figure this out through a combination of trial and error and inspecting objects in the console.  So, consider this ticket just a request for documentation with a note on where one user was confused.  Current README only gives examples of reading & traversing resources, not creating or updating.


[Question] How to deal with such an error in k8s ？

init env variables
generate dolphinscheduler config
/root/startup-init-conf.sh: line 150: /opt/dolphinscheduler/conf/env/dolphinscheduler_env.sh: Read-only file system

@zhangfeng114 It seems that you use the DolphinScheduler'version <=1.3.5, but the used docker image is the latest (1.3.6). So either modify the tag in values.yaml to 1.3.5, or use 1.3.6 DolphinScheduler chart https://dolphinscheduler.apache.org/zh-cn/download/download.html


Edit/Delete doesn't work on Develop

After I add few images I couldn't delete anything - delete button shows dialog, but no action there (after refresh the same).
The same problem with Edit button. I clicked it and nothing happens, just address changes but page still the same. If I try to refresh page manually I have NullReferenceException

What page? Can you please attach a screenshot?

@aloscha is it fixed now?

@aloscha what's the status of this one? Please make sure that you inform on GitHub what's your intention. Right now there are two commits created by you despite the issue was self-assigned by @diliger.

@aloscha ping

I fix that issue by my own and I think in pr you already check it

Fixed in https://github.com/StarcounterPrefabs/Images/pull/60


feat: support autonaming session

The autonaming session will only be enabled if the following two conditions are met:

Run .session or -s without a session name.
Set save_session: true.

The autonamed session will be saved to <aichat-config-dir>/sessions/_/<datatime>-<autoname>.yaml
The autonamed session can be loaded with the name _/<datatime>-<autoname>
solve #947 #805, replace #811

This sounds fantastic and something I would use by default when invoking aichat. Is it easy to resume the session using TAB/auto-completion? From the screenshot it seems that  is YYYYMMDD... format. As the number of sessions in a year increases, I imagine the autocomplete will quickly become unwieldy. Perhaps -.yaml would be better?

We don't support tab completions for auto-named sessions. There are too many of them, and their name lengths are also uncontrollable.
The <datetime>-<autoname>.yaml makes more sense. Searching by date is more convenient than searching by name.

Is  the title name "haskell-hello-world-example" summarized by LLM? E.g. aichat asks LLLM to generate a title based on the chat history (similar to chatgpt's title)?


Merged the supg code

Has all the older versions of the files, which were removed in the newer versions..
Pull the current version of the code and add the code changes to that code and give a PR.


problems about Metric depth estimation-prepare the training and test datasets.

Hi,
I based on this document.
I still have some confussion
"Please follow ZoeDepth to prepare the training and test datasets."
I want to know where to place the dataset
I unzip the datasets on the  ./metric_depth/workspace/dataset/kitti_dataset/
but still reporting an error，where to place the kitti datasets?
Traceback (most recent call last):
  File "/root/autodl-tmp/Depth-Anything-main/metric_depth/evaluate.py", line 159, in <module>
    eval_model(args.model, pretrained_resource=args.pretrained_resource,
  File "/root/autodl-tmp/Depth-Anything-main/metric_depth/evaluate.py", line 131, in eval_model
    metrics = main(config)
  File "/root/autodl-tmp/Depth-Anything-main/metric_depth/evaluate.py", line 115, in main
    metrics = evaluate(model, test_loader, config)
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/_contextlib.py", line 115, in decorate_context
    return func(*args, **kwargs)
  File "/root/autodl-tmp/Depth-Anything-main/metric_depth/evaluate.py", line 71, in evaluate
    for i, sample in tqdm(enumerate(test_loader), total=len(test_loader)):
  File "/root/miniconda3/lib/python3.10/site-packages/tqdm/std.py", line 1195, in __iter__
    for obj in iterable:
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 630, in __next__
    data = self._next_data()
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 1345, in _next_data
    return self._process_data(data)
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/data/dataloader.py", line 1371, in _process_data
    data.reraise()
  File "/root/miniconda3/lib/python3.10/site-packages/torch/_utils.py", line 694, in reraise
    raise exception
FileNotFoundError: Caught FileNotFoundError in DataLoader worker process 0.
Original Traceback (most recent call last):
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/data/_utils/worker.py", line 308, in _worker_loop
    data = fetcher.fetch(index)
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/data/_utils/fetch.py", line 51, in fetch
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/root/miniconda3/lib/python3.10/site-packages/torch/utils/data/_utils/fetch.py", line 51, in <listcomp>
    data = [self.dataset[idx] for idx in possibly_batched_index]
  File "/root/autodl-tmp/Depth-Anything-main/metric_depth/zoedepth/data/data_mono.py", line 380, in __getitem__
    image = np.asarray(self.reader.open(image_path),
  File "/root/autodl-tmp/Depth-Anything-main/metric_depth/zoedepth/data/data_mono.py", line 267, in open
    return Image.open(fpath)
  File "/root/miniconda3/lib/python3.10/site-packages/PIL/Image.py", line 3247, in open
    fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: './data/Kitti/raw_data/2011_09_26/2011_09_26_drive_0002_sync/image_02/data/0000000069.png'

The error partially tells you, I believe. "./data/Kitti/raw_data/2011_09_26/2011_09_26_drive_0002_sync/image_02/data/0000000069.png"
Make sure you have a file called data/Kitti/x/x/x/x... The exact placement.. should be in the "metric_depth" folder if I remember correctly. Might be wrong


put the number of papers in each list on each tab in the 'your afp papers' page

Looks good for everyone, closing


App Lock Password - NOT WORKING

Hello, I think I've found a bug, this is the scenario:
Right after the app install, when opening it for the very first time, it will ask you if you desire to password protect (lock) the application on opening.
Sadly, it dose NOT matter If I go with the option "Set a Password" or how many times I "tap/click",
as it will not gonna work. In the Google Play version, it is happening nothing, and in the other versions the "password screen menu" is getting Killed/Closed.
I have tried these versions:

From the Website Version 14.0.3 => https://guardianproject.info/releases/chatsecure-latest.apk
From Google Play Store 14.0.4 => https://play.google.com/store/apps/details?id=info.guardianproject.otr.app.im&hl=en
From F-Droid 13.1.2 AND  the old deprecated one "Gibberbot" 0.0.11-RC5
https://f-droid.org/repository/browse/?fdfilter=chat&fdid=info.guardianproject.otr.app.im

This is the Scenario:

When starting the app, app Lock passwd input is NOT possible

The user is expecting at this step to be able to input a passwd / swipe / pin lock

After staring the app there is no App Lock passwd menu available

At this step, the user is expecting to change the lock pin / passwd from whitin the app settings.

Here is the a video ==>> http://youtu.be/RzmZgKum5Og <<==

I'm going to second @unknerror here actually. The "password" field was also not very clearly marked, to me. I came here also thinking this feature was broken. I can't say why for sure, but I would consider having somebody with UI experience look at it and figure out why.

If it were up to me, I'd have a header font that says "Set Password" for the dialog. And then have the button say "Submit" or similar. I think this is more like what people are used to.


[Content]: CleverTap supports Cloud Mode as well

What article on segment.com/docs is affected?
https://segment.com/docs/connections/destinations/catalog/clevertap/
What part(s) of the article would you like to see updated?

In CleverTap Destination document, under "Connection modes", the table states that only Device-mode Web, Mobile are supported, which is inaccurate.
CleverTap Destination actually supports :
Device-mode: Web, Mobile
Cloud-mode : Web, Mobile, Server

Similar to #1, update the same information under "Supported Sources and Connection Modes"
Additional information
No response

Hi @shahharsh093, thanks for letting us know about this.
The reason the CleverTap connection modes display the way they are is this:
For our documentation, we infer integration connection modes using the Supported Platforms, and available Components. In CleverTap's case, we see that they do support Browser, Mobile, and Server components. However, there are no available Server or Cloud components (Only Browser, iOS, and Android).
This means that our process that computes connection modes does not see any cloud connections available.
I'll do some digging on my side to see if there is a workaround for this, or I will manually override the connection modes to update. This issue will remain open in the mean time.

Thanks, @markzegarelli for looking into this. Possible to manually override the connection modes so that the documentation reflects the connection mode state accurately.
Looking forward to your responsne.


Support stemmer-languages other than english

Following discussion from https://github.com/pipedown/noise/issues/30
The wrapper around the snowball stemmer is hard-coded to english. Quite some
flexibility could be gained by offering the ability to specify a different language
supported natively by the snowball-project. Obviously english should be the default.
From the top of my head:
Something along the lines of:
let index = noise.open("myindex", true, { "lang": "german" });
Most use cases should operate on a single language, so multi-language support
shouldn't be an issue.

Looked into it and managed to build a german-stemming fork. With two minor alterations:
change language in src/stem.rs and set my fork of noise in the node-noise fork as
the noise dependency. Including the node-noise fork works as expected (text is stemmed
with german rules, and fuzzy search works as expected):
Anyone interested in trying out the 'german'-fork can try it out by including
my github fork as noise-search dependency:
  "dependencies": {
    "noise-search": "git://github.com/OSHistory/node-noise"
  }

cargo test fails now, obviously, on the stemming part.
Links to my forks:
node-noise fork
noise fork

Nice work! I'm glad you figured it out (the whole chain with Node + Rust + RocksDB is far from being obvious). I hope I find some time to add this properly soon.


Fixed Spelling.

Hello @jimmycasey
Thanks for the helping ! We are not yet there with PRs, can you file a JIRA and upload a patch, that would be awesome.

This spelling issue is no longer in the repo line numbers don't match up with current master. Closing the PR.


When used with seaborn, legend draws error: two legend label boxes appear.

Description
I was using propplot as the layout tool and seaborn as the plotting tool.
Everything was fine until I used ax.legend(loc='b') to add a label box below the plot. Two tab boxes appeared! One is drawn by seaborn itself, and the other is drawn by propplot.
I tried adding legend=False to sns.lineplot(), however, this makes proplot unable to get all the legend information (because seaborn will not add the automatically generated legend information except the label to the handler).
How to solve this problem please?
I can turn off the legend of proplot, but then I can't adjust the position of the legend box!
Steps to reproduce
fig, axs = pplt.subplots(ncols = 1, nrows = 2, refaspect=2, refwidth=5, sharey=False)
axs.format(abc='a', abcloc='ul')
sns.lineplot(ax=axs[0], data=global_mean, x="year", y="LAI", hue="Dataset", legend=False)
axs[0].format(ylabel='Global Mean LAI ($\mathregular{m^2/m^2}$)')

sns.lineplot(ax=axs[1], data=global_annomaly, x="year", y="LAI", hue="Dataset")
sns.lineplot(ax=axs[1], data=global_annomaly, x="year", y="LAI", color="black", linewidth=2.2, label="Multi-dataset Mean")
axs[1].format(ylabel="Global LAI Anomaly ($\mathregular{m^2/m^2}$)")
axs[1].legend(loc='b')
fig.show()

Expected behavior:
Only one legend box on the bottom of the plot.
Actual behavior:

Another Example:
Adding legend=False to sns.lineplot()
fig, axs = pplt.subplots(ncols = 1, nrows = 2, refaspect=2, refwidth=5, sharey=False)
axs.format(abc='a', abcloc='ul')
sns.lineplot(ax=axs[0], data=global_mean, x="year", y="LAI", hue="Dataset", legend=False)
axs[0].format(ylabel='Global Mean LAI ($\mathregular{m^2/m^2}$)')

sns.lineplot(ax=axs[1], data=global_annomaly, x="year", y="LAI", hue="Dataset", legend=False)
sns.lineplot(ax=axs[1], data=global_annomaly, x="year", y="LAI", color="black", linewidth=2.2, label="Multi-dataset Mean", legend=False)
axs[1].format(ylabel="Global LAI Anomaly ($\mathregular{m^2/m^2}$)")
axs[1].legend(loc='b')
fig.show()

Proplot version
Paste the results of import matplotlib; print(matplotlib.__version__); import proplot; print(proplot.version)here.
3.4.3
0.9.5

I have found a solution though the problem in proplot is still yet to be settled.
Firstly, I plot only by seaborn with legend=True.
Secondly, I get the legend handles by h, l = g.get_legend_handles_labels().
Thirdly, I plot with proplot with legend=False for seaborn (so that seaborn will not draw another legend).
Finally, I add the legend by proplot using fig.legend(handles=h, labels=l)
Every thing works fine now except I need to plot with seaborn twice (the first time is only for getting the legend handles).

I think this problem occurs because proplot rewrites the legend part in matplotlib so that the figure can have multiple legends.


Generate Thrift constants

At the moment we do not generate the constants defined in the schema; we could be generating them as static methods of a struct, for instance.

I'd be happy to help with some of the rust thrift issues / features. I can imagine that you have some thoughts about what a certain feature should look like. What's the best way to discuss those? For example this one. What about using rust constants? http://rustbyexample.com/custom_types/constants.html

Thanks for offering to help! If you could look into supporting the
constants it will be great - I have not really looked into this yet, but
using Rust const's looks like a good first shot. So far I was first
implementing Rust code by hand and then adding generation to the compiler;
if you feel comfortable with the solution, I'll be happy to review a pull
request.
On Wed, May 27, 2015 at 11:54 PM, Rad Gruchalski<EMAIL_ADDRESS>wrote:

I'd be happy to help with some of the rust thrift issues / features. I can
imagine that you have some thoughts about what a certain feature should
look like. What's the best way to discuss those? For example this one. What
about using rust constants?
http://rustbyexample.com/custom_types/constants.html
—
Reply to this email directly or view it on GitHub
https://github.com/maximg/thrift/issues/12#issuecomment-106089435.

I've done an initial assessment for this feature and this is what I found out so far.
Looking at other languages, anything can be stuck as a constant, meaning that a thrift file may choose to set, for example, a structure in a constant. In rust a const usage is limited. Trying to do the following:
pub const SOMECONST: StructType = SructType::new();

where StructType is
pub struct StructType {
  ...
}

results in
error: function calls in constants are limited to struct and enum constructors

Same limitation applies to static.
I think it's fair to ask: what is considered to be const/static? A reference? Or a value? If a value, this would be sufficient:
#[allow(non_snake_case)]
pub fn SomeConstant() -> String {
    return "This is my static value...".to_string()
}

In such case, I'd propose the following:
#[allow(unused_imports)]
use std::collections::{HashMap, HashSet};
use thrift::protocol::{MessageType, Type};
use thrift::transport::Transport;
use thrift::protocol::Protocol;
use thrift::protocol::{Readable, Writeable};
use thrift::TResult;
#[allow(unused_imports)]
use thrift::ThriftErr;
#[allow(unused_imports)]
use thrift::ThriftErr::*;
use thrift::protocol::ProtocolHelpers;
#[allow(unused_imports)]
use thrift::protocol::FromNum;

pub mod constants {

  #[allow(unused_imports)]
  use parent::module::*

  #[allow(non_snake_case)]
  pub fn SomeConstant() -> String {
    return "This is my static value...".to_string()
  }

  #[allow(non_snake_case)]
  pub fn SomeStructConstant() -> StructType {
    return StructType::new()
  }

}

pub struct StructType {
  ...
}
impl ...

// other structs ...

The value returned from a function representing a constant would always look the same. So, not really the same thing but looking the same. Would it be sufficient? @maximg

Indeed handling const structs is less than straightforward; if I look at Rust constants it seems they can be supported, but we may need to generate separate consts for each field, see here:
https://doc.rust-lang.org/reference.html#constant-items
const BIT1: u32 = 1 << 0;
const BIT2: u32 = 1 << 1;

const BITS: [u32; 2] = [BIT1, BIT2];
const STRING: &'static str = "bitstring";

struct BitsNStrings<'a> {
    mybits: [u32; 2],
    mystring: &'a str
}

const BITS_N_STRINGS: BitsNStrings<'static> = BitsNStrings {
    mybits: BITS,
    mystring: STRING
};

I am not sure how easy it will be to support containers this way, and if we will have to introduce many more annotations than now. There seems to be a test for const support (test/ConstantsDemo.thrift), maybe it is a good starting point.
For the approach based on functions I have the following concerns:
a) Do we want to handle simple consts (int, etc) separately or introduce functions for them as well?
b) Can we avoid building complex structures every time a const is used in the client code?
c) Do we expect the following code to work for all const types, including containers:
let x = MY_THRIFT_CONST;
let y = MY_THRIFT_CONST;
assert!(x == y);

Oops, wrong button. Reopening.

That's a nice path to explore. I'll have a look if this is a reasonable path.

@radekg Are you still working on this? The other issues that need to be done before submitting this to the mainline are almost complete, so I just wanted an update on this.

@gsingh93 It will be very difficult for me to deliver in a reasonable time.


feat(core): support update of SCS read from JSON file

Resolves #197

Does this need to be a uniform interface when processing JSON data?

Or just SCS because it uses Json?

It looks like the CLI currently reads only Subject Condition Sets and client credentials from JSON optionally as a flag value or a file. In each case we unmarshal differently into values (the former with json.RawMessage and protojson and the latter via just json), so I don't know how much value a common interface would give at this time. Please let me know if you disagree, though.


pick() is not right function

Hi,
Your pick() implementation is not same original (http://underscorejs.org/#pick). Yours should be named pluck(). It made me confusing when using it.
Thank you for good library.

Fixed and tagged in 0.6.0.


fix: shuttle init --template, reorder subcommands, fix bugs

Description of change

⭐ Rename the arguments to init from --axum to -t/--template axum etc
Reorder cargo-shuttle arguments based on relevance to a new user
Transparency: showing what cargo init command is being run, and printing the output.
Rename --new to --create-env
⭐ Pass the project name (--name or as prompted) to cargo init --name. This means that the crate name will be what you choose as project name, not what the folder is called. cargo shuttle init --name my-crate -t axum my-shuttle-folder will put "my-crate" in Cargo.toml. Not sure this is the right move. More reading: https://github.com/shuttle-hq/shuttle/issues/665#issuecomment-1476273872 https://discord.com/channels/803236282088161321/1076126506323030017/1100716327511015514
TODO?: Don't prompt for path if it was given as arg. This is kinda tricky because the parsing done by parse_init_path() makes it hard to know if the path was given or not.

⭐= more "breaking" change, happy to discuss
How Has This Been Tested (if applicable)?

A bunch of manual testing
The integration tests for init has been updated. Will probably add more. Tests will be updated when template cloning is done.
The relevant unit test was dumbed down, maybe too much.

New ordering in subcommands
  init        Create a new shuttle project
  run         Run a shuttle service locally
  deploy      Deploy a shuttle service
  deployment  Manage deployments of a shuttle service
  status      View the status of a shuttle service
  stop        Stop this shuttle service
  logs        View the logs of a deployment in this shuttle service
  project     List or manage projects on shuttle
  resource    Manage resources of a shuttle project
  secrets     Manage secrets for this shuttle service
  clean       Remove cargo build artifacts in the shuttle environment
  login       Login to the shuttle platform
  logout      Log out of the shuttle platform
  generate    Generate shell completions
  feedback    Open an issue on GitHub and provide feedback
  help        Print this message or the help of the given subcommand(s)

New help page for init
shuttle ❯ cargo run -p cargo-shuttle -- init --help
Create a new shuttle project

Usage: cargo-shuttle init [OPTIONS] [PATH]

Arguments:
  [PATH]
          Path to initialize a new shuttle project

          [default: .]

Options:
  -t, --template <TEMPLATE>
          Initialize the project with a template

          Possible values:
          - actix-web: Initialize with actix-web framework
          - axum:      Initialize with axum framework
          - poem:      Initialize with poem framework
          - poise:     Initialize with poise framework
          - rocket:    Initialize with rocket framework
          - salvo:     Initialize with salvo framework
          - serenity:  Initialize with serenity framework
          - tide:      Initialize with tide framework
          - thruster:  Initialize with thruster framework
          - tower:     Initialize with tower framework
          - warp:      Initialize with warp framework
          - none:      Initialize with no template

      --working-directory <WORKING_DIRECTORY>
          Specify the working directory

          [default: .]

      --create-env
          Whether to create the environment for this project on shuttle

      --name <NAME>
          Specify the name of the project (overrides crate name)

      --api-key <API_KEY>
          API key for the shuttle platform

  -h, --help
          Print help (see a summary with '-h')

More transparent output from cargo init
A bit whacky, but shows the command and output/warnings/errors from cargo init.
shuttle/test ❯ cargo run -p cargo-shuttle -- init --name xyz -t axum abc
     Running `"cargo" "init" "--bin" "--name" "xyz" "/home/jonaro00/shuttle/test/abc"`
warning: compiling this new package may not work due to invalid workspace configuration

current package believes it's in a workspace when it's not:
current:   /home/jonaro00/shuttle/test/abc/Cargo.toml
workspace: /home/jonaro00/shuttle/Cargo.toml

this may be fixable by adding `test/abc` to the `workspace.members` array of the manifest located at: /home/jonaro00/shuttle/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.
     Created binary (application) package

For clarity: I marked this as a breaking change, but it won't break for people who don't upgrade. However, since we also need to update the docs for this it will appear broken for people who follow the docs but haven't updated.

It's planned for monday next week, so if you could swing that it would be great, but if you can't just let me know and I'll do it! And I agree, telling people to upgrade if they encounter this is no biggie. It's just good to try to avoid breaking changes when we can (although we are still very relaxed on this), so users don't always have to upgrade immediately, and also it's good to mark breaking changes clearly so we don't forget when we make a release. :smile:

@oddgrd
ready for 0.16.0: https://github.com/shuttle-hq/shuttle-docs/pull/91
Some of the examples/showcases on www are getting outdated... If our adventure with token resetting gets around to updating it, I can take a look and bump them too.


[php] PHP globals hovers on html tag

In a file called header.php.
Hovering over the html5 <header> tag shows a php header() tooltip:

It also shows it on the </header> tag.
I have php 7 installed on the system.

This is annoying, but the builtin PHP support is very simple, and so it isn't easy to fix. I suggest using a PHP extension.


Add the destroySession method and support the with syntax.

Not destroying the session can also cause memory leaks, so the destroySession method needs to be called.
Current problems:
In the goland project, destroySession does not close the httpclient connection, even if we call it now, it will still cause memory leaks. I have submitted the code to the tls-client library to fix this issue.
If you need to test, I have compiled the package with the modifications I made.

Thank you very much for the pull request. I have merged it into main.


Add a "Vendor Supported" quality metric

We need a means of highlighting cookbooks provided and supported by other companies for their products.

Love the idea but since there won't be any way to automatically detect this I think it's best implemented as a new feature for the Supermarket separate from the quality metrics.

Agreed with Nathen. As a reflection of the quality metrics, is it something that we would want people to aspire to have vendor support? I think it's separate information that we want to share and visualize on the  Supermarket, but not something that gives a cookbook additional quality. Do we have a specific set of practices we expect to happen based on vendor supported cookbooks?

Just another thought -- we should clarify that vendor support may not be a binary yes/no. It may be that vendors support cookbooks that are unrelated to their product (e.g. if you pay us, we'll help you with any cookbook), vendors providing support for a cookbook that directly deals with their product (e.g. an oracle_java cookbook that installs java), as well as a vendor that only supports a cookbook for paid/licensed users (e.g. oracle_rdbms cookbook that installs the Oracle enterprise edition database).
I suggest we limit the scope of 'vendor supported' to be:

the cookbook installs software supported by a vendor
the vendor also supports the cookbook itself

Should we also make any kind of statement about vendor support that's been orphaned (no responses in X time period)? E.g. a cookbook the vendor used to support, and the docs say the vendor still does, but they clearly don't?

This is being implemented in the Supermarket so I'm going to close this issue.
Reference:

https://github.com/chef/supermarket/issues/1175
https://github.com/chef/supermarket/issues/1176
https://github.com/chef/supermarket/issues/1177
https://github.com/chef/supermarket/issues/1178

I thought "vendor supported" was more general than Chef partner supported. Or was "chef partner support" the original intent of this issue? :8ball:

@martinb3 "partner supported" is more appropriate than "vendor supported", since we're only using the label with companies that have reached out to Chef's Partner Engineering team. The idea is that Partner Engineering will give vendors the guidance they need to write "better" cookbooks.

:+1:


Provide Documentation or a Plugin to Help with S3 setup

In order to help setup of s3 buckets and help guide people newer to s3 and hosting their assets there, it may be helpful to include some recommended S3 bucket configurations in a wiki page or even create a plugin or hook to configure s3 buckets.

Is there some configuration required other than creating the bucket?

@rtm, you will need the accessKeyId, secretAccessKey and region as well.
Please look at the example deploy.js in the README
On Sat, 25 Apr 2015 at 19:26 rtm<EMAIL_ADDRESS>wrote:

Is there some configuration required other than creating the bucket?
--
Reply to this email directly or view it on GitHub
https://github.com/ember-cli/ember-cli-deploy/issues/104#issuecomment-96256489
.

Following the instructions in the readme for using s3 I have not been able to get a working deploy. Once the ember deploy command is done I can see the uploads in the bucket but when I test the url I get:
GET http://somebucket.s3.amazonaws.com/assets/gutenberg-32141d944c8deb502c68a32ad22a9e4b.css net::ERR_CONTENT_DECODING_FAILED
GET http://somebucket.s3.amazonaws.com/assets/gutenberg-23d50de23068d7b0c5915070c9e5a051.js net::ERR_CONTENT_DECODING_FAILED
GET http://somebucket.s3.amazonaws.com/assets/vendor-b801da685e73674bd55b88ad90f1be54.js net::ERR_CONTENT_DECODING_FAILED

@achambers you mentioned needing a region but where in the deploy.js does that get set? Also is there a bucket policy required for this to work?

+1 for a little more help on the S3 side.  @achambers, I'm fine with providing a key and secret (and region), but what permissions does the user associated with that key need?  For example, to upload code to a certain bucket, I have a policy for a user like so:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "s3:PutObject"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:s3:::bucketname/*"
        }
    ]
}

Are there any other actions required as well for this to work?

@IanVS
A Policy like this should work:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListAllMyBuckets"],
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::<bucket-name>",
        "arn:aws:s3:::<bucket-name>*"
      ]
    }
  ]
}

The list all buckets action of course isn't necessary you can restrict this to the respective bucket of course.

@LevelbossMike - It doesn't seem like full actions should be allowed. Shouldn't there be a safe subset?

@ryanjm Not sure what you want to restrict in an asset bucket / index bucket. You can try out to disable deletion of bucket contents for example but you are already granting rights for the user to "deploy" your app so I don't think that would make that much of a difference.

@LevelbossMike That's a good point. I guess these credentials shouldn't be living anywhere except on a trusted computer.

@ryanjm Ideally credentials should live in an environment variable, to maintain separation between config and code.  See http://12factor.net/config (written by engineers at Heroku) for a good explanation.

:+1: on Twelve-Factor configuration.

Twelve-Factor mostly refers to deployed apps, like configuring instances of docker containers with db connection strings, cipher keys, etc.  But it wouldn't be that difficult to use something like https://github.com/motdotla/dotenv to get similar benefits at dev-time.

Right, I’m using dotenv to keep my credentials local. That’s what I meant by keeping them on a local machine. Those will never be published to a server so I don’t need to worry as much about what access they have.

On Jun 23, 2015, at 5:32 PM, Kris Williams<EMAIL_ADDRESS>wrote:
Twelve-Factor mostly refers to deployed apps, like configuring instances of docker containers with db connection strings, cipher keys, etc. But it wouldn't be that difficult to use something like https://github.com/motdotla/dotenv https://github.com/motdotla/dotenv to get similar benefits at dev-time.
—
Reply to this email directly or view it on GitHub https://github.com/ember-cli/ember-cli-deploy/issues/104#issuecomment-114674056.

dotEnv file support is baked into 0.5, and S3 config is documented in https://github.com/ember-cli-deploy/ember-cli-deploy-s3/blob/master/README.md. Closing.


Permission denied

I'm trying to use z with my MacBook but I'm getting this message everytime I try to reload the .bash_profile with source.
-bash: /usr/local/etc/profile.d/z.sh: Permission denied

I got the message everytime, even when I try to install z from Homebrew.
How can I fix this?

FWIW I did the same thing (missed the dot) ha.

btw, sorry for what the meaning of . in that string?

@skywinder you need to source the script (which runs the script in the current shell session), and while you could:
source /foo/bar/z.sh
People say . because even though source is a synonym for dot/period '.' in bash,  it's not in POSIX sh, so for maximum compatibility use the period.


Haven't merged master -> develop in a while - opening PR to look at conflicts

I've been falling into an anti-pattern of going feature -> master.
This has facilitated some fix PRs, but has also resulted in some master changes now conflicting with develop.
Opening this PR to see how much divergence there is...

I think that we're going to need to abort this, and then cherry pick 'feature' fixes from develop across.
Proposal:

shelve (rename!) current develop branch to feature/button_box_improvements <- the source of most merge conflicts
make a new develop branch from master
cherry pick the bits that we want from the old (renamed) develop branch to the new develop branch


Tag releases when published to NPM?

When a release is published to npm, please tag a release with the same tag as the version released, so that it's possible to identify a specific version of the code in use. Thanks!

thank you! this helps a lot.


Failed to operate website on PythonAnywhere

with this error:

ModuleNotFoundError: No module named 'colorfield'

Solved


[wip] Configure the number of preserved data directories.

Adds a control to the runner's configuration page to adjust the number of most recent data directories to preserve for each job.

[x] Add a control to the configuration page.
[x] Actually use the configuration value.

Fixes #28.

Interesting. It looks like dirkeeper deletes the oldest count entries, rather than what I would expect, which is deleting everything but the most recent count entries. That's certainly what I thought from the README, anyway. It special-cases counts of 0, or greater than the number of subdirectories, to delete everything and nothing, respectively.
Looks like I have another PR to make :wrench:

Nice catch.

I've opened an upstream PR at FrozenRidge/dirkeeper#2. With some judicious use of npm link, it looks like it's working correctly.
One interesting note is that this keeps the most recent N+1 builds around, because it prunes all but the most recent N then creates the current build's directory. Do you think I should make the configuration setting include the current build (and account for the off-by-one), or leave it as it is?

I would account for it, and make sure that the minimum is 1.

:+1: Can do.

Done. This should be ready as soon as that dirkeeper PR is merged and shipped (or we can depend on the git commit, I suppose).
Here's what the configuration looks like:


install.sh: don't install nodetool

Nodetool is now supplied by the scylla core package, the Java tools package shouldn't install it anymore.
Drop it from all packaging scripts and also drop the now unused nodetool-wrapper nodetool-completion scripts.
After merged, the submodule update for this PR should be incorporated into https://github.com/scylladb/scylladb/pull/18255.

When we upgrade the package, will it remove the now defunct Java based nodetool? In the RPM post install script for example?

When we upgrade the package, will it remove the now defunct Java based nodetool? In the RPM post install script for example?

No, and we should. I don't know how to do it though. Will need some help on that.

BTW, the nodetool-wrapper removed by this PR didn't make it into any release yet, so no need to add rules to remove it.
We should clear nodetool binary from /opt/shared/cassandra/bin.

v2:

Keep installing nodetool to /opt/scylladb/share/cassandra/bin/nodetool, but don't create a thunk/symlink in /usr/bin (in root install).

@tchaikov after thinking about it, I don't think I need to do any transition work in the packaging of scylla-tools. Instead all the required changes have to go into the packaging of scylla-server, as it is the one which takes over files from this package, the reverse is not true.

v2:

Keep installing nodetool to /opt/scylladb/share/cassandra/bin/nodetool, but don't create a thunk/symlink in /usr/bin (in root install).

@tchaikov after thinking about it, I don't think I need to do any transition work in the packaging of scylla-tools. Instead all the required changes have to go into the packaging of scylla-server, as it is the one which takes over files from this package, the reverse is not true.

agreed, I was commenting on the wrong PR. All the comments should apply to the scylladb PR.

v2:

Keep installing nodetool to /opt/scylladb/share/cassandra/bin/nodetool, but don't create a thunk/symlink in /usr/bin (in root install).

@tchaikov after thinking about it, I don't think I need to do any transition work in the packaging of scylla-tools. Instead all the required changes have to go into the packaging of scylla-server, as it is the one which takes over files from this package, the reverse is not true.

agreed, I was commenting on the wrong PR. All the comments should apply to the scylladb PR.

for scylla-tools , it Breaks scylla-server (<<6.0)

i was wrong. the above comment still applies.

agreed, I was commenting on the wrong PR. All the comments should apply to the scylladb PR.

for scylla-tools , it Breaks scylla-server (<<6.0)

i was wrong. the above comment still applies.

I don't understand. Why is this package breaking scylla-server? Older versions of this package break the new version of scylla-server, but the new one doesn't, they have no common files.

sorry for the confusion, i meant: the new scylla-tools should not coexist with old scylla-server, that's why the new scylla-tools "breaks" the old scylla-server.

sorry for the confusion, i meant: the new scylla-tools should not coexist with old scylla-server, that's why the new scylla-tools "breaks" the old scylla-server.

Ok, makes sense.

@scylladb/scylla-maint please merge. Both this and its sister PR https://github.com/scylladb/scylladb/pull/18255 are ready for merge.

(remember to not create a submodule update after merging, the submodule update has to go into https://github.com/scylladb/scylladb/pull/18255, so it is enough to just merge this to scylla-tools-java:master).


Incorrect query in dev

The dev-query (line 484, 485):
"SELECT DISTINCT winner_name ,  winner_rank FROM matches ORDER BY winner_age LIMIT 3"
generates the wrong output, which is related to the question:
"What are the names and ranks of the three youngest winners across all matches?"
To make the query match with the question the SQL should be:
SELECT winner_name, winner_rank FROM matches GROUP BY winner_name ORDER BY winner_age LIMIT 3

tables.json: baseball_1 has no primary key's defined.


Command %adl liststoreaccounts does not declare the number for list store account

Describe the bug
Command %adl liststoreaccounts does not declare the number for list store account, but the result displayed 5 store accounts, that will make user confusing.
To Reproduce
Steps to reproduce the behavior:

Run command "%adl liststoreaccounts"
Observe the result.

Expected behavior
Should declare the list store account number in this command, otherwise, that will be confusing to user why that can list 5 items.
Screenshots

Desktop (please complete the following information):

OS: [Windows 10]
Browser [chrome]
Jupyter Version 5.5.0

Additional context
If declare the list number, please limit negative numbers, for list number negative number should be invalid.

Should support default config values. So that user no need to specify the values.
Duplicate with issue #13


Is kotlin-reflect really needed for lets-plot?

I'm about to add lets-plot charts to Apache JMeter, and it turns out kotlin-reflect-1.5.21.jar consumes 3 megabytes (~18% of the new jars).
Could kotlin-reflect dependency be avoided in lets-plot?
Just for reference, here's the list of all the jars Kotlin + lets-plot brings:
    54852334 => 71166807 bytes (+16314473 bytes)
    99 => 134 files (+35)

  +   17536 annotations-13.0.jar
  -   18538 annotations-16.0.2.jar
  +  507197 base-portable-jvm-2.1.0.jar
  +  485809 batik-anim-1.14.jar
  +  424624 batik-awt-util-1.14.jar
  +  703757 batik-bridge-1.14.jar
  +  112373 batik-codec-1.14.jar
  +    8433 batik-constants-1.14.jar
  +  330318 batik-css-1.14.jar
  +  184487 batik-dom-1.14.jar
  +   10238 batik-ext-1.14.jar
  +  192087 batik-gvt-1.14.jar
  +   11466 batik-i18n-1.14.jar
  +   76875 batik-parser-1.14.jar
  +   25876 batik-script-1.14.jar
  +    6663 batik-shared-resources-1.14.jar
  +  232734 batik-svg-dom-1.14.jar
  +  227514 batik-svggen-1.14.jar
  +  129300 batik-transcoder-1.14.jar
  +  127477 batik-util-1.14.jar
  +   33866 batik-xml-1.14.jar
  +   32033 kotlin-logging-jvm-2.0.5.jar
  + 2993765 kotlin-reflect-1.5.21.jar
  + 1505952 kotlin-stdlib-1.5.31.jar
  +  198322 kotlin-stdlib-common-1.5.31.jar
  +   22986 kotlin-stdlib-jdk7-1.5.31.jar
  +   16121 kotlin-stdlib-jdk8-1.5.31.jar
  +  792176 kotlinx-html-jvm-0.7.3.jar
  +  196707 lets-plot-batik-2.1.0.jar
  + 3593892 lets-plot-common-2.1.0.jar
  +  627895 plot-api-jvm-3.0.2.jar
  +  882509 plot-base-portable-jvm-2.1.0.jar
  +  792534 plot-builder-portable-jvm-2.1.0.jar
  +  115007 plot-common-portable-jvm-2.1.0.jar
  +  454864 plot-config-portable-jvm-2.1.0.jar
  +  173932 vis-svg-portable-jvm-2.1.0.jar
  +   85686 xml-apis-ext-1.3.04.jar

Hi, I have to double check on this but this is most likely a required dependency.

I'm not sure what are the build/test instructions (are you interested in GitHub Actions-based CI?), however, I commented all kotlin-reflect dependencies, and gradlew build more-or-less works for me.
There are several reflection usages:
AesReflectTest which uses reflection to instantiate Aes: https://github.com/JetBrains/lets-plot/blob/6249749a1d58a3d210f644e748698123c08d4e54/plot-base-portable/src/jvmTest/kotlin/plot/base/AesReflectTest.kt#L22-L23
LiveMapTestBase which uses .constructors..: https://github.com/JetBrains/lets-plot/blob/6249749a1d58a3d210f644e748698123c08d4e54/livemap/src/jvmTest/kotlin/jetbrains/livemap/LiveMapTestBase.kt#L82
BUILD SUCCESSFUL in 1m 58s
588 actionable tasks: 159 executed, 429 up-to-date

(I excluded python-extensions)
Other than that, it looks like kotlin-reflect is not really used in the implementation of lets-plot.

AFAIK Kotlin compiler is able to compile simple things like ::class.name and delegated properties without dependency on kotlin-reflect.

Just in case, the use of lets-plot in JMeter is very minimal now (~one line chart), and it works when kotlin-reflect dependency is excluded.

Sounds good! If ::class.name indeed doesn't fail at runtime without kotlin-reflect then I don't see a reason to bundle this dependency.
For now it should be safe to just exclude it as you did.

gradlew build more-or-less works for me.
Yes, this is what we do.

Yes, most reflection we are using is provided by stdlib (Klass.name, KProperty.name). Exceptions are AesReflectTest and  LiveMapTestBase. In fact we already refactored LiveMap tests so there is no need in that kind of reflection, so I removed the code that depends on kotlin-reflect.
So what I did - I removed all kotlin-reflection deps except one - for jvmTest in plot-base-portable. I did excessive testing by running our JVM, Native and JS applications - everything looks fine. If you will notice any problems after this change, please, make us know.


Add SSO with Nextcloud Android SSO API

Please add Single Sign On with the Nextcloud Android Files app (see https://github.com/nextcloud/Android-SingleSignOn)!
Current problem is that flutter/dart is not directly supported (see https://github.com/nextcloud/Android-SingleSignOn/issues/297). The issue was unfortunately closed already. However, I have seen that some very good nextcloud android apps (including yours) are written in flutter/dart, e.g.:

https://gitlab.com/joleaf/nc-passwords-app
https://github.com/vauvenal5/yaga

Perhaps, you and the other developers can find a solution together. Also see https://gitlab.com/joleaf/nc-passwords-app/-/issues/28

Sorry, I'm back from a longer break!
To find a solution that works with flutter would be definitively a good idea.
But as the current system is working and it is more on the side of nice to have i will not prioritize this.
Nevertheless will leave this issue open, for anyone that has news on potential flutter libraries or if i ever get around to work on that!

But as the current system is working and it is more on the side of nice to have i will not prioritize this.

I can't use your fantastic app on my phone as my NC instance only allows SSO. Other Android NC apps were able to login no problem (Nextcloud and Nextcloud Talk). They presented the login screen, which shells out to the OpenID Connect login, then goes in with the token. Thank you!

@dupuik
I'm not sure if i understand you correctly. You can only login with SSO?  How is that even configured? I was not aware that this is possible,
As i mentioned i will currently not invest time into this as it will be a lot of work and there are multiple ways this works already.
Have you checked if you cannot generate an "app password" yourself in nextcloud and then login with this in the app with the Advanced Settings option "Use self generated App Password"

Hi,
I was asking to add SSO support
Thanks,
Ken
On Sat, Apr 17, 2021, 12:26 PM Teifun2 @.***> wrote:

@dupuik https://github.com/dupuik
I'm not sure if i understand you correctly. You can only login with SSO?
How is that even configured? I was not aware that this is possible,
As i mentioned i will currently not invest time into this as it will be a
lot of work and there are multiple ways this works already.
Have you checked if you cannot generate an "app password" yourself in
nextcloud and then login with this in the app with the Advanced Settings
option "Use self generated App Password"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Teifun2/nextcloud-cookbook-flutter/issues/51#issuecomment-821849324,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APBUYSPYWCLR2RYDRQPVL63TJGZELANCNFSM4W3M6TRA
.

@dupuik
Sadly SSO support is not planned in the near future. Can i help you in another way to setup the app?
Or is SSO a deal breaker for you :(

Def not a deal breaker! I will check out the app someday. My wife loves to
cook but doesn't know an easy helpful tool to help her.
On Mon, May 24, 2021, 5:18 PM Teifun2 @.***> wrote:

@dupuik https://github.com/dupuik
Sadly SSO support is not planned in the near future. Can i help you in
another way to setup the app?
Or is SSO a deal breaker for you :(
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Teifun2/nextcloud-cookbook-flutter/issues/51#issuecomment-847341184,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/APBUYSLXMJN36GGXUDJONXDTPK7BRANCNFSM4W3M6TRA
.


TLA+ Trace validation

Per our understanding, to guarantee the correctness of a service based on this raft library, we need to at least ensure two things: the correctness of the consensus algorithm, and correctness of implementation.
We know that using TLC model-check tool and we can verify the correctness of algorithm by exploring the state space of the finite state machine model. You can refer to #112 for the spec that aligns with existing raft library implementation. Note that the spec is also included in this PR.
This PR proposes a method to address the second part of the question: how to verify implementation aligns with algorithm. This PR leverage the idea from TLA+ trace validation in Microsoft CCF. The basic idea is to constrain the state space by the states and transitions that the service actually walks through. We add special trace log points in the library to record the algorithm relevant states and transitions. A trace validation spec walks the core algorithm state machine following the transitions specified by these traces. If it encounters any trace whose state or transition are not allowed by the core algorithm state machine, a mismatch between the implementation and algorithm is found.
Such mismatch implies two things: implementation issue, or out-of-dated model. If we can guarantee the correctness of model, then there must be something wrong in the implementation. We believe this would be especially useful to avoid regressions in new feature implementation.

@joshuazh-x
Out of curiosity, have you found any interesting bugs in the etcd/raft with this test?

No. I did not find bug so far.
Usually when we start a new project, the model shall be validated first. Then trace validation would be used to validate implementation to ensure it aligns to validated model. CCF follows such process.
For etcd, it is a little bit different as the implementation has been running good for long time. So we did it in a reversed way. We build the model according to etcd's implementation and use TLC model checker to validate the correctness of the model (and we did not find any violation to Raft properties).  With this done, we can assure the correctness of current implementation and can catch future implementation issue if it may break Raft.

Rebase to etcd-io/raft main

cc @ahrtr @pav-kv

@joshuazh-x I'll give it a closer look this week.

@pav-kv any comment?

ping @pav-kv

From discussion on slack https://kubernetes.slack.com/archives/C3HD8ARJ5/p1711367871600289
@ahrtr asked if we can confirm that TLA+ can reproduce the etcd durability issue in https://github.com/etcd-io/etcd/issues/14370. @joshuazh-x amazingly already provided a repro https://github.com/joshuazh-x/raft/commit/6aefcc85f83665274f9f0afb70ee8d29f219be3b.
I think this already confirms how having at TLA+ model could  provide benefits to etcd. We could continue to iterate on the PR, but I don't think it's needed as it already will bring value and should not impact the raft codebase. There are many improvements that we could implement:

Validate just raft model, like in https://github.com/joshuazh-x/raft/commit/6aefcc85f83665274f9f0afb70ee8d29f219be3b
Validate different raft configuration (1 node, 3 nodes, 5 nodes)
Integrate with CI

However I don't think we need everything at once, I can work with @joshuazh-x to iterate on it.

One thing, I would like to ensure that I can follow the instructions provided in README and run the validation using script.
It's important to have other people than @joshuazh-x knowing how to run them.
Left a comment.

The example trace isn't correct?
$ ./validate.sh -s ./Traceetcdraft.tla -c ./Traceetcdraft.cfg ./example.ndjson
spec: ./Traceetcdraft.tla
config: ./Traceetcdraft.cfg
Downloading TLA+ tools ... done.
./example.ndjson - FAIL
0 of 1 trace(s) passed

Do I understand correctly that the actual code change should be minimal? My understanding is that it boils down to a dozen or so "tracing" calls in key places, and the whole thing is active only in tests. From this point of view, this work can be done with low risk (does this answer the "controlled" part?).

I believe that the code changes can be completely decoupled from the raft codebase. @joshuazh-x Did you explore other ways of obtaining the trace without changing the code. We explored a very similar approach where we sample traces and simulate the TLA model using the traces. We go further to use the coverage on the model to fuzz test the raft library. You can find our implementation here - https://github.com/zeu5/raft-fuzzing/blob/master/raft.go
There has been some contrasting work done where the traces are generated from the model and run on the implementation. This requires a bit more involved instrumentation which controls the running of the go code in a step-by-step fashion - https://dl.acm.org/doi/abs/10.1145/3552326.3587442. More crucially, they found certain issues with the original TLA spec used here. Unfortunately I observe that the same bugs exist in the TLA+ model here.

Did you explore other ways of obtaining the trace without changing the code.

I see your comment in the sig-etcd channel. I think the benefit of instrumenting/changing raft code is that it can be more easily reused by all applications & test systems.

To summarise my discussion in slack with @ahrtr - The instrumentation will be a feature of the raft library which users can use to collect traces and run the model checker. It is also useful in the etcd e2e tests. However, there is one main concern with the mechanism in which the traces should be collected.
If traces are collected per node and used to check the correctness of the states observed in that node, the interleaving of messages is lost. With this we risk not identifying large class of bugs where there is an inconsistency between the states of two or more nodes. For example, no two leaders in the same term.
Therefore any trace collection mechanism should be central (to all nodes) and preserve the exact interleaving of events observed. The example trace suggests that there is an interleaving of events, whether the interleaving is exactly as it occurred in the execution is unknown.

If traces are collected per node and used to check the correctness of the states observed in that node, the interleaving of messages is lost

We record & verify the trace per node. I think it should be good as long as each node follows the expected state machine transferring paths and doesn't break any invariant properties.
If you think the interleaving of messages is lost is a problem, then please provide an detailed example.
BTW, the existing raft maintainers have limited knowledge on TLA+. Personally I am still in progress of learning TLA+ (my study was interrupted for a while due to KubeCon Paris). If anyone has any comment on the TLA+ spec, please feel free to raise them. We (raft maintainers) will try to provide help from raft perspective.

Quoting from the issue comment @pav-kv - #111 (comment)

Do I understand correctly that the actual code change should be minimal? My understanding is that it boils down to a dozen or so "tracing" calls in key places, and the whole thing is active only in tests. From this point of view, this work can be done with low risk (does this answer the "controlled" part?).

I believe that the code changes can be completely decoupled from the raft codebase. @joshuazh-x Did you explore other ways of obtaining the trace without changing the code. We explored a very similar approach where we sample traces and simulate the TLA model using the traces. We go further to use the coverage on the model to fuzz test the raft library. You can find our implementation here - https://github.com/zeu5/raft-fuzzing/blob/master/raft.go

@zeu5 Decoupling tracing from raft lib is a very good suggestion and I'd love to explore every possible way to achieve that. But you know that would also be very challenging. The proposal you mentioned here and also in Slack could be a solution. This requires evolving current deterministic trace validation method to an indeterministic one (something like current robustness test). To my current understanding, it is doable but I may need some time to investigate how to implement it.

There has been some contrasting work done where the traces are generated from the model and run on the implementation. This requires a bit more involved instrumentation which controls the running of the go code in a step-by-step fashion - https://dl.acm.org/doi/abs/10.1145/3552326.3587442. More crucially, they found certain issues with the original TLA spec used here. Unfortunately I observe that the same bugs exist in the TLA+ model here.

Regarding the spec bug, I did not read the whole paper but just the "Specification bugs" section. The author seems to be conflating the concepts of an action in spec and a request handler in implementation. Both UpdateTerm (bug #1) and ReturnToFollower (bug #2) do not remove the message from the message bag. They are just piece of logic as part of message processing flow. Having them as separated actions here just means that they are atomic actions that can be applied in parallel of rest of the request processing logic. Specifically, the rest of the processing logic for this message can be continued after these two actions being "invoked" in next Receive transition in the state machine. That is to say, the equivalent transition sequence is, for example, transition 1 (Receive -> UpdateTerm) -> transition 2 (Receive -> HandleRequestVoteRequest -> Reply).

To summarise my discussion in slack with @ahrtr - The instrumentation (light and safe) will be a feature of the raft library which users can use to collect traces and run the model checker. It is also useful in the etcd e2e tests. However, there is one main concern with the mechanism in which the traces should be collected.
If traces are collected per node and used to check the correctness of the states observed in that node, the interleaving of messages is lost. With this we risk not identifying large class of bugs where there is an inconsistency between the states of two or more nodes. For example, no two leaders in the same term.
Therefore any trace collection mechanism should be central (to all nodes) and preserve the exact interleaving of events observed. The example trace suggests that there is an interleaving of events, whether the interleaving is exactly as it occurred in the execution is unknown.

The raft spec models the global state machine, and, although logs are written at individual nodes (where else could logs be obtained unless one also instruments the middleware?), they are "merged" by the trace spec into (prefixes of) TLA+ behavior(s). TLC then checks if the set of prefixes of the trace spec and the set of behaviors of the Raft spec (modeling the global state machine) intersect.  The scenario that two or more nodes are leaders in the same term won't be accepted, because it is not a behavior of the raft spec.
The current trace validation uses a centralized clock that it assumes to provide sufficient granularity to correctly establish the happen-before relationship of log events. Insufficient granularity will be accepted by the trace validation iff the Raft spec explicitly allows non-determinism at this point in a behavior.  In order to establish happens-before relationships in the general case, logical clocks would have to be added to the implementation.  https://github.com/tlaplus/Examples/commit/61d6be787445b7c5b7870b93ecc509cb50413abe is an example of how trace validation leverages logical clocks.

Thank you for the comments!
@lemmy - I agree that assuming synchronous clocks solves the problem I list and removes the need for centralised collection of traces.
@joshuazh-x - I agree that the author is exaggerating the meaning of bugs in the paper and the specification in this PR is correct when viewed in isolation. However as I suggest in my review, if the goal is to check conformance between the implementation and the specification then we need to ensure that the granularity of the step is the same between the implementation and the spec. Specifically, if the trace suggests to pick the action Receive(m) but the resulting state in the model is different (even accounting for the non-determinism) from the state in the implementation then we will end up raising a false positive. It is a false positive because there is a stuttered action (an additional Receive(m)) that will lead to the conformed state in the model. But, there is no way of guessing the stuttering.

if the goal is to check conformance between the implementation and the specification then we need to ensure that the granularity of the step is the same between the implementation and the spec. Specifically, if the trace suggests to pick the action Receive(m) but the resulting state in the model is different (even accounting for the non-determinism) from the state in the implementation then we will end up raising a false positive. It is a false positive because there is a stuttered action (an additional Receive(m)) that will lead to the conformed state in the model. But, there is no way of guessing the stuttering.

It is not strictly necessary for the specification and implementation to have identical granularity. Indeed, a specification action can be more coarse-grained, encompassing multiple steps in the implementation. This concept is supported in TLA through specs being insensitive to stuttering ([Next]_vars <=> Next \/ UNCHANGED vars). The behaviors defined by the spec may contain states where the variables remain unchanged over a finite number of states (or forever). Conversely, an implementation might combine several actions into a single, atomic step. TLA's action composition allows us to "merge" multiple actions into a single action.
An example of (finite) stuttering is when entries are appended to the log one by one in the implementation, whereas the spec might append all entries in a single action (NoConflictAppendEntriesRequest). Similarly, action composition of e.g. the UpdateTerm and HandleAppendEntriesRequest actions addresses the implementation optimization that piggy-backs a term message on append entries or request vote messages.
https://dl.acm.org/doi/abs/10.1145/3552326.3587442 does not leverage action composition and, thus, cannot handle what the authors discard as "spec bugs".

It is not strictly necessary for the specification and implementation to have identical granularity

I was being imprecise. I believe the transition systems of the implementation and the spec should be related by a bi-simulation relation if we want to check conformance.

This concept is supported in TLA through specs being insensitive to stuttering

I agree that in principle, TLA+ specification allows for arbitrary stuttered steps. I might have missed it, but in the spec of the current PR, there is no provision  for stuttered steps.

Conversely, an implementation might combine several actions into a single, atomic step. TLA's action composition allows us to "merge" multiple actions into a single action.
An example of (finite) stuttering is when entries are appended to the log one by one in the implementation, whereas the spec might append all entries in a single action (NoConflictAppendEntriesRequest). Similarly, action composition of e.g. the UpdateTerm and HandleAppendEntriesRequest actions addresses the implementation optimization that piggy-backs a term message on append entries or request vote messages.

I am a bit confused by this. Unlike the first example where there is a composition of actions in the spec, the second example requires composition of actions on the implementation side.  UpdateTerm and HandleAppendEntriesRequest are two actions in the model but a single action in the implementation. Since we do not control the granularity of actions on the implementation, we will have to merge the two actions in the spec. Please correct me if I have misunderstood this.

we will have to merge the two actions in the spec

Exactly, A \cdot B or UpdateTerm \cdot HandleAppendEntriesRequest more concretely.  Can be done in the original raft spec or at the level of the trace spec.

It is not strictly necessary for the specification and implementation to have identical granularity

I was being imprecise. I believe the transition systems of the implementation and the spec should be related by a bi-simulation relation (modulo stuttering) if we want to check conformance.

This concept is supported in TLA through specs being insensitive to stuttering

I agree that in principle, TLA+ specification allows for arbitrary stuttered steps. I might have missed it, but in the spec of the current PR, there is no provision for stuttered steps.

Conversely, an implementation might combine several actions into a single, atomic step. TLA's action composition allows us to "merge" multiple actions into a single action.
An example of (finite) stuttering is when entries are appended to the log one by one in the implementation, whereas the spec might append all entries in a single action (NoConflictAppendEntriesRequest). Similarly, action composition of e.g. the UpdateTerm and HandleAppendEntriesRequest actions addresses the implementation optimization that piggy-backs a term message on append entries or request vote messages.

I am a bit confused by this. Unlike the first example where there is a composition of actions in the spec, the second example requires composition of actions on the implementation side. UpdateTerm and HandleAppendEntriesRequest are two actions in the model but a single action in the implementation. Since we do not control the granularity of actions on the implementation, we will have to merge the two actions in the spec. Please correct me if I have misunderstood this.

There are two ways to validate action combination implemented in application. The first one is, as you suggested, modify the spec to combine actions so that we have 1:1 mapping in spec actions and implementation actions. CCF employes this method (https://github.com/microsoft/CCF/blob/c66745d83834fe91028d14ca343e94a6899aeff2/tla/consensus/Traceccfraft.tla#L227). As you can see that that needs to identify all such actions and change them accordingly. That requires very good understanding of the implementation to make it right.
The other way keeps main spec unchanged but let trace validation walks through the same action multiple times. In the original Raft spec, processing a message finish when the message is removed from the global message bag. We follow this design principal to guide the trace validation walk into Receive action again and again until the message is removed from the message bag, i.e., end of implemented Receive action in the application.
StepToNextTraceIfMessageIsProcessed(msg) ==     IF OneLessMessage(msg)          THEN StepToNextTrace         ELSE             /\ pl' = l              /\ UNCHANGED <<l>>.
This method is less intuitive. But it preserves the flexibility in implementation and decouple the trace-guided walking and main Raft algorithm in two specifications more clearly.

Just making sure we are on track with merging the PR. @joshuazh-x @ahrtr what else we need to address to have the PR merged?
Awesome to see such detailed discussion. Please note that it might be better to keep the discussion in the PR related to blockers/feedback related to the PR itself to ensure we are getting closer to merging it. If you have a high level design proposals for what we can do with TLA+ that don't block this PR I would recommend to move them to https://github.com/etcd-io/raft/issues/111 or create a new issue.

Hey, just making sure we are proceeding with the PR.
Awesome to see such detailed discussion. Please note that it might be better to keep the discussion in the PR related to blockers/feedback related to the PR itself to ensure we are getting closer to merging it. If you have a high level design proposals for what we can do with TLA+ that don't block this PR I would recommend to move them to #111 or create a new issue.
@joshuazh-x will you able to address the @ahrtr suggestions in reasonable time? I don't want to push too much work on a single person, as we already see the merits of this approach. It's ok if you cannot address all of the issues in a single PR, we can delegate as it seems there are more people now interested in helping.

@serathius  @ahrtr  Sorry I was swamped at something else lately. I updated the PR following my last catch-up with @ahrtr. Hopefully I did not miss anything important.

Just had a zoom call with @joshuazh-x .
We should make sure the Readme is clear & accurate.
We expect the Readme should be super clear & accurate, so that everyone just needs to follow the readme to run whatever verification. Please write the readme from users' perspective.
Where to generate trace?
Currently this PR instruments/changes raft code to generate trace logs.
There is comment above to propose to obtain the trace without changing raft code. We agree that such approach has better maintainability, and it completely verifies raft as a black box.
But the current way (instrumenting raft code directly) can be more easily reused & integrated into application's (e.g. etcd) test suites. Applications (e.g etcd) just need to provide a valid TraceLogger instance to raft. Otherwise, each application may need to create a different utility to obtain the trace.
It's still open to discussion as a followup.
Merge all trace logs
I was thinking each node just records & verifies the trace logs separately. it isn't correct. All trace logs generated by each node should be merged into one trace file.
Usually in github workflow, all etcd nodes are running on the same host, so we may need to point all TraceLogger instances to the same file. It may complicate the test.
Potential problem when node crashes & restarts
In etcd's test cases, we may randomly crash & restart any etcd member using failpoints. When an etcd node crashes, it may partially persist some logs (WAL records). But the trace log are generated inside the raft repo. So we may run into a situation that all trace logs are persisted, but the data (WAL records) are partially persisted, eventually it leads to the trace validation failure.
It needs more discussion on this.

@ahrtr @lemmy has some great idea on solving this issue. Basically we will need to validate this in non-deterministic way. I'll submit another PR after this one is in.

@serathius @ahrtr  #192 is the draft PR I mentioned to generate traces for test.

This is really useful, thanks for your work!
I had a quick question to make sure I'm doing this right: I tried running verify-model.sh and I get:
Starting... (2024-04-07 14:49:41)
Computing initial states...
Finished computing initial states: 1 distinct state generated at 2024-04-07 14:49:41.
Model checking completed. No error has been found.
  Estimates of the probability that TLC did not check all reachable states
  because two distinct states had the same fingerprint:
  calculated (optimistic):  val = 3.3E-19
7 states generated, 1 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 1.
The average outdegree of the complete state graph is 0 (minimum is 0, the maximum 0 and the 95th percentile is 0).

I see only one state and a graph depth of 1, is that right? Or could that be because of not running it long enough? And also, how can I run this for longer?

That doesn't seem right. The output shall be something like this:
Starting... (2024-04-09 03:49:09)
Computing initial states...
Finished computing initial states: 1 distinct state generated at 2024-04-09 03:49:10.
Progress(8) at 2024-04-09 03:49:13: 33,459 states generated (33,459 s/min), 7,725 distinct states found (7,725 ds/min), 5,643 states left on queue.

Could you share the full output?

@joshuazh-x thanks,

Full output here
❯ ./validate-model.sh -s etcdraft.tla -c etcdraft.cfg
spec: etcdraft.tla
config: etcdraft.cfg
Downloading TLA+ tools ... done.
TLC2 Version 2.18 of Day Month 20?? (rev: d1504b6)
Running breadth-first search Model-Checking with fp 3 and seed -3880762815027339908 with 1 worker on 16 cores with 7282MB heap and 64MB offheap memory [pid: 98807] (Mac OS X 13.6.5 x86_64, Homebrew 21.0.2 x86_64, MSBDiskFPSet, DiskStateQueue).
Parsing file /Users/mjivrajani/gocode/src/github.com/MadhavJivrajani/raft/tla/etcdraft.tla
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/Naturals.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/Naturals.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/Integers.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/Integers.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/Bags.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/Bags.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/FiniteSets.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/FiniteSets.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/Sequences.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/Sequences.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/SequencesExt.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/CommunityModules-deps.jar!/SequencesExt.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/FiniteSetsExt.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/CommunityModules-deps.jar!/FiniteSetsExt.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/BagsExt.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/CommunityModules-deps.jar!/BagsExt.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/TLC.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/TLC.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/_TLCTrace.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/_TLCTrace.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/Folds.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/CommunityModules-deps.jar!/Folds.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/Functions.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/CommunityModules-deps.jar!/Functions.tla)
Parsing file /private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tlc-281771803267607344/TLCExt.tla (jar:file:/private/var/folders/r7/f6kyp7vs0sv90105pjh1t8340000gp/T/tmp.RtLyjmUa/tool/tla2tools.jar!/tla2sany/StandardModules/TLCExt.tla)
Semantic processing of module Naturals
Semantic processing of module Integers
Semantic processing of module Sequences
Semantic processing of module FiniteSets
Semantic processing of module TLC
Semantic processing of module Bags
Semantic processing of module Folds
Semantic processing of module Functions
Semantic processing of module FiniteSetsExt
Semantic processing of module SequencesExt
Semantic processing of module BagsExt
Semantic processing of module TLCExt
Semantic processing of module _TLCTrace
Semantic processing of module etcdraft
Starting... (2024-04-09 11:18:57)
Computing initial states...
Finished computing initial states: 1 distinct state generated at 2024-04-09 11:18:57.
Model checking completed. No error has been found.
  Estimates of the probability that TLC did not check all reachable states
  because two distinct states had the same fingerprint:
  calculated (optimistic):  val = 3.3E-19
7 states generated, 1 distinct states found, 0 states left on queue.
The depth of the complete state graph search is 1.
The average outdegree of the complete state graph is 0 (minimum is 0, the maximum 0 and the 95th percentile is 0).
Finished in 01s at (2024-04-09 11:18:57)

@joshuazh-x thanks,
Full output here

I forgot to set its initial configuration. Fix it in the new commit.
BTW MCetcdraft.tla/cfg is recommended for model checking as it sets reasonable boundaries to limit the search in a small scope. And it also includes bootstrapping logic in node.go.

Overall looks good to me.
I am Ok to merge this PR once other maintainers have no objection.
After we merge this PR, I suggest to move all the TLA+ specs into a dedicated separate repo, something like raft-spec or raft-tla. The purpose is that we can delegate it to a list of dedicated maintainers to maintain. Based on the discussion above, I see some people have expertise on TLA+. Please feedback if anyone is interested in maintain the new repo. At least we should onboard @joshuazh-x @lemmy

I am Ok to merge this PR once other maintainers have no objection.

LGTM

After we merge this PR, I suggest to move all the TLA+ specs into a dedicated separate repo, something like raft-spec or raft-tla. The purpose is that we can delegate it to a list of dedicated maintainers to maintain.

Please note that directories can also have dedicated maintainers, let's keep the TLA spec in raft for as long as we are iterating on the test to avoid friction of coordinating between two repos. We can decide later.

Please note that directories can also have dedicated maintainers, let's keep the TLA spec in raft for as long as we are iterating on the test to avoid friction of coordinating between two repos. We can decide later.

OK, we can revisit this later. Hopefully eventually the TLA spec maintainer should have permission to merge the change on the spec independently.

LGTM
Thanks for the great work!

So happy to see this merged, thank you @joshuazh-x for your work!

This is a great demonstration of TLA+ "real world usage". I hope it gets more publicized and mentioned.


Still Active?

Hi, this is a good idea.  Are you still actively pursuing this?
Thanks

@kevindarby Thanks for your interest in the project.
Right now, I mostly focus on getting XGBoostLSS and LightGBMLSS into a new and more PyTorch environment.


Fix snapshots path

Signed-off-by: Sayali Gaikawad<EMAIL_ADDRESS>Description
S3 upload was creating a directory. This PR fixes that
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Codecov Report

Merging #1485 (98c6cca) into main (42140d1) will decrease coverage by 7.87%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##               main    #1485      +/-   ##
============================================
- Coverage     94.45%   86.58%   -7.88%
  Complexity       12       12
============================================
  Files           142       22     -120
  Lines          3085       82    -3003
  Branches          8        8
============================================
- Hits           2914       71    -2843
+ Misses          164        4     -160
  Partials          7        7

Impacted Files
Coverage Δ

...teg_test_start_properties_opensearch_dashboards.py

...eg_test/integ_test_runner_opensearch_dashboards.py

src/system/os.py

src/ci_workflow/ci_check_list_dist.py

src/ci_workflow/ci_args.py

src/system/zip_file.py

src/paths/output_dir.py

src/build_workflow/builder.py

src/paths/script_finder.py

src/assemble_workflow/bundle.py

... and 110 more

Continue to review full report at Codecov.

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


Add enqueue action support

What this PR does / why we need it:
Add enqueue action support in kube-batch
None

/lgtm
/approve


Update ug v1.2

Update User Guide to include new project direction.
Change order of parameters to align with UG.
Fixes #65 .

Codecov Report

Merging #71 (8e0b2e1) into master (2907cdb) will increase coverage by 0.03%.
The diff coverage is 88.88%.

@@             Coverage Diff              @@
##             master      #71      +/-   ##
============================================
+ Coverage     69.90%   69.93%   +0.03%
  Complexity      406      406
============================================
  Files            74       74
  Lines          1306     1304       -2
  Branches        141      140       -1
============================================
- Hits            913      912       -1
  Misses          345      345
+ Partials         48       47       -1

Impacted Files
Coverage Δ

.../java/seedu/address/logic/commands/AddCommand.java
100.00% <ø> (ø)

...java/seedu/address/logic/commands/EditCommand.java
97.22% <ø> (ø)

...a/seedu/address/logic/parser/AddCommandParser.java
85.00% <75.00%> (+3.18%)
:arrow_up:

...c/main/java/seedu/address/model/person/Person.java
97.82% <100.00%> (ø)

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Slows down commands

I was trying this plugin out but realized that this plugin adds significant lag to commands. I had some remaps that used commands and it made them unusable.
e.g.
vim.api.nvim_set_keymap("n", "}", [[:keepjumps normal! }<cr>]], { noremap = true })
vim.api.nvim_set_keymap("n", "{", [[:keepjumps normal! {<cr>]], { noremap = true })

+1. Like many people I use the following mappings to shift lines up and down, and they become almost unusable when using this plugin.
keymap("n", "<A-DOWN>", ":m .+1<CR>==", opts("Shift line down"))
keymap("n", "<A-UP>", ":m .-2<CR>==", opts("Shift line up"))
keymap("v", "<A-DOWN>", ":m '>+1<CR>gv=gv", opts("Shift line down"))
keymap("v", "<A-UP>", ":m '<-2<CR>gv-gv", opts("Shift line up"))

Hello,
i will look into it, but i guess it is entangled with the copy stuff. Can you please try it with disabled copy sync to narrow down the source?
Kind regards
Alexander

@pafirmin @AlexXi19
Can you please try to reproduce this with disabled  copy sync?

hmmm, i guess the sync with tmux triggers but i have no idea why. Since im not using tmux anymore, can anyone of you try to pin down, why it triggers?

I'm having a similar issue right now with two things in particular:

: takes much longer with the plugin enabled
I have shift+h and shift+l mapped to buffer left / right with bufferline

Having the plugin enabled slows both down to maybe 100-200ms between when I press the shortcut and when it actually happens

I'm having a similar issue right now with two things in particular:

: takes much longer with the plugin enabled
I have shift+h and shift+l mapped to buffer left / right with bufferline

Having the plugin enabled slows both down to maybe 100-200ms between when I press the shortcut and when it actually happens

I have this exact issue.
i have a very simple nvimconfig not many plugins, mainly all with default settings, I recently switched laptops and all my plugins updated (hadnt been updated for a few months) and now i am experincing this issue.
: takes muchhh longer when i use this plugin

@qoobes I am having the exact same issue, enabling the plugin slows down buffer movements significantly and if you keep on holding your buffer movement keys it lag goes even to seconds when you press the key and the buffer switches !!


Fix the Fedora 36 build

Update mkosi and requirements
Backport patch from main (for new gpg keys)
Minor adjustemnts to make it work

Sorry, missed a bug... I'll re-open it


PIC18F25K80 issues

hello,
I have troubles with flashing open-sourced ELM327 firmware to this chip (https://github.com/uholeschak/ediabaslib).
I have successfully connected to the chip, it showed that upload (flashing) was successful, but it has failed at verification stage - Error at 0x0000 E:0xFE R:0x00 (or something along those lines, I did not saved the output log)
Now, when I connect to it again, it only tells me: Wrong device ID: ffe0, expected: 6180.
My board did not have dedicated pins for connecting a programmer, so I had to solder thin wires to some points on the PCB.

Bough a cheap PicKit 2 from eBay - that one flashed my PIC in an instant.
Problem "solved"


Docs link on release notes v0.10.0 is broken

v0.10.0 release notes point to some upgrade instructions (with text in bold that it is critical for upgrades to work). The link takes us to : https://heptio.github.io/ark/v0.10.0/upgrading-to-v0.10 which is not a valid page.
Please fix this doc link.

https://heptio.github.io/velero/v0.10.0/upgrading-to-v0.10 is the right link. Will look at getting this updated.

This is being fixed in the v0.11 release (see the docs related PR for that: https://github.com/heptio/velero/pull/1228). Closing this issue.


added graphql example

All great suggestions. I'll keep working on it!

Outstanding items:

Communicate with Graphiti maintainers about the HTTP 500 issue
Refactor to use the Graphiti Star Wars API example

1. Communicate with Graphiti maintainers about the HTTP 500 issue

Not sure what you mean here. If you are concerned about the Hummingbird returning a 500 status, that is because an error it doesn't recognise has been thrown. You can get around this by conforming the error type to HBHTTPResponseError. This then gives you options to format an HTTP response from the error.

You can get around this by conforming the error type to HBHTTPResponseError. This then gives you options to format an HTTP response from the error.

Perfect! Did just that and added test.
Just need to do the Star Wars API, now.

@adam-fowler StarWars example is in now. I think that resolves all the change requests.

Looking good, can we move the GraphQL (everything prefixed with GraphQL) code into a GraphQL folder, and the Starwars stuff into a StarWars folder. Also make it explicit that the StarWars stuff is coming from the Graphiti repository.
I think it would be good to make it obvious where you would insert database calls (in the Context I assume) and provide an API that returns EventLoopFutures. But we can do that in a second PR if you'd prefer.

I've also thought of a way you can pass a single EventLoop.
Store the API on the HBApplication and create a new context for each api.execute which holds the EventLoop (or maybe even the HBRequest so the user can get a database handle). In this situation the starwars data would have to be static but that makes more sense as we are replicating some global storage.
Again maybe for another PR


Default values for hidden widgets need to be updated

Currently default values for hidden widgets are set on creation.
The fields are not even included in the editor when updating (As far as I can see).
This is unexpected behavior imho. These fields should always be updated with their default value.
Imagine this:
fields: [
    {
      label: "Meta Robots Tag",
      name: "robots",
      widget: "hidden",
      default: "all",
    }
]

On creation this is set to "all', as expected.
Now since we're working with static sites, often developers or even authors work in their IDE using find/replace.
It's very easy for a default value to change without realizing it.
Or another scenario... a default value for a hidden widget changes. It should be possible to update content through the UI, knowing the content will have the new default values.

Hi @madsem, can you follow the feature request template https://github.com/netlify/netlify-cms/issues/new?assignees=&labels=type%3A+feature&template=feature_request.md&title=Please+replace+with+a+clear+and+descriptive+title or the bug report template https://github.com/netlify/netlify-cms/issues/new?assignees=&labels=type%3A+bug&template=bug_report.md&title=Please+replace+with+a+clear+and+descriptive+title?
I'm not sure if you're reporting a bug or a feature, and what is the expected behavior you'd like to have.
I think it's expected that the hidden widget is not shown in the UI:
https://www.netlifycms.org/docs/widgets/#hidden

@erezrokah I've updated it.
I wasn't talking about making hidden widgets visible, I was talking about the fact that they aren't updating their default values.


Ungroup icons on the taskbar in Windows 11

Your Idea
Create checkbox for switch off grouping icons on the taskbar.
In Windows 11, this cannot be done.
SophiApp Version
No response
Windows Version
Windows 11
Comments
No response

There is no built-in method for Windows 11 to do such thing. So no way...
I think you may install StartAllBack, disable a custom Start from the app but enable feature to ungroup icons.

This is what you need: https://windhawk.net/mods/taskbar-grouping