createFromString only reads first line when using CR instead of LF

Hello,
I just exported an excel file to CSV, and wanted to parse this file using this library. I'm using a Mac, so it seems the new lines are done with CR. So, it should work like this, right?
// CR
$reader = Reader::createFromString($file, "\n");
// LF
$reader = Reader::createFromString($file);
However, the first one fails. When trying to ouptut the data later
$data   = $reader->query();
foreach ($data as $lineIndex=>$row) {
    print $row[0] . "\n";
}

I'm only getting the first line. When converting the file to LF and parsing it, I'm getting all the datasets. Is this a known issue? Is there a reason?

Hi @tzfrs Using the library on a Mac is covered in the library documentation


Recognition of auxiliary filters

File core.py, lines 185-188, an auxiliary particle filter is recognised by testing the logetat attribute. However, in line 322, the attribute logeta of self.fk is called instead.
This could lead to APF FeynmanKac objects not being executed properly if they contain logeta attribute but not logetat. This is the case for APF objects created via state_space_models.py.
Seems like the correct fix is to put logeta at line 188 (in coherence with state_space_models.py), but more testing might need to be done (e.g. existing codes).

Hi!
First of all, nice work on thw waste free SMC @hai-dang-dau !
On this, testing for behaviour based on the presence or absence of an attribute is an antipattern an can lead to issues as you highlighted. This should be handled by the inheritance contract, so the real thing to check is if self is an instance of APFMixin (or AuxiliaryPF, depending on logic). The way I would go around it is to delete the isAPF altogether and then replace its use by a direct isinstance check. For instance this
https://github.com/nchopin/particles/blob/8e5eb4c6886823598ba941d4f4eab551e8779509/particles/core.py#L311
would be replaced more cleanly by
if isinstance(self.fk, AuxiliaryPF):

if you are worried about circular imports, you can also use local imports of AuxiliaryPF

@AdrienCorenflos Thanks for your feedback. I do not entirely agree with the type checking solution because that seems to go against Python's "duck typing" philosophy (i.e. any object with the logeta method should work with the implementation, regardless of its type).
My proposition would be to add a boolean-valued useAPF keyword argument in the SMC class. My arguments are:
(1) Even if a FeynmanKac object does include the logeta method, the user may, out of curiosity, prefers running the standard filter instead and sets useAPF=False.
(2) If useAPF is set to True, the implementation shall call fk.logeta without checking. So if the user passes in a FeynmanKac object without logeta method and sets useAPF=True, an AttributeError is therefore automatically raised (which is what we want anyway).

I applied the quick fix recommended by Dang. Now things should work as expected.
But it's true that the current design is a bit dodgy, as proved by this "silent bug". I'll think about it.


Issue with Migration rule v111

I was facing some issues with migration rule v111
Please check the following:

Make sure you are targeting the master branch, pull requests on release branches are only allowed for bug fixes.
Read contributing guidelines: https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md
Describe what your pull request does and which issue you're targeting (if any)

You MUST delete the content above including this line before posting, otherwise your pull request will be invalid.

Codecov Report

Merging #9449 into master will increase coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #9449      +/-   ##
==========================================
+ Coverage   41.51%   41.51%   +<.01%
==========================================
  Files         570      570
  Lines       74639    74642       +3
==========================================
+ Hits        30983    30988       +5
+ Misses      39818    39813       -5
- Partials     3838     3841       +3

Impacted Files
Coverage Δ

models/migrations/v111.go
0% <0%> (ø)
:arrow_up:

services/pull/temp_repo.go
31.62% <0%> (-2.57%)
:arrow_down:

models/repo_list.go
74.07% <0%> (+0.92%)
:arrow_up:

models/unit.go
67.56% <0%> (+5.4%)
:arrow_up:

modules/indexer/code/indexer.go
55.26% <0%> (+10.52%)
:arrow_up:

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 f8a6eb8...8499956. Read the comment docs.


Expo CLI v5 issue

I'd like to upgrade Ignite CLI to use expo-cli version 5.x, but I ran into an issue with Expo and using a local template. This is to track that issue.
https://github.com/expo/expo-cli/issues/4423

For what it's worth, if you use<EMAIL_ADDRESS>via npx definied in new.ts AND uninstall any globally installed expo-cli, a project does get created properly. For example:
const deps: { [k: string]: string } = {
  // expo-cli v5 would be nice, but we're having a problem with it:
  // https://github.com/expo/expo-cli/issues/4423
  expo: "5.0.0",
  podInstall: "0.1",
}

along with these dependencies in the package.expo.json boilerplate:
"dependencies": {
    "@expo/webpack-config": "^0.12.71",
    "expo-linear-gradient": "~11.3.0",
    "expo-localization": "~13.0.0",
    "expo-modules-core": "~0.9.2",
    "expo-status-bar": "~1.3.0",
    "expo": "~45.0.0",
    "react-native-gesture-handler": "~2.2.1",
    "react-native": "0.68.2",
    "react": "17.0.2"
  },

But then after cd myproject, yarn start you obviously get prompted to install expo-cli since it isn't available. Installing the latest then is just fine and ignite will open up to the demo screen.
However, defining it only as "5" will take the latest version and I do get that template error.
const deps: { [k: string]: string } = {
  // expo-cli v5 would be nice, but we're having a problem with it:
  // https://github.com/expo/expo-cli/issues/4423
  expo: "5",
  podInstall: "0.1",
}

Not sure if making use of the Versioned Expo CLI will be of help here, but it is still experimental AFAIK.

Let's work on Expo / Vanilla unification (#1983), which should solve this issue.

This is resolved with the unification of the boilerplate.
PR #1985
Will be released in Ignite v8: Maverick


Is there a way to simplify tokens AFTER tokenizer ?

StringMetric metric =
with(new CosineSimilarity())
.simplify(new Case.Lower(Locale.ENGLISH))
.simplify(new NonWordCharacter())
.tokenize(new Whitespace())
.build();
The example show simplification on the input BEFORE tokenization, but if we want to do simplication on a word not sentence basis it would much easier if the simplifier could just work on a token rather than the whole sentence, by simplifying  AFTER tokenization (For example I would like to write a simplifier that removed "'s" from the end of words)
Using Lucene Analyzers syntax, your simplifiers wortk like a NormalizeCharMap , tokenize is like a Tokenizer but there is no support for Filters.

There isn't. Yet. Not in the StringMetricsBuilder anyway.
I did I re-factor the original library so that the list and set metrics would allow you to compare arbitrary lists with elements of the same type. the StringMetricsBuilder was added to maintain feature parity, not really for advanced processing.
In the immediate term you can work around this short coming by using the components themselves.
SetMetric<String> metric = new CosineSimilarity<String>();
Tokenizer t = new Whitespace();
Set<String> aTokens =  t.tokenizeToSet("hello worlds");
Set<String> bTokens =  t.tokenizeToSet("hello other worlds!");

//apply filtering and transforms on  tokens here

metric.compare(aTokens, bTokens);

But it shouldn't be too hard to add steps that simplify tokens.
StringMetric metric =
with(new CosineSimilarity())
.simplify(new Case.Lower(Locale.ENGLISH))
.simplify(new NonWordCharacter())
.tokenize(new Whitespace())
.filter(new IsLongWordWord())
.simplify(new RemovePossessiveS)
.filter(new IsNoun())
.simplify(new PresentPerfectForm())
.build();

Where IsLongWordWord and IsNoun are Guava filters and RemovePossessiveS and PresentPerfectForm are Guava functions. Would have to keep in mind to create a new Set after each transformation though to avoid duplicates.
If you don't mind me asking. Why aren't you using Lucence though? It's a bit more mature.

thanks Im using this lib because I'm just trying to compare two strings rather than search for x in a number of strings  (documents) whihc is what lucene is for.

I understand the workound you provide, except how would I adapt if I still want to so some simplication BEFORE tokenization as well as AFTER tokenizaton.

You can do it like this. But it gets a bit clunky if you want to do allot.
SetMetric<String> metric = new CosineSimilarity<String>();
Tokenizer t = new Whitespace();
Simplifier s = new Case.Lower();

String a = "hello worlds";
String b = "hello other worlds!";

String aSimple = s.simplify(a);
String bSimple = s.simplify(b);

// optionally repeat with other simplifiers

Set<String> aTokens =  t.tokenizeToSet(aSimple);
Set<String> bTokens =  t.tokenizeToSet(bSimple);

//apply filtering and transforms on  tokens here

metric.compare(aTokens, bTokens);

Just committed 3806bb5f647ea7988c3acba527ead846f63f1797 which adds the transform step to the builder. After the first tokenize step, you can chain any  tokenize, filter or transform step indefinitely.
StringMetric metric = with(new CosineSimilarity<String>())
		.tokenize(new Whitespace())
		.filter(longWords())
		.transform(removePossessiveS())
		.filter(longWords())
		.tokenize(new QGram(3))
		.transform(...)
		.filter(..)
		.filter(..)
		.transform(...)
		.build();

I hope you don't mind building from source though. The current chaining method isn't as efficient as it can be. I want to have a look at that before I push a new release to maven central.

Thanks I dont mind building from src but I am having git problems, git pull brought nothing new, git checkout develop and then git pull didnt either - not sure what I am doing wrong

Are you pulling from Simmetrics or your own clone?

from simmetrics, i started with git clone https://github.com/Simmetrics/simmetrics.git

I really don't know. The check ins are in the repo. :S

I've just deployed version 3.2.0 of Simmetrics. It should be up on Maven Central in a few hours.
The StringMetricsBuilder can transform tokens after the tokenization step. Repeated filtering and transform operations are sqaushed together. Either with Guava's Predicates.compose and Functions.compose or by internally passing the Filtered and Transformed Collections rather then creating new lists/sets for each step.


Fetch file from private S3 bucket with AWS keys

I am trying to fetch a file from a private s3 bucket that was pushed with DVC. It's not clear to me how I make my AWS keys available to pkgs.dvc-nix.fetch-dvc and if that's even possible. I've got some feedback from the Nix community saying that nothing in Nix supports the AWS Sig 4 protocol which is required to authenticate. On the other hand, there seem to be Nix users who have use cases for making their AWS keys available to Nix. So I find it hard to believe that there are no workarounds.
Is there any way to do this with dvc.nix?

Providing credentials to be accessible during a build in nix is really tricky. This unfortunately gets even worse if you're running with a multi-user installation, because in that case using impureEnvVars isn't really possible, since then the environment variables need to be present when the nix daemon is started, not when you run nix on the command line. One possible way to provide credentials to a build is to a nix build is to pass the --extra-sandbox-paths ... option with a path to your credentials file and then refer to that same path as a string inside the build.
The fetchs3 fetcher in nixpkgs seems to use the aws cli to download the files. This could be a reasonable approach to download the files but this requires either passing credentials that will be stored as plain text in the world-readable store or have a credentials service running on the same machine that the aws s3 cp references during execution.
Moreover, I'll have to update the flake a bit because the packages are using the let bindings and not taking the values from final. This means that overriding fetch-md5-file will not be enough in your case.
In conclusion: There's currently no easy way to support fetching DVC files from a private S3 bucket using dvc.nix but if you're interested in supporting this use case I would be willing to assist you in implementing this.


truncated content in title and description

✔ fix truncated content in title and description - GSearch
✔ Update installation guide in readme
✔ Ignore pycache from testing - .gitignore

amazing😁👌


New service in loki-angular.js

I added an additional service that does a lot of the heavy lifting for the developer in angular, for example, allowing the user to easily load a database from a json file and for the database to automatically re-create if it gets deleted (unless the json file is removed).  The original Lokijs code isn't touched, all i did was add a service called Lokiwork within the loki-angular.js file.  All of my additions are within that service.

Hey, this looks really interesting, thanks!  Normally, @techfort would review this since he wrote the original but I believe he may be offline for a few days or a week or so.
I did notice it looked like you had made changes to the several files which may be specific to your fork.
If you submit a pull request which only includes the loki-angular.js file I'll go ahead and merge that since it is not critical path, but some of the changes to the other files do not look appropriate to merge with main branch.
Thanks!

Closing request because i should have only submitted one file.


React Router with plugin not working

I just followed this guide  and this example but I have a couple of problems in this setup.

When I try to install the plugin I had the error below related to fast-glob package. I think installing this package is missing in the guide:

pnpm add -D @generouted/react-router
Packages: +1
+
Progress: resolved 166, reused 144, downloaded 0, added 0, done

devDependencies:
+ @generouted/react-router 1.7.5

 WARN  Issues with peer dependencies found
.
└─┬ @generouted/react-router 1.7.5
  └── ✕ missing peer fast-glob@>=3
Peer dependencies that should be installed:
  fast-glob@>=3

Done in 2s

Then I tried to install fast-glob manually like this to solve this step and it seems it's working:
pnpm add -D fast-glob

Then I got a type error on my vite.config.ts file as below:

But it seems the routes.gen.tsx file is created for me in the src folder so I think we can ignore this issue for now.

I just added some pages exactly same as the example but I only can see blank pages as a result in the browser.
After switch from plugin setup to the normal setup everything is working without any other changes anywhere. I just replaced this line:

import { Routes } from './routes.gen'

with this:
import { Routes } from 'generouted/react-router'

and installed generouted package rather than @generouted/react-router

I had the exact same issue with you before. Make sure you have to use the  component inside your _app file instead of children

Hey @mnlbox, Thanks for providing all the details!
1 I wanted to ask which vite version are you using?
2 The types should work fine now in vite.config.ts, it was an issue solved in v1.7.6
3 As @brotherko pointed out, there's an issue that requires having pages/_app.tsx file and renders an <Outlet /> component from React Router:
// src/pages/_app.tsx

import { Outlet } from 'react-router-dom'

export default function App() {
  return <Outlet />
}

I'll close this issue after solving issue 3, which is expected as pages/_app.tsx is optional.

Hi @oedotme,
Thanks for your reply. My vite version is 4.1.0.
Ah, good point about that <Outlet /> thanks for the clarification.

@mnlbox Not having a pages/_app.tsx file should also work fine now v1.7.7.
But in case of using pages/_app.tsx, you'll still need an <Outlet /> component to render the children, and I added an example for the optional root layout to the readme.
Lastly for the missing fast-glob installation is fixed at v1.7.8, it should be now installed automatically while installing @generouted/react-router.
Please let me know if all works now as expected!


Setup.py, CI and pytest

Summary

This PR adds our setup.py file, and sets up the CI with pytest and pyright.
After doing pip install -e . in the root directory, you'll be able to import core.... just fine without any import errors.
Testing

Pytest runs, currently failing. Need help from @yolandaw2021
Notes

Comments

[ ] Add an x between the brackets if you commented your code well!

Will be fixing up the failing tests soon! Repo is not yet setup to reject PRs with failing builds, but I will change that soon


chore: creating test topics if they does not exist

Description
creating test topics if they does not exist in the kafka bootsrapper
Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have added tests to cover my changes
[ ] I have made corresponding changes to the documentation

Disclaimer
By sending us your contributions, you are agreeing that your contribution is made subject to the terms of our Contributor Ownership Statement

@fernando-a-marins are you aware of this in KafkaFlow?
https://github.com/Farfetch/kafkaflow/blob/f47446042bc58606f3af92c0163f9fa9358697e6/samples/KafkaFlow.Sample/Program.cs#L21
        .AddCluster(
            cluster => cluster
                .WithBrokers(new[] { "localhost:9092" })
                .CreateTopicIfNotExists(topicName, 6, 1)


Upgrade flex-column and table for Foundation 6.2.

Upgrading our CSS files to use $grid-column-responsive-gutter per https://github.com/zurb/foundation-sites/releases/tag/v6.1.0

Thank you!


Port message actions popover to tippy

Partly fixes #23632

Thanks! Somehow the menu is no longer wide enough to fit all the options in Russian:

Vs. main:

@alya Fixed

@timabbott Marking for integration review. I did not retest manually after the menu width fix, so let me know if you'd like me to do so.

This looks fairly plausible implementation-wise; posted a bunch of comments on various details.

@timabbott addressed all of your comments, thanks!

Pushed an update which now selects message when the actions popover icon is clicked via message_lists.current.select_id(message_id);.

Merged after redoing the comments on 8b6dc955f132841d00f507e8c42d25b56b5545ee, thanks @amanagr!
I'm still not sure this is the simplest correct implementation; in particular, I'm skeptical that tippy_no_propagation is required, since it appears that all the code paths in click_handlers.js that would open the compose box look at whether you click on something inside .message_controls and should noop in that case (For example, is_clickable_message_element should return true for clicks on this toggle element!).
Can you look at what would happen if we just went back to using delegate?
Aside from that, I think we can proceed with migrating other popovers; I would hope that they'll go faster, since we've figured out a few patterns here and in any case, this was one of our more complex popovers to deal with. (I guess stream_popover.js has most of the remaining small ones. Its name is a misnomer; since it's like 5 popovers across the left sidebar; I'd probably be fine with just putting them all into popover_menus.js rather than trying to keep them in a separate file, especially given we've got the popover_menus_data.js split that seems a bit more natural. Though you could try to create a move_topic_popover_menu.js for at least the internal UI code for that 200 line block, and similarly for user_card_popover_menu.js, which I think is the main one in popovers.js that is particularly huge).

Can you look at what would happen if we just went back to using delegate?

Yeah, compose box closes on clicking any of the popover reference elements that use Tippyjs. We can add exceptions to them inside the main click handler ondocument that we have $(document).on("click", (e) => {... for closing compose box but seems more maintainable and cleaner to do it using tippy_no_propagation.


chore(client): remove processIdExpression

We do not support the processIdExpression property as for now, instead processId is the only attribute for call activities available in the properties panel. No validation needed.
I'll leave it in the zeebe.json to have it available via XML Editor and future support.
Closes #130

I think we can ignore the missing code coverage for the removed code.
Open for review @oguzeroglu


Deterministic project file and pods

I noticed if I ran xcodegen a few times, the results were deterministic and no changes showed up on a local diff.
However, if I run pod install afterwards, the results were sometimes different.
How would I avoid such changes so we have a project file that is deterministic?

pod install changes your project. If it does so non-deterministically I'm not sure what we can do

You can post-process your Pods/Pods.xcodeproj with https://github.com/grigorye/xcodeprojFixUUIDs.


Manifest V3

Platform informations

Chrome, Edge
V1.4.2

Issue Description
Manifest version 2 is deprecated, and support will be removed in 2023
Actual behaviour
I cannot use the extension

At the moment it is still possible to use MV2 extensions in Chrome. Now I'm just trying to figure out how to successfully migrate the extension as many things have changed and Mozilla has no plans to support MV3.

Updates in #240


Lint Keras - Text generation with a miniature GPT example

Really enjoyed this small GPT example and noticed a few things. This PR implements a few small changes including spelling fixes, using the sentence-case rule for the title, and adding definite/indefinite articles. Also, "Transformer" is apparently referred to with a capital "T". Any suggestions/feedback welcome. Thanks keras-team and @fchollet 👍

@fchollet I've manually linted the Jupyter, Python and Markdown files. Thanks very much 👋
I'll give python autogen.py add_example ... a try next time if a model doesn't take long to train 👍


feat(monitor): add nodata alert policy

这个 PR 实现什么功能/修复什么问题:
1.add queryConditon子类：nodataQueryCondition处理nodata类型策略
2.遍历Onecloud类型宿主机，得到nodata宿主机信息
是否需要 backport 到之前的 release 分支:
NONE
/cc @zexi
/area monitor

Codecov Report

Merging #8902 (4888f7d) into master (7ee1655) will increase coverage by 11.74%.
The diff coverage is 0.99%.

@@             Coverage Diff             @@
##           master    #8902       +/-   ##
===========================================
+ Coverage    5.91%   17.65%   +11.74%
===========================================
  Files         817       89      -728
  Lines      127615     8948   -118667
===========================================
- Hits         7544     1580     -5964
+ Misses     119394     7194   -112200
+ Partials      677      174      -503

Flag
Coverage Δ

aFlag
17.65% <0.99%> (+11.74%)
:arrow_up:

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

Impacted Files
Coverage Δ

pkg/monitor/alerting/conditions/nodataquery.go
0.99% <0.99%> (ø)

pkg/cloudcommon/db/managed.go

pkg/multicloud/aws/saml_provider.go

pkg/compute/guestdrivers/aws.go

pkg/util/httputils/fs.go

pkg/keystone/models/usages.go

pkg/multicloud/aws/storage.go

pkg/monitor/models/datasource.go

pkg/cloudcommon/db/enabledstatusstandalone.go

pkg/hostman/system_service/sysv.go

... and 720 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 7ee1655...4888f7d. Read the comment docs.

/hold

/cancel hold

/hold cancel

/lgtm
/approve


trivy doesn't have to use a github token

Currently we have to provide a valid github token in order to install with trivy, and download trivy database.
The github token is used for github rate limit, while it is not necessary usually.

GitHub token should be optional

GitHub token should be optional


Windows Update error 0x80070643 during Kernel Update 5.16.10 + Msi says "Enter CD-ROM"

Windows Build Number
Microsoft Windows [Version 10.0.19043.1110]
WSL Version

[X] WSL 2
[ ] WSL 1

Kernel Version
No response
Distro Version
Ubuntu 20.04
Other Software
No response
Repro Steps
Method 1:
run "Check for updates" in Windows Update (UWP settings app)
Method 2:
Download WSL 5.16.10 update from Windows Update Catalog website
Method 3:
Extracted wsl_update_x64.msi from .cab file
Expected Behavior
Method 1:
Windows updates to download and install'
Method 2:
Cab file to install
Method 3:
Msi installer to run and install files
Actual Behavior
Method 1:
Received download error 0x80070643 in Windows Update:

Method 2:
Attempting to install from .cab file produced smartscreen error, "Ran Anyway" - failed before installer started
Method 3:
Msi installer complained about missing CD-ROM.  Opening wsl_update_x64.msi through installer did not satisfy requirements.  I could not find a way to mount .cab file.
Unarchiving the .msi file, I saw a license file and a kernel file.
I also tried Windows Update troubleshooter (built-in) and one downloaded from this link:
I saw an issue about this same problem from 2020 that was closed.  Was pretty depressing.  I backed up my vhd, unregistered, and removed WSL features.  Tired of troubleshooting more than getting work done.
I just wanted you to have the issue so you know it's back.
Diagnostic Logs
No response

I also encountered the same problem, now would you solve it?

Same issue. Windows 11 update can't install update for wsl and running wsl --update also fails.

when I try to install from cab file  it give me this error


Support cudf pin with rapids-cmake

Set cuDF build with pinned rapids-cmakes in POM
Use git download the rapids-cmake in cudf build so that we can get the rapids-cmake's SHA
Update ci/submodule-sync.sh to get the latest cuDF commit and with the latest rapids-cmake

Close https://github.com/NVIDIA/spark-rapids-jni/issues/1666
Main code is copied from https://github.com/robertmaynard/spark-rapids-jni/commit/85f5a2901afe8ae28c945b9d4e58033edef0c85d

build

build

build

build

build


How do I change the height of the image?

Thank you for the great library. How do I increase the height of the image? Even when I use a bigger image, the size of the image on the app layout does not change. Can you please let me know where to make the change.

Was looking at the wrong place. Had to update the activity main and sliding card item xmls :)


Keyboard will automatically pop up every time when I open the sky app.

Nexus  7
Android Version 5.1

I noticed this as well.  I believe this is a regression since the Dart Summit branch was cut.  Possibly as a result of moving the Keyboard service out of sky/services into mojo/services. @jamesr
Since sky_sdk is a generated repository, we should track this as an issue in the mojo repo:
https://github.com/domokit/mojo/issues/141
Thanks for the report!


Usage with Checkboxes

Hey all -
I'm trying to use v4 with Material-UI Checkboxes, and am experiencing some strange behavior.
const Checkbox = ({
  field,
  label,
  checked,
}) => {

    const {
        getInputProps,
        value,
    } = useField(field, {
        defaultValue: checked,
    });

    return (
        <FormControlLabel control={
            <MuiCheckbox
                {...getInputProps()}
                checked={value}
            />
        } label={label} />
    );
};

Here's a stripped down version of my component. This works when I pass a default value of true or false but the output of the value is a stringified "true" or "false" after I manipulate the checkbox in the UI. Is there a way to tell react-form that this field is supposed to be a checkbox boolean, or do i need to add handling for stringified booleans to my code base?

const Checkbox = ({
  field,
  label,
  checked,
}) => {

    const {
        getInputProps,
        setValue,
    } = useField(field, {
        defaultValue: checked,
    });

    const onChange = (e) => {
      setValue(e.target.checked);
    }

    return (
        <FormControlLabel control={
            <MuiCheckbox
                {...getInputProps()}
                onChange={onChange}
            />
        } label={label} />
    );
};

This works, with a custom onChange that calls setValue. It just feels like there should be an easier way. I tried filterValue but returning false caused the stored value to not update.

I went down the same path as @timcosta.  Seems like checkboxes don’t play by the same rules as other inputs, since they use defaultChecked and checked for their value, and this might be confusing this library if it expects the value to be coming from value.
A simple example of how to use react-form with <input type="checkbox"> would be helpful.

@jacksonrayhamilton here's an updated version of what i'm using, with support for creating an array based on a set of checkbox values.
import React from 'react';
import PropTypes from 'prop-types';
import { useField } from 'react-form';
import { Checkbox as MuiCheckbox, FormControlLabel } from '@material-ui/core';

const findValueInArray = (array = [], value) => {
  if (typeof value === 'object' && value.constructor === Object && value.id) {
    return array.findIndex((i) => i.id === value.id);
  }
  return array.indexOf(value);
}

const Checkbox = ({
  field,
  label,
  isArray,
  value,
}) => {

    if (isArray && !value) throw new Error('Checkboxes that are used as for array must have a value.');
    const methods = useField(field);
    let currentValue = methods.value;
    if (currentValue === undefined) {
      if (isArray) {
        currentValue = [];
      } else {
        currentValue = false;
      }
      methods.setValue(currentValue);
    }

    const onChange = (e) => {
      if (e.target.checked) {
        if (isArray) {
          methods.pushValue(value);
        } else {
          methods.setValue(value || e.target.checked);
        }
      } else {
        if (isArray) {
          const idx = findValueInArray(methods.value, value);
          if (idx > -1) methods.removeValue(idx);
        } else {
          methods.setValue(value ? undefined : false);
        }
      }
    }

    return (
        <FormControlLabel control={
            <MuiCheckbox
                {...methods.getInputProps()}
                checked={isArray ? findValueInArray(methods.value, value) > -1 : currentValue}
                onChange={onChange}
                value={value}
            />
        } label={label} />
    );
};

Checkbox.propTypes = {
  label: PropTypes.string.isRequired,
  field: PropTypes.string.isRequired,
  isArray: PropTypes.bool,
  value: PropTypes.any,
};

Checkbox.defaultProps = {};

export default Checkbox;

It's not the cleanest, but it supports create and edit (via defaultValues on useForm) for both single and group/array checkboxes. Can probably be optimized from a perf perspective with some useMemo or useEffect hooks.

Thanks Tim for this!  When I said “A simple example … would be helpful,” I actually meant to direct that to the package maintainer.  Since you said “It just feels like there should be an easier way,” and since I agree with that, I was hoping we could get a canonical answer; one which would hopefully feel consistent with the style used for other inputs.

Definitely agreed, it would be great to have official checkbox support. Just wanted to share how I solved it as to unblock you just in case.

Hey all, I'm closing this issue as it appears to be related to a version of the old non-current @tanstack/react-form and friend APIs. We're looking to 1.x soon enough, and I want to more easily filter down to more recent issues.
Thanks for being early adopters of our tooling! We know that it can lead to issues like this being unresolved sometimes, but we're working hard on the new iteration of Form.
Maybe take a look and let us know what you think?
https://tanstack.com/form
Best,

Corbin


Colored tabs or Tab division by connection.

Is your feature request related to a problem? Please describe.
It is too hard to indistinguishable many tabs.
Describe the solution you'd like
Colored tabs / Tab division by connection.
I saw this requests at past, but it's been a long time since then.
Is there a solution now?
https://dbeaver.io/forum/viewtopic.php?f=3&t=916
https://github.com/dbeaver/dbeaver/issues/300
https://github.com/dbeaver/dbeaver/issues/1777

thanks for the suggestion

This feature would be awesome.
To illustrate what I would need (And what @moonjoungyoung described) :

The areas in 1, 2 and 3 are colored
The tabs in 4 are not, and as the screenshot shows: To which connection each tab belong to? we can't know without opening them.

This feature would solve this problem 😃

This feature would be awesome.
To illustrate what I would need (And what @moonjoungyoung described) :

The areas in 1, 2 and 3 are colored
The tabs in 4 are not, and as the screenshot shows: To which connection each tab belong to? we can't know without opening them.

This feature would solve this problem 😃

Agree, any option (colors or tabs grouped by connexion) would be really helpful.

This would be greatly benefic; for example, use cases where one has several similar/identic databases and not able to distinguish betweeb tabs.

I need this feature "group tab by connection", it will be very useful.
Often I too open several databases with same name on different servers.

Really nice would be a solution like the Chrome Browser to group tabs. Thanks

@bmoAtolcd and @LoloIrie , something like this: #3027 ?

There is any temporal workaround to somehow difference 2 open tables from different sources, without switching to each one?

@bmoAtolcd and @LoloIrie , something like this: #3027 ?

interesting but not realy that i want.
I need something that group tab by connection, perhaps a tab by connection with have child-tabs.


k8s doc https://github.com/apache/skywalking-kubernetes

update K8s doc.

Codecov Report

Merging #4715 into master will decrease coverage by 51.05%.
The diff coverage is n/a.

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


Appending AdditionalLibraries to command line

Hi
I've tried xamguard in windows and I have a problem with the command line, it build something like this
 c:\...\proguard.bat -injars obj\Release\android\bin\classes -outjar obj\Release\android\proguard\java -injars c:\...\Components\googleplayservices-<IP_ADDRESS>\lib\android\19\content\google-play-services/libproject/google-play-services_lib/libs/google-play-services.jar:c:\...\Local\Xamarin\Android.Support.v13\20.0.0\content\support/v13/android-support-v13.jar:c:\...\Local\Xamarin\Android.Support.v7.AppCompat\20.0.0\content\support/v7/appcompat/libs/android-support-v7-appcompat.jar:c:\...\Local\Xamarin\Android.Support.v7.MediaRouter\19.1.0\content\support/v7/mediarouter/libs/android-support-v7-mediarouter.jar -outjar obj\Release\android\proguard\additional -injars obj\Release\android\proguard\tmp\library_projects -outjar obj\Release\android\proguard\library_projects -libraryjars c:\...\Local\Android\android-sdk\platforms\android-19\android.jar -libraryjars "c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\MonoAndroid\v4.4\mono.android.jar\" -include obj\Release\proguard-generated.cfg -include Proguard.cfg

An this is the error
PROGUARD : error : Can't read ... (No such file or directory)
So I'm think the error is with this line (https://github.com/roosmaa/XamGuard/blob/df6f2b58a9d352dd11f31cab88bcd41486ef8f08/Proguard.Build.Tasks/Tasks/Proguard.cs#L79) instead of use : as a separator between jars it should be ;
or add a conditinal with the OS.IsWindows
or I should just create a PR....
Cheers

I've hit this bug too, it makes ProGuard almost useless. When will there be a fix?

Since I don't have a Windows machine anywhere I can't really do anything about it. But you're more than welcome to submit a pull request.

Thank you for the fast reply, let me see if the fix with ; works and I'll send you one.

It works. Before I send the pull request: should I only use ; just on Windows or does it work on the other platforms too?

There's the pull: https://github.com/roosmaa/XamGuard/pull/10 .

Thanks. :+1:  Will make a new Nuget release in a moment :)

You're welcome. I am afraid, however, that it seems I cannot use XamGuard after all. It drops much Java code that is actually used by bindings. Adjusting Proguard.cfg seems to have no effect because the same classes remain missing.

You should inspect obj/Release/proguard-generated.cfg file to see if the binding stuff really isn't discovered by XamGuard. Does the bindings library have RegisterAttribute for all of the generated classes?
You can always customise Proguard.cfg if all else fails. For example checkout Toggl mobile app's Proguard.cfg.

Thank you for this advice. I will take a took.


Ensure Enumerable#to_a and Enumerable#tally properly retain return type of T

Fixes #14440

Welp, seems wasm doesn't like this new spec...

Yeah, something's really funky about the failures on macos and wasm.

I'm actually able to reproduce this on my intel mac with LLVM 17. Reproduces when running the whole of std_spec, or both specs together, but not when running the new modified specs on their own.
I'll play around with it and see if I can get a more minimal example...

I think the gist of this is it's caused by having two private types typed as an interface interfering with each other when required from separate files.
E.g.
# test2.cr
module OtherInterface; end

private record One do
  include OtherInterface
end

private record Two do
  include OtherInterface
end

([One.new, Two.new] of OtherInterface) == [One.new, Two.new]

Then:
# test.cr
require "./test2"

module OtherInterface; end

private record One do
  include OtherInterface
end

private record Two do
  include OtherInterface
end

pp [One.new, Two.new] == [One.new, Two.new]

Results in:
$ crystal test.cr
Program exited because of an invalid instruction

If I had to guess, I'd say something regarding the "private to the file" thing isn't working out exactly as we expect giving one or the other files a reference to the other?


Implement RFC 35: Add ShapeLike, ValueLike

RFC PR: https://github.com/amaranth-lang/rfcs/pull/35
Implementation PR: https://github.com/amaranth-lang/amaranth/pull/983

Implemented.


RFC - Zero-Sized References

Rendered

Is it possible to do this in a library with PhantomData<&'a ()>?

The main purpose is to help with polymorphic code, that usually doesn't deal with ZST.

Rendered

IIRC we haven't pursued this idea in the past because of the potential for breakage involved.

I disagree completely with this change. & pointers are still pointers, and people trust that they don't change address.

This would also make references not extern "C" compatible, which is a major breaking change; if someone uses a ZST to represent an opaque type, for example.

Shouldn't extern "C" use pointers anyway? C doesn't have references the way Rust does...

"Breaking code" is a drawback big enough to make this Rust 2.0 material

Even in an hypothetical Rust 2.0 (which by the way I hope won’t happen for many years!), breaking code that uses &ZST as a way to implement &Opaque is disruptive enough that it shouldn’t be done.
A zero-size reference-like thing can be useful, but I think it should be a separate type. Something like:
// Does not implement Deref
pub struct ZeroSizedRef<'a, T>(std::marker::PhantomData<&'a T>);

A couple points I want to add (a bit meta):

I am not as much pushing this RFC, as opening it for debate. I have heard strong opinions in both directions, and would like to have a discussion to come to an agreement. We could then point people towards this discussion whenever questions arise.

The discussion of this RFC is expected to drift towards the definition of & and it's valid / invalid uses. That is intended and should be counted as on-topic.

Also, clarification about breaking code:
I want to find a solution that will not break valid unsafe code. I have no strong opinion about breaking non-valid unsafe code. However, since I have little knowledge about much of the unsafe code in the wild, the specifics of these should be discussed here.

AFAICT there's two basic use cases here, which are both valid, but in tension:

If data structures with custom allocators store references to their allocators, and you define some global allocator with a ZST just to identify it, it would be unfortunate if data structures instantiated with it as their allocator had to physically store pointers which don't actually point to anything useful. (N.B. I'm not sure I have the details of this right, but there are probably analogous cases even if I don't.)

FFI code wants to use ZSTs (or similar) as stand-ins for foreign types, with &ZST containing no useful information on the Rust side, but faithfully preserving the memory address for when it is passed back into foreign code. (The extern type or OpaqueData RFCs might provide a not-technically-ZST option, but in any case we can't break code using the currently-existing one.)

How about an opt-in approach where authors can tag specific zero-sized types with "references to this type should also be ZSTs"? That satisfies the allocator use case (with a bit of manual annotation) without affecting any existing code. (My suspicion is that generic code would not pose a problem either because Rust implements it exclusively with monomorphization, but I haven't thought about it very deeply!)

You can transmute from/to &T with a generic T. So you'd need a trait that types opt out of and is present as a bound by default (i.e. like Sized), or some code will still break.

@eddyb Is there actually generic code in the wild which does it? (I'm not doubtful, simply ignorant.)

Yes, we had to add a special-case because there were about a dozen (IIRC) crates which transmuted between pointers to T: ?Sized. I never actually checked how many would break if we pretended we didn't know the layout of pointers to T: Sized, but if the standard library doesn't abuse it then we could experiment with a small check for "does this type contain any type parameters?" (instead of "is it sized?").

@RalfJung no. If you want more info, hit me up on irc, I don't want to write it up here.

@ubsan I would argue that the extern "C" function should have C-level types (raw pointers, no Box etc.), and then one writes a wrapper around it using more Rustic types. This avoids making assumptions about the layout if the Rust types.
But maybe that doesn't actually work so well, and anyway it's enough for some people to write libraries the way you propose to make this a problem.

@eddyb Hmm, what if both pointers and references to such opted-in types were ZSTs, with a fixed address of 0xAlign? Would that solve the transmute problem, and would it introduce any others? It seems like it would avoid any kind of FFI issues unless people deliberately aim at their own feet.

ZSTs, with a fixed address of 0xAlign

What does that mean? A by-value coercion? Then this will still silently break code which doesn't use transmute.

@eddyb Can you give an example of what kind of code you're thinking of? I just mean that both *const ZST and &ZST would themselves be ZSTs, and whenever the actual value of the address is required (e.g. *const ZST as usize), it would be 0x1 (alignment was a silly thought, given that ZSTs don't really have differing alignments).
Hmm... that would break ptr::null() though. And making the value always be 0x0 instead would probably break &T, which is supposed to be non-zero. So I guess this doesn't really work out...

@glaebhoerl We really shouldn't touch *const ZST, since it carries extra data (null or non-null) it can't be ZST itself.

there were about a dozen (IIRC) crates which transmuted between pointers to T: ?Sized.

@eddyb Pointers to T: ?Sized are not affected by this though? Since we only affect the references to structs of known size, references to trait objects are unaffected. References transmuted between each other will be affected only if the target is of different sizes... which IIRC would be an error anyway? And no sort of pointer would be affected. And I don't thik people transmute between *const ZST and &ZST since they could just use as for that. Are there other cases I didn't think of?

@ubsan The specific examples you showed didn't use a ZST. For examples with ZST, the next comes to mind:
struct OpaqueStruct;

extern "C" {
  fn some_fn(s: &OpaqueStruct);
}

but I think it could be enough to allow writing the next
unsafe impl !Sized for OpaqueStruct {}

and give an error that hints of the fix, something like Can't use references to ZST in extern "C", consider adding "unsafe impl !Sized for OpaqueStruct {}".
Would this much be enough? The code will not silently break, and the fix is given + straightforward.
Note that writing the unsafe impl !Sized would probably disallow instantiating the struct on rust's side, but I can't even come up with a single case where you would send a pointer to a REAL ZST to C code.

@EpicatSupercell My point was that there were even transmutes between T: ?Sized pointers, so we had to support those, on top of T: Sized pointers (which have a known size).

@eddyb Is it valid to transmute between pointers to different known sizes? So transmute &u8 to &u16 for example.

@EpicatSupercell It has always been valid. Transmute only cares about immediate size, which is the same for all pointers to sized types.

And I don't think people transmute between *const ZST and &ZST since they could just use as for that.

Strictly speaking, transmute was a mistake for almost everything it's commonly used for nowadays and I wish I hadn't seen some of the usage in the wild - the compiler should complain more.
Sadly https://github.com/rust-lang/rust/pull/32939 doesn't seem to link to the original crater report, so I can't show you the examples for T: ?Sized that I was mentioning earlier.

We really shouldn't touch *const ZST, since it carries extra data (null or non-null) it can't be ZST itself.

...Yes. That's what I said.

@eddyb Actually since &ZST and *const ZST ARE of different immediate size, the real question is whether we care about breaking the code that uses it like that. Honestly I'd hate to do that, but I feel like if we care TOO much about maintaining backwards compatibility, we'll end up worse than C++ in no time. If the use was never correct, AND it's in unsafe block, AND there are better solutions anyway, AND we give an error message instead of silently breaking, it might be fine to break it?

@EpicatSupercell If you can always detect it (which you can't because you can emulate transmute in stable code with raw pointers), then you can evaluate the impact right now, without waiting.
The typical usage scenario that we enabled was actually a transmute between two pointers with the same unknown potentially-unsized trailing type, so that would take over when working with Sized pointees, if their size cannot be computed statically, but only in some cases.
If you really feel confident enough that this scheme can work, I can implement the check (just the transmute compile errors), it's really just making the layout of &T depend on that of T.

I suppose more generally, a reference is isomorphic to the type itself, meaning for any type (even implementing Drop) with sizeof(T) <= sizeof(*const T) and no interior mutability, any reference could be stored more efficiently as the value itself.
At least that's what I'd like to be able to say. There are plenty of reasons this won't work, which is a shame.

&7 as *const i32 is perfectly safe code which cannot be implemented if &i32 is stored by value
&T as *const T as *const u8 is used often in unsafe code to copy bytes from one type to another
&T as *const T as usize is valid today - something to think about
A generic function with transmute will compile today but fail if even zero-sized references are introduced
&T as &Trait is valid today - this could be worked out but of course you don't benefit from reducing the size of the type here - also some unsafe code is probably going to break if &Trait contains an inlined value instead of a reference

Let's see how these examples will change after the change!

&7 as *const i32 is unaffected, because not ZST
&T as *const T as *const u8 allows you to copy all 0 bytes of the ZST... from a random location (lets say 0x1). Since it doesn't matter where you copy 0 bytes from, no change here.
&T as *const T as usize will now give the address assigned right now (0x1) instead of a different arbitrary address of a ZST.
Generic function with transmute - between which two types? It matters.
 Now it generates a fat pointer from a new address (0x1) and the correct V-table. So, still correct.

&T as *const T as usize will now give the address assigned right now (0x1) instead of a different arbitrary address of a ZST.

This one I worry about. e.g. the following code would break:
let x = ();
let _spacer = 0;
let y = ();
assert!(&x as *const () != &y as *const ())

Aside - if you take the references first, you get the opposite behaviour, with the pointers equal to 0x1
let x = &();
let _spacer = 0;
let y = &();
assert!(x as *const () == y as *const ())

Also have to deal with the following behaviour:
let tuple = ((), ());
assert!(&tuple.0 as *const () == &tuple.1 as *const ());

Actually that code never was guaranteed to work, since LLVM is allowed to reorder variables how it sees fit.

Ok if that's the case it's not the end of the world (for ZSTs at least) - just pointing out that there are some legitimate purely-safe-code programs that could in theory fail from this change - but if those programs were never guaranteed to work then that's just fine.

whenever the actual value of the address is required (e.g. *const ZST as usize), it would be 0x1 (alignment was a silly thought, given that ZSTs don't really have differing alignments).

They do: [T; 0] has the alignment of T.

To provide a concrete example, relying on the address of &ZST is already a broken assumption because:

The standard library itself will already cook up arbitrary pointers to ZSTs at address 0x1.
ref_slice was deemed legal but useless.

One can already throw away the address of a ZST reference in safe code by calling, ref_slice(zst_ref).iter().next().unwrap(). Any FFI code relying on the value of &ZST as *const SomeCType is already unsafe.

@Stebalien Fair enough, but that's not what I personally question, rather the behavior of generic code assuming the size of &T for T: Sized.

@RalfJung why write a wrapper around it if you don't need to? Also, again, types are better documentation than documentation. What's the difference between these three functions?
extern "C" {
  fn foo1(x: *mut T);
  fn foo2(x: *mut T);
  fn foo3(x: *mut T);
}

can you tell now?
extern "C" {
  fn foo1(x: Option<&mut T>);
  fn foo2(x: &Cell<T>);
  fn foo3(x: CBox<T>);
}

Also, I hate the assumption here that somehow, unsafe code is less important (and it's less of a bad thing to break it). Unsafe code is far more bad to break, because they have assumptions that, if broken, will cause undefined behavior.

@ubsan: You are making lots of assumptions about data layout here, which I find very worrying. See e.g. https://github.com/rust-lang/rfcs/pull/1758 -- there's no guarantee currently that transmuting between T and Cell<T> makes any sense, and yet that's exactly what you are doing.

@RalfJung I'm making exactly the assumptions that the standard library makes.

@RalfJung Isn't there an accepted &mut T -> &Cell<T> RFC? That pretty much guarantees it.

@ubsan

Also, these aren't transmutes, they're pointer-based type punning.

I don't see the distinction. Transmute could well be implemented using pointer type casting.
@eddyb

Isn't there an accepted &mut T -> &Cell RFC? That pretty much guarantees it.

Ah, right, there is.

@RalfJung no it couldn't be, due to alignment requirements. pointer-based type punning is different from memcpy-based type punning.

Personally, I'd love to just make *const ZST zero sized. This will cause lots of existing code to not compile but, IMO, that code is already wrong. The "correct" way to do this is to define an opaque type , as documented in the nomicon is enum Opaque {}.
However, given that we're living in the real world with people who will complain if their code breaks even if they're relying on UB, we probably can't do this :(.

But, to be pedantic, I'm going to try to redirect this discussion because it's coming to the right conclusions for the right reasons by the wrong arguments.
@ubsan

Unsafe code is far more bad to break, because they have assumptions that, if broken, will cause undefined behavior.

There's no such thing as "causing undefined behavior". The behavior of unsafe code that makes invalid assumptions is always undefined, regardless of whether or not it happens to work and we cannot be scared of breaking code that relies on undefined behavior lest we never optimize/fix bugs. The questions to ask are:

Are we breaking defined behavior?
If we are changing undefined behavior, should we introduce a deprecation period/warning?
If we are changing entrenched undefined behavior, should just define it?

In this case, the only truly defined behavior I see this breaking is size_of::<Option<&T>>() == size_of::<&T>() (which we do specify). However, this assumption is only directly useful in FFI where using &ZSTs are already provably broken.
The other possibly defined behavior that this would break is that size_of::<&ZST>() == size_of::<*const ZST>() (or even just size_of::<&ZST>() > 0).  However, I can't find anything documenting this behavior. On the other hand, size_of::<&ZST>() > 0 could be implied by size_of::<Option<&T>>() > size_of::<&T>() (&T can't be a ZST bcause Option<&T> can't).
At the end of the day, I think this RFC will likely fall into category 3. Therefore, if we decide to close this RFC, we'll have a golden opportunity to actually define some currently undefined behavior (the assumptions we've decided are too important to break).

@eddyb

Fair enough, but that's not what I personally question, rather the behavior of generic code assuming the size of &T for T: Sized.

Is that actually defined anywhere? That is, isn't that why we haven't specified any of this stuff (so we have room to change and optimize representation)?

The "correct" way to do this is to define an opaque type , as documented in the nomicon is enum Opaque {}.

Oh no, the nomicon says that? I didn't know :( . I think that's horribly wrong. That opaque type states that it is empty. Passing an element of &Opaque around is super-dangerous. That's a whole separate discussion though, see https://internals.rust-lang.org/t/recent-change-to-make-exhaustiveness-and-uninhabited-types-play-nicer-together/4602 and https://github.com/rust-lang/rfcs/pull/1861.
Ironically, the usual advice here (with which I agree) is to use an uninstantiable ZST instead:
mod opaque {
  struct Opaque { _priv: () }
}
use opaque::Opaque;

There's no such thing as "causing undefined behavior". The behavior of unsafe code that makes invalid assumptions is always undefined, regardless of whether or not it happens to work and we cannot be scared of breaking code that relies on undefined behavior lest we never optimize/fix bugs.

We haven't even figured out what exactly these assumptions are yet, so you cannot blame anyone for violating them.

Is that actually defined anywhere? That is, isn't that why we haven't specified any of this stuff (so we have room to change and optimize representation)?

The reason we haven't specified any of this is that we just don't know what the spec should be. Also see https://internals.rust-lang.org/t/next-steps-for-unsafe-code-guidelines/3864.

@Stebalien uh, no. That's not how undefined behavior works. In fact, we've defined that a reference is just a pointer in the past, so this would be making previously defined behavior different.
UB has a very specific definition. Unsafe code making invalid assumptions does not constitute.

(although unsafe code making invalid assumptions can cause UB. for example, relying on drop order can result in UB, but is not necessarily undefined behavior in and of itself.)

That there is what's known as "unspecified behavior", which is very different from UB.

@RalfJung

We haven't even figured out what exactly these assumptions are yet, so you cannot blame anyone for violating them.

We absolutely can "blame" (not really the right word) code for making assumptions about currently undefined behavior. If we haven't defined it, you can't rely on it.

The reason we haven't specified any of this is that we just don't know what the spec should be.

You're assuming that there exists a golden spec out there that all rust code obeys, we just haven't figured out how to write it down yet; that's not the case. There's plenty of rust code that works today that will probably break tomorrow because we decide that something that code does is invalid (this happened, e.g., when we enabled field reordering).

@ubsan
I was reacting to the debate about changing unspecified assumptions somehow introducing UB where it previously didn't exist but I clearly wasn't clear about that.
One can "cause" UB if we change specified behavior (modulo the semantics of  "cause UB" versus "cause programs to invoke UB"). I should have said one can't cause (programs to invoke) UB by changing unspecified behavior because programs relying on such unspecified behavior to avoid UB already invoke UB. Many of the assumptions I've seen discussed in this thread are, to the best of my knowledge, relying on unspecified behavior.

In fact, we've defined that a reference is just a pointer in the past, so this would be making previously defined behavior different.

By "we've defined that a reference is just a pointer", I assume you mean that &T should have the same representation as *const T (not that &T is literally just a pointer because that's obviously not the case for DSTs). If so, this is already broken with or without this RFC given that stdlib already plays it fast-and-loose with the value of &ZST. However, I agree that that's a problem. As I've stated, I believe that the correct solution would be to make *const T zero sized but that would break lots of things.

That there is what's known as "unspecified behavior", which is very different from UB.

You're right, I need to get my terms straight before correcting others. So, I'll try this again...

There's no such thing as "causing undefined behavior" in programs that already rely on unspecified behavior to avoid invoking undefined behavior. The behavior of unsafe code that makes invalid assumptions (to avoid UB) is always undefined, regardless of whether or not it happens to work and we cannot be scared of breaking code that relies on undefined unspecified behavior lest we never optimize/fix bugs. The questions to ask are:

Are we ~breaking defined~ changing specified behavior?
If we are changing ~undefined~ unspecified behavior, should we introduce a deprecation period/warning?
If we are changing entrenched ~undefined~ unspecified behavior, should just ~define~ specify it?

In this case, the only truly ~defined~ specified behavior I see this changing is size_of::<Option<&T>>() == size_of::<&T>() (which we do specify). However, this assumption is only directly useful in FFI where using &ZSTs are already provably broken.
The other possibly ~defined~ specified behavior that this would break is that size_of::<&ZST>() == size_of::<*const ZST>() (or even just size_of::<&ZST>() > 0). However, I can't find anything documenting this behavior. On the other hand, size_of::<&ZST>() > 0 could be implied by size_of::<Option<&T>>() > size_of::<&T>() (&T can't be a ZST because Option<&T> can't).
At the end of the day, I think this RFC will likely fall into category 3. Therefore, if we decide to close this RFC, we'll have a golden opportunity to actually ~define~ specify some currently ~undefined~ unspecified behavior (the assumptions we've decided are too important to break).

@Stebalien I'd argue that it's at least an implicit guarantee, if not an explicit one. Especially given that I use this in my own code, and it's likely being used in others' code...

@RalfJung FWIW in Stylo we regularly use &T in FFI for the reason @ubsan mentioned; it's self documenting and also gives some lifetime bounds. It's been very useful. &ZST is a very common pattern in Rust FFI.
We also use Option<&T> for "nullable but valid" pointers, though we understand that that's not an optimization we are allowed to rely on (there are tests ensuring that it still works). I think we make similar assumptions about UnsafeCell (hence the repr(transparent) RFC), so that we can safely use aliased C++ types without noalias making things UB.

Given that Rust's unsafe code semantics are currently unspecified, IMO it's not very productive to look at it from a "blame" point of view.  It is very easy to abdicate all responsibility for "incorrect" unsafe code, however correctness is a very fuzzy concept right now.
A more useful metric is "would it be reasonable to assume this works?". References being the same as a raw pointer internally is IMO a reasonable assumption, more so given the fact that the nomicon actually recommends using ZSTs for void (and this has been a common pattern within the community far predating the nomicon). OTOH, for example, expecting Option<&T> to always be a single word in size may not be as reasonable an assumption; which is why stylo takes all responsibility for this breaking and has tests.
Ultimately, it may be the fault of the writers of unsafe code that their code breaks. However, if this is a more widespread pattern, we should still take it into account. I agree with @ubsan that if anything this is one of the places where we should apply more scrutiny, because this has the potential to cause UB if not handled right.
Not really saying anyone is doing so yet, but this is reminding me of the discussions on the drop order bug where many folks were ignoring the impact on existing code with "but well it's their fault so it's not our problem", and I'd like to preempt that 😄

References being the same as a raw pointer internally is IMO a reasonable assumption,

That would not be violated by "also make pointers to ZST be themselves ZST". (Not that I think that's actually an option.)
I am curious though -- raw pointers to unsized types are already quite different from C pointers; I assume this means people have to be careful not to use pointers to unsized types in their FFI?

given the fact that the nomicon actually recommends using ZSTs for void

Actually, it does not :(

Not really saying anyone is doing so yet, but this is reminding me of the discussions on the drop order bug where many folks were ignoring the impact on existing code with "but well it's their fault so it's not our problem", and I'd like to preempt that 😄

Fully agreed.

Given current FFI uses, it's clear this can't be implemented without at the very least introducing and stabilizing some sort of opaque FFI type and having a transition period during which the compiler complains with increasing severity when a ZST is used with FFI. That seems both doable and desirable, given the many issues that ZSTs can have in an FFI context, despite currently being one of the least-bad alternatives.
That leaves the question of how much non-FFI code exists that relies on preserving and passing/storing the underlying pointer value for references to ZSTs, which I would imagine is not much.
Another issue brought up is generic code expecting &T to be a consistent size for all T: Sized. One thought I had here (which I admittedly have not fully thought through), is that if we say all ZSTs live at 0x1 and that creating an &T with a pointer value other than that is undefined behavior, then I think we can treat &ZST as semantically pointer sized, but still avoid passing/storing it in many cases.
That said, if we can find a way to make &ZST semantically zero sized, I feel it would be a cleaner solution.

I do find the ideas in this RFC very appealing, but it seems to me that there are some pretty strong backwards compatibility concerns:

There is tons of precedent that a &T and a *const T are representation-compatible, and that &ZST (or *const ZST) is a reasonable encoding of an opaque type.
As @eddyb pointed out, we permit transmutes between &T and &U so long as T: Sized and U: Sized. The intention of these rules is to guarantee statically that the types have the same size. Clearly these rules would either have to be changed (causing code to stop compiling) or would become far less useful (causing weird errors).

In short, there seems to be a lot of precedent in favor of the assumption that &T (where T: Sized) is always a pointer, even if it it's sometimes a dummy one. And while I do think we have some amount of license to specify previously unspecified behaviors, which may cause breakage in unsafe code in the wild, we have to be pragmatic about it, and this change doesn't seem to offer enough upsides. If we did want to do this change, it seems like some more explicit opt-in would be better (e.g., a library type or something).
I therefore move to close this RFC (with thanks to the author for the enlightening discussion).
@rfcbot fcp close

I kind of agree. Probably should mark this down as a rust-2.0 wishlist idea. Then we could consider e.g. storing immutable reference to bool as a single bit/byte and other extensions if they make sense. Get that bit-twiddling efficiency out of the programmer's mind and into zero-cost abstractions ;)
null

We avoid significant breakage because it would be harmful to the ecosystem, not just to satisfy semver lawyers. “Rust 2.0”, if it ever happens, is not a license to introduce any and every kind of breakage.

Of course - we don't want to just break everything - but in this case the breakage is in (specific) unsafe code only - the surface area of which I feel is acceptable for major version breakage. Basically any nontrivial change in e.g. how trait objects work, how nested enums are represented, extending the null pointer optimization - would require the same kind of breakage. So I feel the total benefits of allowing just this kind of breakage would be worth it.
On a side note - IMHO it feels very "wrong" the way zsts are used for ffi. It seems like it breaks the assumptions of many potential optimizations anyway, leading to potential unsoundness down the line. There should probably at least be a better way to represent opaque types even if this particular optimization is never implemented.
null

There should probably at least be a better way to represent opaque types even if this particular optimization is never implemented.

https://github.com/rust-lang/rfcs/pull/1861 is already being merged, thankfully.

With the approaching resolution of #1861 we get a tool for FFI to solve some concerns. The other concerns are about unspecified behavior. I am not in favor of breaking code, so right now this RFC is inapplicable.
However, with the additions of epochs, a new possibility opens for us - allowing only references from a newer epoch to be ZST, while keeping all current code working. This RFC sounds fitting for a test run of epochs (assuming it's accepted in the first place). I'm not sure if now is a fitting time for it or not.
On a side note, due to personal circumstances, I didn't have the time to manage this RFC at all this past month :(

A requirement for epoch's is that "if your code compiles in the previous epoch without warnings, then it will keep working in the next epoch". So we'd need to be able to reliably warn for any code that relies on the data layout of &ZST. That seems like a tough call...

It sounds possible to me. You make &ZST be Zero-Sized in the new epoch (= new code) and non Zero-Sized in the old epoch. When calling a function from old epoch or using a struct from old epoch you generate a value for the reference so it's no longer Zero-Sized, and when you receive a value from one you drop it so it's Zero-Sized again. Old code keeps working because it's never ZST, new code will not allow you to do illegal operations anyway.

That's still not epoch-compatible -- you can't just "generate a value for the reference", the value has to still be correct if you don't want to break backwards compatibility. Remember, using &ZST for holding references to opaque C-managed types is a common, recommended pattern for Rust FFI. Generating fake values will not fix this situation, it will only make it compile.
And the struct thing won't work at all, we can't have different representations for the same struct across crates; it would not allow them to be shared.
Epoches allow for breaking changes that are not in the core language, as defined in the RFC. I'd argue that this is definitely a change to the core language since it observably changes representations.

different representations for the same struct

Different representation depending on where it is defined, not used. Therefore a use of an epoch 1 struct in epoch 2 code will follow conventions of epoch 1 struct, while checking the size of an epoch 2 struct containing &ZST will return size 0 even in epoch 1 code.

using &ZST for holding references to opaque C-managed types is a common, recommended pattern for Rust FFI

I come with the assumption that #1861 becomes the standard and '& extern type' becomes the recommended pattern. In that case &ZST stops being recommended and becomes an anti-pattern (and possibly warning/error).

I come with the assumption that #1861 becomes the standard and & extern type becomes the recommended pattern. In that case &ZST stops being recommended and becomes an anti-pattern (and possibly warning/error).

Antipattern or not, you still can't change the behavior in current epoch.
Rather, the compiler would have to emit warnings wherever code would not work for ZST references. This includes FFI, casts to/from usize, various transmutes, raw pointers of ZST types, etc.
The problematic part, however, is that generic code couldn't do those things on any generic references at all, unless a new auto-trait for non-ZSTs is added first (or ZSTs were removed from the Sized bound, which again, wouldn't be backwards compatible).

With respect to interaction between epochs, imagine a specific case where epoch 2 code uses an epoch 1 FFI library that, for whatever irrelevant reason, passes around opaque payload as type &(). Epoch 2 code cannot just handle that &() from epoch 1 as a zero-sized reference, because it would conflict with the requirement that epoch 1 crates can be used in epoch 2 projects.
So for one thing, epoch 2 would need to understand its own &() as a different type from &() in epoch 1 functions. It would also need a way to use epoch 1 &() values, and name that legacy type in function signatures etc.
In other words, it would be possible, but it would be no small feat.

Guess it could be possible in that case to create a type called Epoch_1::LegacyZST (which is equal to legacy &()) and have the compiler complain that you try to assign a value of type LegacyZST to a type &(). Can't say it's very elegant, but is relatively simple.
My main reason I try and find a way to make this work is because I fear that if we decide a feature as simple (in my opinion) as this can't be used with Epochs, we will never be able to add any serious features without a major version (Rust 2.0). And with the collective desire to not go that route, I fear the language will stagnate even faster than C.

I have some thoughts. I'm afraid I have no conclusions. It seems to me there are two main ways to try to remove the overhead of references to ZSTs: make them ZSTs themselves (as proposed here), or try to eliminate them through optimization.
Making them ZSTs
The former option is a breaking change to the language. I agree that it could probably be accomplished in a linking-compatible way by using something like a pair of V1ZstRef<()> and V2ZstRef<()> types. I imagine both would be usable from code in any version, with the first being equivalent to the original &(), and the latter to the new zero-sized &().
The next question is, is it worth it? Even with a mechanism for making breaking changes to the language, the desire is still to keep them small and rare. We would also be committing to keeping both types of references in the compiler for the foreseeable future. Therefore, I would want to see concrete benefits demonstrated before going down that road, such a real work application where it saves a significant amount of memory or code size. I do agree that it seems reasonable to assume that using ZST references for FFI would become deprecated once we have a better alternative.
When I first came to Rust, I actually expected ZST references to also be ZSTs, and was surprised when they weren't. My preference would still be for them to be, I'm just not sure it's worth the breaking change. Aside from backward compatibility, I would like to understand better what generic patterns would be complicated, given that containers et al already have to special case ZSTs in most cases. Are there examples of code that currently works with ZSTs without special casing, but would have to deal with them specially after this change? Is there any code that would silently break?
Eliminating ZST references as an optimization
This can be done either conservatively and aggressively.
Conservatively
This would work by eliminating ZST references when the compiler can prove the address isn't observed, such as when a function never converts the reference to a raw pointer. This could be accomplished through metadata flags, and, like impl Trait, would mean that some changes to a function would require all users of it to also get recompiled. The easiest target for this optimization would be eliminating bare reference, such as &self, but with extended analysis, it would be possible to eliminate them from crate-private structs as well.
I imagine this approach would be able to avoid passing/storing ZST references here and there, but it wouldn't be reliable, and a change to a leaf function could force a ZST reference to be stored through most of the call graph.
Aggressively
I see this approach as kind of a hybrid. ZST references would take up no space in a lot more cases, but code could still treat ZST references as pointer-sized in generic code. To make this work, the language would specify that for any reference: &ZST, reference as *const ZST as usize == std::mem::align_of<ZST>. That is to say, all instances of a given ZST are specified to reside at the lowest non-zero address consistent with its alignment. The language would further specify that attempting to create/modify a ZST reference to point at a different location would be undefined behavior. Importantly, this undefined behavior can easily be tested for by a sanitizer, which is desired for any UB in Rust.
This would allow the compiler to always eliminate passing and returning a bare &ZST, and would also enable compiler to avoid storing them in repr(rust) structs. Structs would then just take up the space necessary for there other members. The exception (to avoid unexpected ZSTs in generic code), is that structs containing nothing except ZST references and ZSTs would act just like bare &ZSTs: they would act pointer sized, but the compiler could eliminate passing them or storing them.
This approach obviously requires that using &ZSTs in FFI and other usages of ZSTs and opaque types to be deprecated and eventually removed in favor of #1861. I think this is desirable anyway, because using ZSTs as opaque types have a number of other disadvantages (which, indeed, served as the motivation for that RFC). This approach also wouldn't eliminate space usage in all places that making &ZST truly zero-sized would. E.g., unless optimized to take advantage of the new rules, Vec<&ZST> would still store a pointer-sized value for each reference, even though they're guaranteed to be the same.
Finally, this could break some non-FFI code. The most obvious example I can think of is something like using https://github.com/Diggsey/rust-field-offset with a zero-sized field. In debug mode, calculating the offset would underflow and panic. In release mode, applying the offset to a given struct would result in a pointer to a random location. Now, dereferencing a random point to a ZST is unlikely to actually cause any trouble, since there will never be an actual read and write to that location. Further the address would effectively get normalized back to the proper one when apply returned, since the compiler would have optimized out actually returning anything.

Thanks all for the discussion, and @EpicatSupercell for the RFC! I'm going to close as per discussion and FCP, but there are still alternative avenues to explore here!

E.g., unless optimized to take advantage of the new rules, Vec<&ZST> would still store a pointer-sized value for each reference

Can someone explain why this is? What is preventing &ZST from being considered a ZST itself in this context?

@kevincox &T has been “non-null *const T with a lifetime” forever and some programs rely on it carrying a memory address.
For example they might use ZST’s to represent opaque types that are only manipulated through pointers or references (say, C++ objects whose memory layout might change across platforms). Using references over pointers is useful to get lifetime tracking. Then when it’s time to do something with that reference, it is cast back to a pointer and passed to some FFI function and needs to have preserved its address.

@SimonSapin That sounds like the general reason this RFC was denied, but I don't see how it translates to the Vec case with the "proposed" changes in that comment. That "proposal" would set reference as *const ZST as usize == std::mem::align_of<ZST> which would remove the ability of storing data in the reference.

It is indeed possible to do zero-sized references without breaking existing code:
struct S<'a> {
    #[allow_zero_sized]
    pub e: &'a Empty,
}

Then S should be zero-sized.
Please implement this feature.


added port detection and automatic slot number

This PR detects automatically all serial ports, and uses the port when one is detected. It also sets the slot depending on the filename, it it contains "slot1" or "slot3".

Confirmed on my Mac
mcumgr-client 0.0.2, Copyright © 2023 Vouch.io LLC

19:18:26 [INFO] One bootloader device found, setting device to: /dev/cu.usbmodem14301
19:18:26 [INFO] upload file: ext-flash.bin
19:18:26 [INFO] flashing to slot 3
19:18:26 [INFO] 22003712 bytes to transfer
⠖ [00:01:00] [====>                                    ] 2.44 MiB/20.98 MiB (2m)


Websocket Route Not Working With Nested Router

First Check

[X] I added a very descriptive title to this issue.
[X] I used the GitHub search to find a similar issue and didn't find it.
[X] I searched the FastAPI documentation, with the integrated search.
[X] I already searched in Google "How to X in FastAPI" and didn't find any information.
[X] I already read and followed all the tutorial in the docs and didn't find an answer.
[X] I already checked if it is not related to FastAPI but to Pydantic.
[X] I already checked if it is not related to FastAPI but to Swagger UI.
[X] I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

[X] I commit to help with one of those options 👆

Example Code
from fastapi import APIRouter, FastAPI
from fastapi import WebSocket

router = APIRouter(prefix="/foo")
nested_router = APIRouter()
router.include_router(nested_router)
app = FastAPI()

# WORKS

# python -m websockets ws://localhost:8000/test-ws
@app.websocket("/test-ws")
async def test_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_text("Hello World!")
    await ws.close()

# WORKS

# python -m websockets ws://localhost:8000/foo/test-ws
@router.websocket("/test-ws")
async def foo_test_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_text("Hello World!")
    await ws.close()

# FAILS - 403 FORBIDDEN

# python -m websockets ws://localhost:8000/foo/bar/test-ws
@nested_router.websocket("/bar/test-ws")
async def bar_test_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_text("Hello World!")
    await ws.close()

app.include_router(router)

Description
When upgrading from FastaAPI 0.72.0 to 0.78.0, noticed that a websocket path I had defined on a router included by another router was no longer available (server returns 403, trace logs indicate normal closure, think this is the normal behaviour when a websocket tries to upgrade a non-existent route).
Looks like #2640 fixed the case for a websocket defined on a router, but seems like the nested router makes this appear again.
Operating System
macOS
Operating System Details

FastAPI Version
0.78.8
Python Version
3.10.1
Additional Context
It's kinda weird that it did work before, since #98 would indicate that it's been a long standing problem. 🤷

Alright so I pulled down the code and it seems like I can fix it with ordering the path definitions and the include_router. If I restructure the code like this:
from fastapi import APIRouter, FastAPI
from fastapi import WebSocket

nested_router = APIRouter()

# NOW WORKS
# python -m websockets ws://localhost:8000/foo/bar/test-ws
@nested_router.websocket("/bar/test-ws")
async def bar_test_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_text("Hello World!")
    await ws.close()

router = APIRouter(prefix="/foo")

# WORKS
# python -m websockets ws://localhost:8000/foo/test-ws
@router.websocket("/test-ws")
async def foo_test_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_text("Hello World!")
    await ws.close()

router.include_router(nested_router)
app = FastAPI()

# WORKS
# python -m websockets ws://localhost:8000/test-ws
@app.websocket("/test-ws")
async def test_ws(ws: WebSocket):
    await ws.accept()
    await ws.send_text("Hello World!")
    await ws.close()

app.include_router(router)

I can then hit the  nested router:
cbrodt@cbrodt-safely-you[fastapi]$  python -m websockets ws://localhost:8000/foo/bar/test-ws
Connected to ws://localhost:8000/foo/bar/test-ws.
< Hello World!
Connection closed: 1000 (OK).

So it seems like when calling include_router, it will miss any path operations not yet defined. Not sure on the right approach for a fix, but in the meantime maybe add a warning to the docs?

Hello, I recently tried how to initiate a request to websocket in the sub-application, but found that the websocket parameter cannot be received in the sub-route. How to solve it?


Elixir 1.3.x

Hi,
I am interested in using your lib for authorization, but I am getting a warning that says: "the dependency :policy_wonk requires Elixir "~> 1.4" but you are running on v1.3.4". Is it necessary to have Elixir 1.4.x? If no, can you lower the elixir requirement in your mix.exs file?
Thanks,
Vlado

I don't remember why it requires 1.4. I'll take a look soonish.
The new version, which targets phoenix 1.3 umbrella apps, will definitely need Elixir 1.4...


update LOGOS submodule

Pull Request Description
What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)
see #1114
What are the significant changes in functionality due to this change request?
remove the constraint on Pyomo version, now LOGOS works for both Pyomo 5.7.x and 6.x.x

For Change Control Board: Change Request Review
The following review must be completed by an authorized member of the Change Control Board.

[ ] 1. Review all computer code.
[ ] 2. If any changes occur to the input syntax, there must be an accompanying change to the user manual and xsd schema. If the input syntax change deprecates existing input files, a conversion script needs to be added (see Conversion Scripts).
[ ] 3. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
[ ] 4. Automated Tests should pass, including run_tests, pylint, manual building and xsd tests. If there are changes to Simulation.py or JobHandler.py the qsub tests must pass.
[ ] 5. If significant functionality is added, there must  be tests added to check this. Tests should cover all possible options.  Multiple short tests are preferred over one large test. If new development on the internal JobHandler parallel system is performed, a cluster test must be added setting, in  XML block, the node <internalParallel> to True.
[ ] 6. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change.  The requirements and the requirements test shall be in sync.
[ ] 7. The merge request must reference an issue.  If the issue is closed, the issue close checklist shall be done.
[ ] 8. If an analytic test is changed/added is the the analytic documentation updated/added?
[ ] 9. If any test used as a basis for documentation examples (currently found in raven/tests/framework/user_guide and raven/docs/workshop) have been changed, the associated documentation must be reviewed and assured the text matches the example.

@PaulTalbot-INL @yoshiurr-INL This is the PR to remove the constraint on Pyomo Version.

Job Test CentOS 7 on 85bc361 : invalidated by @wangcj05
retesting:

All jobs on 85bc361 : invalidated by @wangcj05


Update README phone images

Replace outdated phone images in the README with the currently offline app experience.

@clivewong @dbreese when previewing this branch in Git, the image layout on the README file seems a little off. They look stacked, like in the images below. Can we add line breaks between the bullet points and latest images?

Looks good! Let's ship it!

@dbreese @khawkins can we merge this PR to main?


Plugins and extensions

The composeable nature of cmd allows plugins and useful extensions to easily be created.
Something like a auto generated usage screen for a cli could look something like:
var oneCommand = command(
  alias('me'),
  description('This is the "me" command and it does this and that'),
  example('command me <options>'),
  handler(function () {

    console.log('me command')
  }),
  handler(function () {

    console.log('another me command function')
  }),
  description('This is one command')
)

var flags = cli(f())

var program = cli(
  usage(
    description('cmd <command> <options>'),
    alias('--usage'),
    alias('-h', '--help')
  ),
  oneCommand({option: 'one'}),
  flags()
)

run(
    process.argv.slice(2),
    program()
)

Usage would basically export a program which is composable into other programs or runnable with the run function. It would looks something like:
module.exports = function usage () {
  var options = asArray(arguments)

  return cli(
    flag(
	alias.apply(null, parseAliasesFromArgs(options)),
	handler(function (value, context) {

	  // print out usage screen here
	})
  )
}

Underneath is an AST(ish) type tree, but there's really no need to know about it as evrything is just a command, flag, or cli (ultimately). The basic functions alias, handler, command, flag, cli, and run should be enough to make any plugin.

@scottcorgan is this code currently executable? I think I may be able to answer some of my own questions by trying to fiddle with it.

It is on my local machine, but I haven't pushed up the code yet. I should be able to get it up in the next few days so it is executable. It will be a collection of the following modules to make it all compose:

cmd
cmd-alias
cmd-handler
cmd-command
cmd-flag
cmd-usage
cmd-run

I'll be able to explain more on why there are so many as things start to come together. I'm hoping to get the code to a place that starts to let contributors in.


[sqlitecpp] do not use stack protection

change configuration to turn stack protection off
Fixes #25760

I took your suggestions as the cmakelists.txt of sqlitecpp mentions that stack protection does not work on (only) mingw64.

please run following commands when you git commit a new change:
.\vcpkg x-add-version sqlitecpp --overwrite-version
git add .
git commit --amend --no-edit
git push


Article Details

Hello, I am a graduate student in China and have the privilege of reading your BBDM paper published in CVPR2023 at arXiv. The derivation of some formulas in the paper is not very clear. Would it be convenient for you to provide a contact email for your consultation? thank you.

Thank you for your attention. Some of the deduction details can be found in the appendix. https://arxiv.org/abs/2205.07680
If you have any other questions, you can specify the parts to me.

Hi @zhangXJ147 and @xuekt98 ,
I have a question (#29) regarding the reverse process as for my understanding of this equation in line 198 in the code it should be equivalent to Eq 12 in the paper, right?
However, when I implemented Eq 12 directly and compared both of them they didn't give the same result which means your implementation (line 198) is different from the Eq 12 in the paper.
More specifically, the difference is only in the X0 coefficient.
Thanks in advance!


Laravel 9 error on webserver

I have Laravel 9 and when I installed the package locally and then moved all files to my web server and created the Controller. When I gave use of GoogleTransleate; I have such an error Class "GoogleTranslate" not found. And I don't know what to do but I need it to run on my webserver. It is true that I reworked the function a bit because it is more convenient for me to use it and I did not want to play with overwriting the class function

I tried the package in a fresh laravel v9 install and it works as expected. You might not have installed the package properly. Please refer to the package readme and follow all the steps.

I tried the package in a fresh laravel v9 install and it works as expected. You might not have installed the package properly. Please refer to the package readme and follow all the steps.

I did everything step by step as in the instructions and then chewed all the files on my webserver which I have on the hosting.

I did everything step by step as in the instructions and then chewed all the files on my webserver which I have on the hosting.

I did everything step by step as in the instructions and then chewed all the files on my webserver which I have on the hosting.

I have heard from a few people that Laravel has such problems that packages do not always work as the developers would like them to and you have to register them manually. I also saw that not only I have such a problem because one person already had problems with hosting Laravel. I am able to provide access to my web server if necessary

@introwit

@introwit Okay, I solved the problem. I recommend you to change the GoogleTranslateServiceProvider file because it causes a problem and makes it not working on web hosting because when you manually register an alias and provider in the config / app.php file and change 2 lines in the GoogleTranslateServiceProvider file, it works normally.
From __DIR__ . '/../config/googletranslate.php' => config_path('googletranslate.php'),
To config_path('googletranslate.php') => config_path('googletranslate.php'),
From $this->mergeConfigFrom(__DIR__ . '/../config/googletranslate.php', 'googletranslate');
To $this->mergeConfigFrom(config_path('googletranslate.php'), 'googletranslate');


Add the postinstall trackEvent back in

Description
Adds the postinstall step back in that was revered in #441
Steps to Test
Test packaged install:

Run npm pack
Run npm install -g automattic-vip-1.6.2.tgz and confirm there are no install errors
Might be a good idea to confirm that the track event was sent

Test cloned install: (this currently does not work)

git clone in a new dir and switch to this branch
npm i should run without errors

As noted on Slack, what are we trying to achieve with tracking when a new version is installed?

I think the idea was that we could see how many people were using each version. Probably to see uptake and to also know the scope of users affected if we have to break compatibility down the road for (much) older versions?

Noting that removing the npm build from the postinstall step has broken the cloned version install.  Thinking about this a bit more, maybe we don't really care about tracking when it's installed via git clone vs npm i -g? We probably don't to track these types of "installs", since things like the CI services clone it then run npm i

I think we can use other events such as https://github.com/Automattic/vip/blob/master/src/lib/cli/command.js#L407 to detect what versions are used by clients. If we add a tracking event to install, and use it as a way of detecting version usage, we may end up with outdated info as this event will only fire once (when installing). In all other events, we do track which version is used, so I think any event can be used to have an idea about version usage, and those will be newer than an install event in my opinion.

cc @simonwheatley for input on whether we need to track the install event.

I’m happy that we can use the version property on all events to track this. Assuming that this PR affects only the Tracks event post-install it can be closed unmerged @dchymko

Thank you for confirming Simon. Closing this!


Set the User-Agent header

We should set the User-Agent header to a unique string that identifies this project so that we can more easily filter smoke tests in our request logs. This can be very useful when debugging problems.
We should set the User-Agent once globally and not in every test individually. This will require us to refactor how we currently initialize the HTTP clients. I suggest that we create our own ClientBuilder that wraps reqwest::Client::builder() and sets the User-Agent.
Depending on reqwest's API, it might be necessary for our own builder to accept and pass additional headers to the default_headers.
We can then refactor all usage of reqwest::Client to go through our own HTTP client.

I would like to give this issue a try. I got here from the Impl Room issues for EuroRust.


configuring issue

Hi Carlos,
I m facing while configure the API,
It gives me "NetworkError: 410 Gone - http://gdata.youtube.com/feeds/api/playlists/PL2591DC20C4BB4D78?v=2&alt=json&callback=jQuery111300009907489479589193_1440425100797&_=1440425100798"
Thanks
Prateek

Hi. The RSS Feed used to get the playlist contens was deprecated in the past weeks by YouTube. I'm upgrading the library to use YT API V3.0 (using an API KEY) Hope will beready to test in 2 or 3 days.

I've just uploaded the new version updated to the V3 of Youtube API. Some testing it's in progress but seems that work fine with modern browsers.


React  basic useState examples not found

Hello I Will Try To Help You
In Const [user,setUser] = usestate();
add {} in ()
Hope This Will Help You

https://react.dev/reference/react/useState#usage


Where are the LSTM and GAN benchmarks?

Thanks for participating in the TVM community! We use https://discuss.tvm.ai for any general usage questions and discussions. The issue tracker is used for actionable items such as feature proposals discussion, roadmaps, and bug tracking.  You are always welcomed to post on the forum first :)
Issues that are inactive for a period of time may get closed. We adopt this policy so that we won't lose track of actionable issues that may fall at the bottom of the pile. Feel free to reopen a new one if you feel there is an additional problem that needs attention when an old one gets closed.
For bug reports, to help the developer act on the issues, please include a description of your environment, preferably a minimum script to reproduce the problem.
For feature proposals, list clear, small actionable items so we can track the progress of the change.

Please open a thread at  https://discuss.tvm.ai , thanks


Adding ability to install requirements from frontmatter through the /pipelines/add API

Solves the issue #188
Issue: The frontmatter "requirements" field is not respected when pipeline is added through the /pipelines/add API, which is what OpenWebUI uses.
Solution: As part of loading the module, extract frontmatter, run pip to install the requirements before loading the module.
This should match the behavior similar to what start.sh doesn.

@tjbck any thoughts on the changes? Would love to have this in to make the pipeline installation convenient.

LGTM, Thanks!


GRASSHOPPER

why u silent about grasshopper?

Can you watch this video: https://www.youtube.com/watch?v=VoymcDni9eM (Minute: 31:00), please. 🙂
Then you can see that I started Grasshopper but there are still problems in some places! 📝


(node:17285) DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.

Deprecated notice on Node 7.1

same here... cannot fix it...
os = require('os');
os.tmpDir = os.tmpdir;

formidable/lib/incoming_form.js
change os.tmpDir(); to os.tmpdir();
change at repository would be great.

This repository still active? I use this package on my framework, but I will need to create my own package (maybe a fork) to apply critical changes like this one.
I don't want see deprecation warnings! 😞

+1

Done 9KCZ5A2GrylAXM1E

still warning

+1

i have updated everything, made the changes everywhere but still getting the same error

(node:12964) [DEP0022] DeprecationWarning: os.tmpDir() is deprecated. Use os.tmpdir() instead.
any help

fixed in https://github.com/node-formidable/node-formidable/pull/516