Webview crashed

I meet a problem where change webview very quickly ,the webview will crash and display none until restart app.
the same code
this.state.buttonIndex = 1
render() {
    let content = this.state.buttonIndex ==1 ? <WebView> : <ListView>
   <View>
      <Button   onPress = {this.changeState}/>
      {content}
   <View>
}

This will happend when I press button quickly .
Just as I test, It only occur on android
Some logs may be helpful:
09-09 15:05:53.688: E/DataReductionProxySettingListener(25014): No DRP key due to exception:java.lang.ClassNotFoundException: com.android.webview.chromium.Drp
09-09 15:05:53.753: E/SELinux(338): avc:  denied  { find } for service=batteryproperties scontext=u:r:untrusted_app:s0:c512,c768

Additional Information

React Native version: [0.31]
Platform(s) (iOS, Android, or both?): [Android]
Operating System (macOS, Linux, or Windows?): [Mac]

Hi there! This issue is being closed because it has been inactive for a while.
But don't worry, it will live on with ProductPains! Check out its new home: https://productpains.com/post/react-native/webview-crashed-
ProductPains helps the community prioritize the most important issues thanks to its voting feature.
It is easy to use - just login with GitHub.
Also, if this issue is a bug, please consider sending a PR with a fix.
We're a small team and rely on the community for bug fixes of issues that don't affect fb apps.

@facebook-github-bot label Icebox

@facebook-github-bot close


KubeCon NA 2023 Blog Post

TODO:

Review list of talks
Add location of project pavilion

@mtwo @austinlparker please take a look, anything we can add around the loung / extra space for otel, cc @jpkrohling

I would like to get @mtwo's approval before mentioning the lounge.

+1 to Austin's comment, we should add a section about the OpenTelemetry Observatory area on the show floor, and we should direct community members to host sessions there

@svrnm I sent you a blurb on slack for the lounge, can you add it?

done, see https://github.com/open-telemetry/opentelemetry.io/pull/3251/commits/b06bb0e22926d6b926358312be5d54c8793de8d5
please take a look again if this fits


Update chain.json bitsong by 🔥STAVR🔥

@obajay I've accepted a few of these already but just realized you're adding yourself in the middle of each set. If it's a new addition, it needs to be added to the bottom of the list. Can you please fix this and the remaining ones and then we'll accept?

@obajay I've accepted a few of these already but just realized you're adding yourself in the middle of each set. If it's a new addition, it needs to be added to the bottom of the list. Can you please fix this and the remaining ones and then we'll accept?

yes, no problem, I'll do it.
It was just more convenient for me to add in the middle so as not to make a mistake with punctuation


htlcswitch: reduce db contention when removing forwarding packages

This PR alters the way we remove forwarding packages in the link.
ee55bd68c6a8948bebc59b2b18781802eb6a3e47 reduces memory, time in the link by using a single transaction to remove a group of forwarding packages. Previously this was done in a loop with a database transaction created every single time.
5f0f19e5c5f77af0aa83ac37ca6d0b506c0d3fa2 removes the forwarding packages initially when fwdPkgGarbager is first started in a goroutine. This lets us bump the FwdPkgGCTicker interval to 1 hour. They do not need to be removed every minute. The forwarding packages must be initially removed so that flappy nodes actually get their forwarding packages removed.

Travis build fails are flakes.

We could also make it so that resolveFwdPkgs doesn't use as many db txn's as well

Travis build is a flake, please re-review !


Update override-default-open-behavior-grids.md

Add a new updated approach to modify the default open behavior with the new Power Apps Grid Control

@ericregnier
Thanks for your contribution.
This change is to modify this article: Override the default open behavior of data rows in an entity-bound grid
I reviewed this but didn't test it end-to-end. How would you characterize the difference between this new approach from the existing one?
As far as I can see, the new approach leverages the fact that the Power Apps Editable grid control exposes the OnRecordSelect event.
If I understand the instructions, the new approach would immediately open the new URL when the record is selected. Whereas if I understand the existing approach, the change enables a new custom button that can be used to open a new window when the record is selected.
Does this match your understanding?
Here is a problem I see:
This article: Override the default open behavior of data rows in an entity-bound grid is about customizing the command bar using "classic commands".
But your approach doesn't use the command bar or any command.. so while it achieves the same or similar outcome, I think it needs to be in a different location within the docs.
It seems to have more in common with this article Navigating to a custom page using client API.
If I'm not mistaken, it is similar to the existing example: Open from a selected record in editable grid as a centered dialog with record ID except it uses Xrm.Navigation.openUrl rather than Xrm.Navigation.navigateto.
Does this seem accurate to you?

Thanks for your prompt comments @JimDaly!
If I understood your question correctly, it's a different approach because it's a different way of modifying the default behavior open record on model-driven app grids - with the client-side event instead of a custom ribbon command. In my opinion, the new approach is way simpler for the customizers.
From the user/developer/customizer perspective, I suggest keeping it here because it's easier to find and compare the desired approach. I see the article Override the default open behavior of data rows in an entity-bound grid about customizing the default behavior whether it's with the ribbon or not... And most likely the users will search how to modify the record select/open behavior and can see all the options in one place. Perhaps in the future there will be other ways (hopefully without even requiring code) and can be updated here.
Hope this makes sense?

bout customizing the default behavior whether it's with the ribbon or not... And most likely the users will search how to modify the record select/open behavior and can see all the options in one place. Perhaps in the future there will be other ways (hopefully without even requiring code) and can be updated here.

@ericregnier
I hear what you are saying. There can be different ways to do the same thing. That makes things challenging because our content is organized by feature and this article (and all the ones it is grouped with) is about customizing ribbon commands.

Each article in this section calls out that:

This topic is about classic commands.
There is a new way to define commands. See Modern commanding overview (preview).

At some point in the future when modern commanding replaces ribbon, all this content will be removed. No one will look into this article to extract the separate approach that doesn't use ribbons to achieve the same result. It would get lost.
I would prefer to have a separate page that highlights scenarios around using Xrm.Navigation.openUrl, where this particular scenario could be used. And then we could have links between these two articles to highlight that they achieve the same result.
What do you think?

Or we could put this as an example for the Grid OnRecordSelect event  page.
Lots of room on that page...

@JimDaly yup that makes sense based on how the info is structured now. I will move it to https://learn.microsoft.com/en-us/power-apps/developer/model-driven-apps/clientapi/reference/events/grid-onrecordselect as suggested and create a new PR

https://github.com/MicrosoftDocs/powerapps-docs/pull/4492


Restrict the use of crd generate structs to the cluster marshaller

This fixes a runtime panic during upgrade due to an invalid casting in cluster manager
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: g-gaston
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [g-gaston]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@g-gaston: The following tests failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

eks-anywhere-mocks-presubmits
fb7b5216465d073a69d7ea73e838e45e48586ea9
link
/test eks-anywhere-mocks-presubmits

eks-anywhere-attribution-files-presubmit
fb7b5216465d073a69d7ea73e838e45e48586ea9
link
/test eks-anywhere-attribution-files-presubmit

eks-anywhere-e2e-presubmit
fb7b5216465d073a69d7ea73e838e45e48586ea9
link
/test eks-anywhere-e2e-presubmit

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Implement messages and postbacks

TODO:

[ ] Add tests for the controller

I've heard of this technique called “tests first”. Believe @fespinoza has some input. :trollface:

HEHE FUNNY

Actually that is pretty funny.

A better approach than to bundle all sorts of integrations with this gem would be to make a gem for each framework (e.g. facebook-messenger-rails), so I'm closing this.


Fix insufficient contrast on borders

Description
Use $gray-600 for border color in light mode.
This has a contrast of 4.69 to white, which should be good
Motivation & Context
This solves the insufficient contrast on borders when on light mode. Issue opened here: #38480
Type of changes

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Refactoring (non-breaking change)
[ ] Breaking change (fix or feature that would change existing functionality)

Checklist

[x] I have read the contributing guidelines
[x] My code follows the code style of the project (using npm run lint)
[ ] My change introduces changes to the documentation
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[x] All new and existing tests passed

Live previews

https://deploy-preview-40949--twbs-bootstrap.netlify.app/

Related issues
No related issues.

Thanks for your PR @GhassenRjab, but the suggested value is too dark. A lighter one was already refused in https://github.com/twbs/bootstrap/pull/38489.
As said here https://github.com/twbs/bootstrap/pull/38489#issuecomment-1518506999:

Let's keep the PRs at bay for now and discuss any potential changes in the issue. I could see us darkening things a little, but this is too much.


Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.4%) to 96.194%

Totals

Change from base Build<PHONE_NUMBER>:
0.4%

Covered Lines:
2556

Relevant Lines:
2656

💛  - Coveralls


find_validators fails when called second time on same dataclass

Initial Checks

[X] I have searched GitHub for a duplicate issue and I'm sure this is something new
[X] I have searched Google & StackOverflow for a solution and couldn't find anything
[X] I have read and followed the docs and still think this is a bug
[X] I am confident that the issue is with pydantic (not my code, or another library in the ecosystem like FastAPI or mypy)

Description
Context: Our library uses Pydantic to generate Json Schema from the signature of a user-provided Python function (we use create_model). We were investigating reports of empty schemas when function uses dataclasses.
As I was investigating the issue, the debugging experience was very weird - same code executed behaved differently when executed  by library vs. when executed by us.
Chasing the root cause and doing sanity checks, I've found a very unexpected behavior in Pydantic: It looks like when find_validators function is called on a user's dataclass, it modifies the class in a way such that the next invocations of find_validators crash. This is very unexpected behavior.
Check the following simple code.
import dataclasses
import pydantic.v1.dataclasses
import pydantic.v1.validators

@dataclasses.dataclass
class LocationX:
    city: str
    state: str

print(f"{pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=}")
print(list(pydantic.v1.validators.find_validators(LocationX, config=pydantic.v1.BaseConfig())))
print(f"{pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=}")
print(list(pydantic.v1.validators.find_validators(LocationX, config=pydantic.v1.BaseConfig())))

Output:
pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=True
[<bound method _validate_dataclass of <class '__main__.LocationX'>>]
pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=False
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
[<ipython-input-43-ca4a49586824>](https://localhost:8080/#) in <cell line: 9>()
      7 print(list(pydantic.v1.validators.find_validators(LocationX, config=pydantic.v1.BaseConfig())))
      8 print(f"{pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=}")
----> 9 print(list(pydantic.v1.validators.find_validators(LocationX, config=pydantic.v1.BaseConfig())))

[/usr/local/lib/python3.10/dist-packages/pydantic/v1/validators.py](https://localhost:8080/#) in find_validators(type_, config)
    763         yield make_arbitrary_type_validator(type_)
    764     else:
--> 765         raise RuntimeError(f'no validator found for {type_}, see `arbitrary_types_allowed` in Config')

RuntimeError: no validator found for <class '__main__.LocationX'>, see `arbitrary_types_allowed` in Config

Initially, is_builtin_dataclass(LocationX) == True. But after calling find_validators once, is_builtin_dataclass(LocationX) == False which causes find_validators to always fail in subsequent calls. (The reason is_builtin_dataclass is now returning False is because LocationX now has __pydantic_model__ attribute.)
Such intrusive modification of user-provided classes is completely unexpected and disruptive.
Please fix this issue and restore our collective sanity.
Example Code
import pydantic

@dataclasses.dataclass
class LocationX:
    city: str
    state: str

print(f"{pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=}")
print(list(pydantic.v1.validators.find_validators(LocationX, config=pydantic.v1.BaseConfig())))
print(f"{pydantic.v1.dataclasses.is_builtin_dataclass(LocationX)=}")
print(list(pydantic.v1.validators.find_validators(LocationX, config=pydantic.v1.BaseConfig())))

Python, Pydantic & OS Version
pydantic.__version__ == "2.9.2"

             pydantic version: 1.10.18
            pydantic compiled: False
                 install path: /usr/local/lib/python3.10/dist-packages/pydantic/v1
               python version: 3.10.12 (main, Nov  6 2024, 20:22:13) [GCC 11.4.0]
                     platform: Linux-6.1.85+-x86_64-with-glibc2.35
     optional deps. installed: ['typing-extensions']

Affected Components

[ ] Compatibility between releases
[X] Data validation/parsing
[ ] Data serialization - .model_dump() and .model_dump_json()
[X] JSON Schema
[X] Dataclasses
[ ] Model Config
[ ] Field Types - adding or changing a particular data type
[ ] Function validation decorator
[ ] Generic Models
[X] Other Model behaviour - model_construct(), pickling, private attributes, ORM mode
[ ] Plugins and integration with other tools - mypy, FastAPI, python-devtools, Hypothesis, VS Code, PyCharm, etc.

Had a quick look at the implementation, I don't see how this can easily be fixed. I don't know if you are making use of find_validators directly, but this function wasn't publicly documented and we don't provide (non critical) fixes to V1 anymore. You can open a new issue if you feel like it, providing the bigger picture of your issue.

@Viicos Thank you for your patience. I think I did a pretty thorough job digging down to the root of the issue, filed a pretty long and clearly described issue, provided context, included description and repro cases. I hope this will help the team look at the issue seriously.

I don't know if you are making use of find_validators directly
providing the bigger picture of your issue.
As I mentioned in the issue description, I'm using Pydantic to create models and schemas. I use the public create_model method. And that method calls the public find_validators function.

So the consequence is that if you use a type in two models, then everything fails. This looks like a pretty critical error.

I don't see how this can easily be fixed.

If the intrusive behavior of find_validators modifying the user classes cannot be fixed, then you should fix the find_validators being incompatible with itself. Why must it start failing after putting some marks on the class? This looks like an unintended bug.


Remove llnl_scripts/batch_scripts directory?

We have scripts in <axom>/llnl_scripts/batch_scripts to build and test axom and its TPLs using several configurations on several platforms. The makefile to run them does not appear to work and it is not clear if anyone is using these scripts.

Is anyone using these scripts?
Does anyone object to removing them?

I don't see why we should keep them if they don't work. If someone is using them, it's not clear what they are doing?

That's my take as well.  Just wanted to make sure I wasn't missing something.

I updated these scripts and removed the broken Makefile in #502.
I decided the batch scripts had utility since they captured info like banks and partitions and can be submitted without keeping a terminal open.


refactored code to fix eslint errors

correctly updated local repo to upstream project.
Refactored code to fix eslint errors.

@kevinansfield

I'll work on this next.

@dhuang612 please make sure to rebase it over latest master first ;) as this branch seems quite outdatad


Remove unused code & reorg so active code is no longer 'experimental'. Fixes #174.

I think this accomplishes what we've discussed, and I don't see any missing-dependencies errors. I've checked to make sure that the word 'experimental' does not appear in the repo anywhere.
The 'experimental' directory's contents have been moved up one level to a top-level spikesortingview directory, with the exception of two files that I've marked DEPRECATED and which don't seem to be referenced by anything in the repository. (Not sure if this functionality is needed outside the repo--it doesn't appear in the scripts that Kyu linked the other day (see issue #174) but that doesn't preclude it being used elsewhere).
No changes made to the workspace class or methods, except to update references to content that used to be in experimental or had experimental in the name (experimental_spikesortingview -> spikesortingview).
Please let me know if there's anything else we should remove, and what we should do in regards to testing.

Fixed ._spikesortingview(...) => .spikesortingview() in a couple places.
Raise a helpful exception if try to import from sortingview.experimental

Looks good... merging


Improve how to test instructions

Added additional info to run in OSx platform and to run individual test cases

hello, @membphis how can I fix this mac os issue? or does this fail by default

it is unstable, we can re-run it

@sshniro We should do the development in our own repository, avoid to create branch at APISIX repository.

@sshniro We should do the development in our own repository, avoid to create branch at APISIX repository.

Aw! Now only noticed, the edit button in Github creates the branch in the main repo itself, I will close this PR and create a new one.

@membphis there is also another branch with my name in the APISIX repo, shall I also delete it?

yes, we need to remove this branch. it is useless for other people.


Add information that an external library is required to use Pillow

I fixed README.md in example.


Seems like synth is not seeing a package that it built, and therefore deletes packages that need it due to "failed dependency check"

Everything is building OK for me, but when I do a synth rebuild-repository, synth says that four items (which are all among those it just built) "failed dependency check" and deletes them from /var/synth/live_packages/All. Three of them are failing the check simply because they depend upon the first. But for the first (subversion), this is what 06_obsolete_packages.log says:
devel/subversion package has less dependencies than the port requires (8)
Query: devel/apr1:apr-<IP_ADDRESS>.6.1_2
textproc/expat2:expat-2.5.0
security/gnupg:gnupg-2.3.8
archivers/liblz4:liblz4-1.9.4,1
www/serf:serf-1.3.9_6
databases/sqlite3:sqlite3-3.40.1,1
textproc/utf8proc:utf8proc-2.8.0

subversion-1.14.2_2.pkg failed dependency check.

At first, I thought synth was saying I was missing one of those, but I do have all of those packages, with those same versions (both installed on my machine and also within /var/synth/live_packages/All). Then I noticed there are only seven listed, rather than the eight that the log message says. So, I went to the FreshPorts page for Subversion, which seems to show that the missing dependency is devel/gettext-runtime (for libintl.so). But again, I have the latest version of that (again,  both installed on my machine and in /var/synth/live_packages/All):
# pkg version -v | grep gettext
gettext-runtime-0.21.1             =   up-to-date with index
# find . | grep gettext
./gettext-runtime-0.21.1.pkg
./gettext-tools-0.21.1.pkg

And I don't think this matters with respect to the problem I'm facing, but I also have the actual required library package on my machine, and it was installed by the appropriate port:
# locate libintl.so
/usr/local/lib/libintl.so
/usr/local/lib/libintl.so.8
/usr/local/lib/libintl.so.8.3.0
# pkg which /usr/local/lib/libintl.so
/usr/local/lib/libintl.so was installed by package gettext-runtime-0.21.1

So it seems like maybe synth can't see (or for some reason is ignoring) the gettext-runtime-0.21.1.pkg that it just built?

it's a bug in the port. the port author has to fix it.
I don't know what specifically the problem is and it's not something poudriere can detect.  But I've seen dozens of these and they are always mistakes in the port makefile.

the problem is subversion port lists 8 dependencies but for some reason only 7 of those are registered in the package.  So subversion will fail the dep check every single time.

often what happens is the makefile lists a file that's actually present on the system so it doesn't get built.

here's the probably bug, gettext like you mention:
NLS_CONFIGURE_OFF=		--disable-nls
NLS_USES=			gettext

so gettext is only used for NLS
but NLS must be configured off in your case.
So gettext is not used.
therefore it's not linked in.
So the makefile has 8 dependencies but only creates package with 7.
The author needs to set "NLS_USES_ON=gettext" or whatever the syntax is for adding gettext ONLY IF NLS option is set on.  That's the bug.

OK, great, thanks - I'll try to get in touch with the port author to let them know.

let me look a few minutes more to be sure.

OK, will do. Thanks again.

can you show me the options set for the subversion package you built?
There's some kind of "pkg info" command that can show it

and do you have NLS turned off globally somehow that you know of?

I'm not so sure it's gettext anymore because I think NLS_USES only adds gettext if NLS option is set on.

I'm trying to figure out how to show the options that are set, but I saw your question about NLS, and I know the answer for that: Yes, I have it turned off in LiveSystem-make.conf. Here's the whole file:
OPTIONS_UNSET=
OPTIONS_UNSET+=CUPS
OPTIONS_UNSET+=DEBUG
OPTIONS_UNSET+=DOCS
OPTIONS_UNSET+=EXAMPLES
OPTIONS_UNSET+=GUI
OPTIONS_UNSET+=IPV6
OPTIONS_UNSET+=NLS
OPTIONS_UNSET+=X11

Do you know of any reason why I shouldn't just turn it back on to try to get things working (as a short-term fix)?

I think this is what you asked for?
# pkg options devel/subversion
subversion - BDB: off
subversion - DOCS: off
subversion - FREEBSD_TEMPLATE: off
subversion - GPG_AGENT: on
subversion - NLS: off
subversion - SASL: off
subversion - SERF: on
subversion - STATIC: off
subversion - SVNSERVE_WRAPPER: off
subversion - TEST: off
subversion - TOOLS: on

yes, that's what I needed.

FYI the freshports showing gettext is misleading.  You can see the freshports version was built with NLS=ON so that's why it includes gettext.

This is harder than I thought.
It might be python causing it.

USES=python add is a run-depends:

so python is added a run depends that somehow isn't specified in the package manifest.  Maybe.
I think pkg will list out library and run dependencies of a package.  can you figure out how and display that here?

I'll try. But to be clear, you want to see that list for the svn package, right?

yes, I want to see the libraries and run dependencies the svn package is asking for

# pkg info -dependencies devel/subversion
subversion-1.14.2_2:
        serf-1.3.9_6
        utf8proc-2.8.0
        expat-2.5.0
        gnupg-2.3.8
        apr-<IP_ADDRESS>.6.1_2
        sqlite3-3.40.1,1
        liblz4-1.9.4,1
# pkg info --required-shlibs devel/subversion
subversion-1.14.2_2:
        libutf8proc.so.2
        libsqlite3.so.0
        libserf-1.so.1
        liblz4.so.1
        libexpat.so.1
        libaprutil-1.so.0
        libapr-1.so.0

okay, so python isn't registered as a run dependency but synth expects that it will be.
So I just looked up what "env" actually means.

so synth doesn't know this (it must be new) so it's expecting a python dependency that doesn't get included.
To test the theory, you change change the subversion "Makefile" line from
USES+=			shebangfix python:3.5+,env
to
USES+=			shebangfix python:3.5+,build
Then the problem will probably go away.
Synth would need to be modified to understand python:env is this is what is happening.
Which also means this is NOT a port bug as I expected

OK, I'll give it a shot and let you know what happens

I'm not 100% sure it is python:env causing this.  I may have to really dig into what's happening in the framework - hopefully I can reproduce it.  I haven't used ports in years ...

OK, thanks for letting me know. BTW I've been waiting on synth status to scan the ports tree, and it just finished a moment ago. The build should only take a minute or two.

No luck - same thing:
# synth rebuild-repository
Stand by, prescanning existing packages.
Stand by, recursively scanning 264 ports serially.
Scanning existing packages.
subversion-1.14.2_2.pkg failed dependency check.
py39-subversion-1.14.2_2.pkg failed dependency check.
py39-viewvc-devel-<IP_ADDRESS>30104.pkg failed dependency check.
mod_dav_svn-1.14.2.pkg failed dependency check.
Packages validated, rebuilding local repository.
Local repository successfully rebuilt

Just to be explicit, the same details in 06_obsolete_packages.log, too.

okay.  I might actually be glad about that.
Right now my freebsd machine is actually churning on netbsd projects (I swapped SSD out), but I do have access to a dragonfly machine.  Let me see if I can reproduce it there.  One I reproduce it, I can probably figure out what odd dependency is and go from there.  Whatever this is, it's not trivial like I assumed.

For what it's worth, I've done a manual make install clean (which I know is a synth no-no, but hey), and it seems to have worked fine.

so I was not able to reproduce using dports with the exact same profile makefile options.  So I'll have to try again when I get access to the freebsd again.

I could not recreated this on freebsd either.

am I missing something?

Well, first, I don't see you having done a rebuild-repository. That's when the issue happens for me. This is how I do it:
(1) synth status : Shows that svn and such need to be built (as well as unrelated packages, if applicable)
(2) synth just-build : Builds everything that synth status said it needed to build, including svn and such, successfully.
Note that to this point everything seems to be working fine. But:
(3) synth rebuild-repository: Complains about svn and such (details including log message shown in the original post in this thread), and deletes them. They do not actually make it into synth's repository from which I otherwise would be able to pkg upgrade them.
Second, unrelated to your question, but:
Is there perhaps some sort of metadata file (or files) which may be corrupted on my machine, leading to an issue like this? I have taken shots in the dark regarding ones that I know about; for example, I have tried entirely deleting /var/synth so as to force everything to be rebuilt from scratch (did not help). I know I've tried at least one other thing along those lines (which also did not help), but it's been a while, so I might be misremembering exactly what this second one was, but I suspect it was something like getting rid of /usr/ports and then reinitializing it with a portsnap fetch extract or whatever the command is.

okay, I'll rebuild the repository and try again when the machine is free

I think this mimics what you did.  It did the recursive scan.  But it's still not getting erased.

for fun I answered yes - still the same.

I might be misunderstanding something here, but in case not: To remind you, doing a "build" and then answering "yes" is not the same as doing a "just-build" and then a separate "rebuild-repository". Specifically (though perhaps among other things; I dunno) "build/yes" does not delete remove packages.

but as you can see from the images I posted, I did do a "build" and a separate rebuild-repository command.

Ah, OK; I was looking in the screenshot where you said you answered "yes".
So, do you perhaps know of any metadata file or files that might cause a situation like this if they get corrupted? I've tried (for example) deleting /var/synth before commencing on my standard building procedure.

Also, I'm wondering if you turned on the OPTIONS_UNSET for NLS this time, too?

it's definitely some kind of environment variable or make.conf variable causing it.  I apparently can't replicate the environment.  It's 12.2 release machine though.  Probably doesn't make a difference; just pointing it out.

it might help if you publish your log file and provide a link to it

Yes, that's a definite difference (at least in and of itself - I have no opinion on whether it makes a difference or not), as I'm on 13.1

I actually have been trying again for the past while; I thought maybe the reason it was working for you was perhaps that something in svn (or whatever) got updated at some point in the past couple weeks. I'll post the log files when it's done.

Gonna be a while... it's in the middle of building some things that usually take a _long* time (rust, openjdk8, gcc6-aux), and after them, it's got ten more to do.

OK, it's finished (and the same thing happened as before). The logs are attached. The problem shows up in 06_obsolete_packages.log.
Is there any other info I might be able to provide that might help? Thanks.
synthlogs.zip

it's enough for now.  I have to wait until my freebsd machine stops building before continuing though.

Small piece of additional info: I thought maybe something wrong had gotten into ccache somehow, so I emptied the cache and tried again. Same thing happened.

Some more info, this time I think potentially interesting:
I decided to enable NLS (and DOCS, which I did for an unrelated reason and probably shouldn't have done at the same time as this experiment; sorry). Virtually the same thing happened. I say "virtually" because the end result was the same; the difference is only in exactly why it decided to delete the svn package (which isn't noticeable without looking at the logs):
This time, instead of devel/subversion package has less dependencies than the port requires (8), the 06_obsolete_packages.log file said devel/subversion package has less dependencies than the port requires (9). To be clear, it now says 9, previously 8.
Plus, it now lists 8 packages (previously 7) that it finds. The one extra, relative to without NLS, is gettext-runtime-0.21.1... that is, the same one that it seemed to be missing originally.
So, enabling NLS did make it add the appropriate dependency, but since it also bumped up the number of expected dependency, it seems like perhaps the "missing" dependency is something else entirely.
I am attaching the logs.
synthlogs-nls.zip

so I probably didn't say it clearly, but I rejected gettext as being the problem originally once I realized you had NLS turned off.  gettext is wild goose.  That's why turning NLS back on didn't change anything.
so are you saying you are still seing it?   If I can't reproduce this with a stock system, I won't be able to get too much further.  I really need to break into the build to see the values of the makefile variables.

Yes, I'm still seeing it.
Do the logs that I've attached not show the values of the makefile variables?

it only shows the variables that are intentionally displayed.
I really need to query the makefile interactively.
right now the only difference we've identified is the OS release though.  I don't understand how it's not reproducible.

the previous set of logs seems to use the "build" option on devel/subversion.  Can you build with "test" and post just the log for devel/subversion?

Sure, but not right now - I'm currently rebuilding everything without NLS again. That will take hours (due to lang/rust), and I will likely be asleep by the time it finishes.

Oooh, looks like it doesn't have to build lang/rust! It should finish soon. I'll do the "test" thing soon.

OK, here's the subversion log when done with "test" instead of "build":
devel___subversion.log

so the "synth" of ravenports is called "ravenadm".  In test mode it unistalls everything so that that installing the target port causes all the dependencies to install first.  It can be very informative.
Unfortunately, synth doesn't do this.  your log saw subversion only being installed on an already populated environment so it wasn't too helpful.  I'll keep look to see any anything stands out, but I still don't even though which dependency is the missing one.  I'll go review the stuff you posted at the beginning of the thread too.

here's the package I built a few days ago.

libintl is missing from what you posted.  That might be the culprit

Might it help if I do something like delete everything from /var/synth/live_packages and then do the synth test devel/subversion again?

no, don't do that

what is the output of this command?
/bin/sh -c "find / -name libintl.so 2>/dev/null"

This is in my log.  you don't have it.
===>   Returning to build of subversion-1.14.2_2
===>   subversion-1.14.2_2 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)

suspicious.  I'm going to check the makefile now.

ah shoot, NLS is on.  How did that happen?

NLS option isn't getting respected:

How did you manage to get NLS off?  did you run the make options dialog?

I have not yet processed your most recent posts. I will respond to them soon.
The output of that command is... very slow. It's still going. It has found /usr/local/lib/libintl.so, and I'll let you know if it finds any others (it has finished while I was typing this comment - that's the only one it found).
That library is the one that I originally suggested might be related to the issue in the original post. This is installed by gettext, which you had found is brought in by NLS.

It's been a long time since I ran ports.  I can't remember where the options are saved.  I think I had a script to clear those.  I suspect you've set options for subversion.

The only thing I know of that I did to turn NLS off was to OPTIONS_UNSET it in the LiveSystem-makefile.conf file (or whatever it's called). I may at some point in the past run make config, but I do not currently have any non-default options set for any port (checked via /usr/ports/Tools/scripts/redundant-opt-files.sh).

no, you did something else.  I seem to recall you cannot globally turn off NLS in ports.
do you have /var/db/ports directory?
if so, do you have /var/db/ports/subversion  directory?

I notice that NLS is not the only one not being respected in your screenshots. For example, you have DOCS turned off in the makefile, but it says it's on in the "here are the configuration options" thing.

I have a /var/db/ports directory. It is completely empty.

something is wrong on my end.
on this section of the log:

you have the options unset (from your make..conf).  It's not showing up in mine.  I will review to find my error and try again.

I seem to recall you cannot globally turn off NLS in ports.

I don't think this is correct. I can successfully turn it on and off by removing or adding it to OPTIONS_UNSET in the makefile. And again, NLS is not the only thing that your build process doesn't seem to be respecting.

yes, I agreed something was wrong.  And it's been a been a long time so the NLS/DOC option limitation could easily be obsolete.

There's an entry in pkg updating from Dec. 14, 2017 mentioning that "soon", the "WITHOUT_NLS" option would be removed, and replaced with "OPTION_UNSET=NLS" (and, more generically, WITHOUT_xxx by OPTIONS_UNSET=xxx). Looks like FreeBSD 12.2 was released well after that (October 2020), but I don't know what they mean by "soon". Is it possible that 12.2 doesn't yet have support for OPTIONS_UNSET?

no, my entire LiveSystem-make.conf file is being completely ignored.  I'm trying to figure out why.  It's not showing  in the log like yours is.

The man page says put it here:
/usr/local/etc/synth/LiveSystem-make.conf
That's where your file is, right?  I can't figure out why it's not getting picked up.

Yes, that's where mine is.
That's where it should be if you're using the LiveSystem profile, but it should be elsewhere if not. I see mention of "LiveSystem" in your screenshots, so I'm guessing you're using that profile, but I just want to be sure.

yes.  I should have specified I'm using the default profile "LiveSystem"

so I figured it out -- feeling kind of dumb.
so as you may know, people are trying to remove synth from freebsd ports.
I moved synth over to ravenports so at least people could install it an keep using it.
I've been running the synth version installed there, meaning the location is /raven/etc/synth, not /usr/local/etc/synth.  And the man page wasn't updated (something I've got to fix).
Let me try again.

Thank you!

I rebuilt everything from scratch with the new make.conf.  At first glance it seems I didn't reproduce it.

Progress (I think):
I put some debugging code into portscan.adb to try to see what dependencies it was determining subversion needs, and:
asdf: devel/apr1 ...  1;  0
asdf: databases/sqlite3@default ...  2;  0
asdf: textproc/expat2 ...  3;  0
asdf: textproc/utf8proc ...  4;  0
asdf: archivers/liblz4 ...  5;  0
asdf: www/serf ...  6;  0
asdf: security/gnupg ...  7;  0
asdf: print/indexinfo ...  8;  0

That last one, "print/indexinfo", is not present in the list of dependencies found in the output of 06_obsolete_packages.log.
I don't know enough about the FreeBSD makefile system to easily figure out why either:
(1) Subversion really does want this port, but it's not being built; or
(2) Subversion doesn't want this port, but Synth thinks it does.
I'll keep poking, but if you have any suggestions based upon this new information, I'm all ears.

Interestingly, unless there's some other possible interpretation of "synth status wouldn't build it", then I guess that port actually is present in the synth repository:
# synth status print/indexinfo
These are the ports that would be built ([N]ew, [R]ebuild, [U]pgrade):
Total packages that would be built: 0
The complete build list can also be found at:
/var/synth/synth_status_results.txt

does freebsd 13 have indexinfo installed in /usr/bin ?

No, at least not for me (I don't know anything about indexinfo, so I can't say for sure in general). Mine is in /usr/local/bin.

it is in bsd.port.mk

I don't know how INFO got defined yet.

It's not defined in my build environment:

if you do
env ENTERAFTER=patch synth test devel/subversion

and when you get a prompt,
cd /port
make -VINFO

do you get anythng printed out?

oops, wrong instructions
I guess it's :
cd /xports/devel/subversion
make -VINFO

Trying now, but it will take a while due to regenerating the flavor index. In the meantime: Before I started that, I tried a few things that have results that I don't really understand, but that may or may not be interesting:
[root@silicon /usr/ports/devel/subversion]# make -V INFO
/root/.gnupg/S.gpg-agent::
[root@silicon /usr/ports/devel/subversion]# echo $INFO

[root@silicon /usr/ports/devel/subversion]#

The value there is my gnupg agent string, which surprised me. I then figured maybe I had somehow accidentally set $INFO to it in my environment, but apparently not. My $GPG_AGENT_INFO is set to it, which I believe is correct:
[root@silicon /var/log/synth]# env | grep gpg-agent
GPG_AGENT_INFO=/root/.gnupg/S.gpg-agent::
[root@silicon /var/log/synth]#

I then guessed maybe I was accidentally setting it in non-interactive shells, but I don't think so:
[root@silicon /stuff/tmpsynth]# cat shgp
#/bin/sh

echo $INFO

[root@silicon /stuff/tmpsynth]# cat bashgp
#/usr/local/bin/bash

echo $INFO

[root@silicon /stuff/tmpsynth]# ./shgp

[root@silicon /stuff/tmpsynth]# ./bashgp

[root@silicon /stuff/tmpsynth]#

you're doing it from the tree.  I need you do it from "env ENTERAFTER=patch synth test editors/synth".
try this command too:
make -VLIB_DEPENDS -VRUN_DEPENDS | tr " " "\n" | sort -u

I know I did it from the tree - I just wanted to see what it said before I started on the potentially long synth test.
I am still waiting for it, but it should be done soon.

[root@silicon /stuff/tmpsynth]# env ENTERAFTER=patch synth test devel/subversion
*******************************************************************
 The ports tree has at least one file newer than the flavor index.
 However, port directories perfectly match.  Should the index be
 regenerated? (Y/N) yes
*******************************************************************
Regenerating flavor index: this may take a while ...
Scanning entire ports tree.
Scanning existing packages.
After inspection, it has been determined that there are no packages that
require rebuilding; the task is therefore complete.
Starting interactive build of devel/subversion
Stand by, building up to the point requested ...
Entering interactive test mode at the builder root directory.
Type 'exit' when done exploring.
# cd xports/devel/subversion
# make -VINFO

# make -VLIB_DEPENDS -VRUN_DEPENDS | tr " " "\n" | sort -u

gpg-agent:security/gnupg
libapr-1.so:devel/apr1
libexpat.so:textproc/expat2
liblz4.so:archivers/liblz4
libserf-1.so:www/serf
libsqlite3.so:databases/sqlite3
libutf8proc.so:textproc/utf8proc
#

hmm.  No info there.
try -VFETCH_DEPENDS -VEXTRACT_DEPENDS -VPATCH_DEPENDS -VRUN_DEPENDS individually.
I get "gpg-agent:security/gnupg" on RUN_DEPENDS

I think you saw indexinfo from another port, e.g. gnupg:

# make -VFETCH_DEPENDS

# make -VEXTRACT_DEPENDS

# make -VPATCH_DEPENDS

# make -VRUN_DEPENDS
gpg-agent:security/gnupg
#

I think indexinfo might be a goose chase.  the trace you saw wasn't from subversion but one of it's dependencies.

your dependencies match mine exactly

I'm not sure if I understand your "saw indexinfo from another port" post, but if you're saying maybe I ran the command from security/gnupg, then no, I ran it from devel/subversion.

You added a trace command to portscan.  the indexinfo it printed out wasn't from subversion but probably gnupg.

I think indexinfo might be a goose chase. the trace you saw wasn't from subversion but one of it's dependencies.

I'm not sure if I understand this one either, but the debugging output from portscan.adb shows print/indexinfo as the eighth dependency that devel/subversion picks up.

how do you know it's the 8th dep of subversion and not the first dep of a one of it's dependencies?

hold on. you might be right

crap, wrong directory, ignore.

so this is the full query.  no indexinfo anywhere.

i only see 7 deps here.

your query also comes back with 7 deps.  I'm not sure where the 8 is coming from on your setup.

how do you know it's the 8th dep of subversion and not the first dep of a one of it's dependencies?

Well, I guess I don't know, as I'm totally new to synth's code, but here's why I think it:
(1) I looked at where the "has less dependencies" message is coming from, which is portscan-packages.adb:
         if counter < min_deps then
            --  The ports tree requires more dependencies than the existing
            --  package does
            declare
               msg : String :=
                 headport & " package has less dependencies than the port " &
                 "requires (" & JT.int2str (min_deps) & ")" & LAT.LF &
                 "Query: " & JT.USS (query_result);
            begin
               obsolete_notice (msg, debug_dep_check);
            end;
            return False;
         end if;

So this "min_deps" is what the "8" in the original message is; I then looked for where that was set:
min_deps : constant Natural := all_ports (id).min_librun;

Then looked for min_librun, which is set in portscan.adb's populate_set_depends proc:
               if dtype in LR_set then
                  if not all_ports (target).librun.Contains (depindex) then
                     all_ports (target).librun.Insert
                       (Key      => depindex,
                        New_Item => depindex);
                     all_ports (target).min_librun :=
                       all_ports (target).min_librun + 1;
                     case software_framework is
                        when ports_collection => null;
                        when pkgsrc =>
                           if fulldep (1) = '{' then
                              bracketed := bracketed + 1;
                           end if;
                     end case;
                  end if;
               end if;

That's the only place where min_librun is set, except two instances: (1) when being initialized to zero, (2) in the case of "bracketing" being grater than zero. I don't know what the "bracketing" stuff is, but I decided to mostly ignore it for the moment and then change the code that I showed above to the following, by inserting the stuff within the "--asdf begin" and "--asdf end" lines:
               if dtype in LR_set then
                  if not all_ports (target).librun.Contains (depindex) then
                     all_ports (target).librun.Insert
                       (Key      => depindex,
                        New_Item => depindex);
                     all_ports (target).min_librun :=
                       all_ports (target).min_librun + 1;
                     case software_framework is
                        when ports_collection => null;
                        when pkgsrc =>
                           if fulldep (1) = '{' then
                              bracketed := bracketed + 1;
                           end if;
                     end case;

-- asdf begin
                     if catport = "devel/subversion" then
                        TIO.Put ("asdf: ");
                        TIO.Put (get_catport (all_ports (depindex)));
                        TIO.Put (" ... ");
                        TIO.Put (Integer'Image(all_ports (target).min_librun));
                        TIO.Put ("; ");
                        TIO.Put_Line (Integer'Image(bracketed));
                     end if;
-- asdf end
                  end if;
               end if;

Running that gave the output that I showed earlier:
asdf: devel/apr1 ...  1;  0
asdf: databases/sqlite3@default ...  2;  0
asdf: textproc/expat2 ...  3;  0
asdf: textproc/utf8proc ...  4;  0
asdf: archivers/liblz4 ...  5;  0
asdf: www/serf ...  6;  0
asdf: security/gnupg ...  7;  0
asdf: print/indexinfo ...  8;  0

That is, unless I'm misunderstanding the code, Synth has decided that these eight packages are the eight packages that it later says Subversion needs, and the fact that Synth only finds seven packages after having built Subversion is what's leading it to delete the Subversion package.
Am I wrong in any of this?

Also, to be explicit, note that all of those messages show "bracketed" as zero, and bracketed is only ever changed inside of the code that I quoted, so the fact that I ignored the "min_librun is changed if bracketed is greater than zero" case is irrelevant.

so "synth build devel/subversion" won't rebuild a newly built subversion package (so it passes validation) but "synth rebuild-repository" invalidates the same package?

To be further explicit:
(1) The line I quoted from portscan-packages.adb, where min_deps is being initialized to min_librun from the target point, is the only place where min_deps has its value changed.
(2) Regardless of whether my interpretation of "the librun value of a port" being "the direct librun dependencies of that port" is correct or not, the fact that Synth is giving that variable eight entries, but can later only find seven dependencies after having built Subversion (with print/indexinfo being the "missing" one), sure seems to be the cause of Synth deciding to delete Subversion.
So, I think the question is now:
(1) Why does Synth put print/indexinfo into the librun var for the subversion port's object? Possible answers I see: (A) Because Subversion actually does depend on print/indexinfo; (B) Because of some bug in Synth; (C) Because of some weirdness on my system. I'm guessing it's (C), but I don't know.
(2) After having build Subversion, why does Synth not find indexinfo in Subversion's dependencies, despite having put it into the librun var for the subversion port's object? I'm guessing the answer here is "Because the answer to (1) is (C) (or, possibly but seemingly less likely, (B)), and therefore print/indexinfo is not actually required by Subversion, and therefore correctly not referenced into Subversion when Synth builds it".

so "synth build devel/subversion" won't rebuild a newly built subversion package (so it passes validation) but "synth rebuild-repository" invalidates the same package?

I use "synth status" followed by "synth just-build" and then "synth rebuild-repository", and it behaves as thus:
(1) "synth status" says svn needs to be rebuilt.
(2) "synth just-build" builds it.
(3) "synth rebuild-repository" deletes it.
I will try with "synth build" and let you know what happens.

synth status is specific to the localhost.  Since I don't have any of these packages installed, it makes no sense for me to run it.  It shouldn't matter anyway.  repository rebuilds has nothing to do with what's on the localhost.

what happens if you run "synth just-build devel/subversion" twice in a row?

If I do a "synth build" and answer "y" to the 'rebuild repository" question, Synth deletes subversion then.
If I do a "synth build" and answer "n", followed by a "synth rebuild-repository", Synth deletes subversion then.
If I do a "synth build" and answer "n", followed by another "synth build", Synth deletes subversion then, and then builds it again.

Didn't see your "just-build" question until after I had replied to your "build" question. I imagine it will be the same (i.e. Synth will delete it and rebuild it), but I'll try it and let you know.

Whoops, small (I think) mistake: "synth build" followed by "synth build" does not "delete Subversion and then builds it again", but "notes that Subversion failed the dependency check and then builds it again.

And the same with two "just-build" in a row: It gets built both times due to a failed dependency check.

so it's not the rebuild-repository doing it.  it's failing every single validity check.
I am definitely not seeing it.
You ran the query, only 7 dependencies were listed if I understand correctly.  I would have expected to see 8 with that query.

You ran the query, only 7 dependencies were listed if I understand correctly. I would have expected to see 8 with that query.

Well, Synth ran the query, but otherwise: Yeah, that's what I'm saying. Synth sees seven dependencies. And it then decides to delete Subversion because it previously decided that svn should have EIGHT dependencies.
And the missing one is print/indexinfo. Which is present both on my machine and in the synth repository.

what is on your machine is irrelevant.
you can try this as a test.  edit bsd.port.mk.
go to around line 2691, which is:
RUN_DEPENDS+=	indexinfo:print/indexinfo
change it to:
.if ${PORTNAME} != "subversion"
RUN_DEPENDS+=	indexinfo:print/indexinfo
.endif
and try again.  If the rebuild stops happening at least we know that's where indexinfo is getting added.

Yes, that seems to be where it's coming from. After adding that "if", neither just-build nor rebuild-repository decides that subversion has failed the dependency check anymore.

Is there a way in the make language to just output a variable to stdout?

echo "${NAME}" but it has to be part of a target

something is getting introduced into the build environment that defines INFO.  Not sure where.

Is the do_build target in the synth's makefile an appropriate place to try to see what the value of INFO is? I put some code in there to print it out, but it seems to be blank. Code:
        (echo asdfasdfasdf)
        (echo "${INFO}")
        (echo asdfasdfasdf)

... and output:
(echo asdfasdfasdf)
asdfasdfasdf
(echo "")

(echo asdfasdfasdf)
asdfasdfasdf

Whoops, never mind - obviously should have put it in subversion's makefile. I'll try that next.

I put it into svn's do-build; same result (shows as nothing). Tried both ${INFO} and $(INFO); no idea whether that matters, but they both show as nothing.

i think that's expected.
It's not defining INFO during the build, but during the validation scan (somehow)

Narrowed it down. In /usr/ports/mk/bsd.options.mk, around line 535:
.        if defined(${opt}_${flags})
${flags}+=      ${${opt}_${flags}}
.        endif

That's inside a nested loop (lot of other things in the loop are not shown here):
.  for opt in ${_REALLY_ALL_POSSIBLE_OPTIONS}
.      for flags in ${_OPTIONS_FLAGS}
.        if defined(${opt}_${flags})
${flags}+=      ${${opt}_${flags}}
.        endif
.      endfor
.  endfor

One of the iterations hits ``opt`` = "GPG_AGENT" and ``flags`` = "INFO", thus causing it to add the value of my ``${GPG_AGENT_INFO}`` to ``${flags}`` as ${opt}.

I haven't yet checked whether the apparent change in behavior is due to a change in Subversion's ``Makefile``, or a change in FreeBSD 13.1's ``bsd.options.mk``, or what.

As a side note, it's almost unbelievable to me that variables named so incredibly generically, e.g. ``$INFO``, which I could easily imagine being set in the environment nonmaliciously for totally unrelated purposes, are used for such important functionality deep inside the guts of such a fundamental part of the system. How on earth is someone who doesn't live and breath "internals of the FreeBSD ports/packages make system" supposed to know to never, ever name a variable "$INFO", or at the very least to never, ever export it?

In any case, this now seems pretty clearly outside of synth, so I'll close this ticket. If you disagree, please let me know and I'll reopen it.
Or if out of the kindness of your heart you want to give me any suggestions on how to proceed, please let me know that too :)
Thanks for all your help.

well, I'd like to see it through.  It's probably one of those things that's obvious when the problem is found.
just curious - is subversion the only port that exhibited this behavior?
I still think INFO Is getting defined somehow - just not sure how.

OK, I've reopened it.
Regarding "I still think INFO is getting defined somehow", yes, I was trying to say that it was happening right there in that code, but I miswrote something important and garbled the message. When I wrote:

thus causing it to add the value of my ${GPG_AGENT_INFO} to ${flags} as ${opt}.

I meant:

thus causing it to add the value of my ${GPG_AGENT_INFO} to ${flags}

That is, in that particular iteration, it set ${flags} (which had been "INFO") to "INFO /root/.gnupg/S.gpg_agent::". I don't know exactly how the syntax works there, but I do know that immediately before execution of that ${flags} += line, the value of $INFO was not set, whereas immediately after the execution of that same line, the value was equal to the value of my ${GPG_AGENT_INFO}.

where is GPG_AGENT_INFO defined?
do you have an idea why I'm not seeing it?  Is ther something specific about your setup?

Oh, sorry, and:

just curious - is subversion the only port that exhibited this behavior?

Yes, at least for me.

where is GPG_AGENT_INFO defined?

I have it defined during my bash setup for interactive shells (as suggested here in the gnupg documentation):
GPG_AGENT_INFO=$(gpgconf --list-dirs agent-socket | tr -d '\n' && printf ::)

do you have an idea why I'm not seeing it? Is there something specific about your setup?

I don't know. You're using an earlier version of FreeBSD; maybe something in the make system changed? Or maybe something in the Subversion makefile? Or maybe there's a bug in my bash startup, where I'm actually doing setting $GPG_AGENT_INFO for more than just interactive shells? I'll check on that.

Hmmm - so if your local environment is affecting his (probably using the local package) then I need to adjust synth to erase that environment first.  so that would fall into the category of a bug.

It's not just synth, though - this happens when I do a raw make from the command line too. The only difference is that synth cares that make is saying svn requires print/indexinfo but simultaneously svn was not compiled to refer to print/indexinfo (it decides to delete synth because of this). Make doesn't actually care that svn isn't compiled to refer to print/indexinfo, despite the fact that make itself is what decided svn should be compiled so.

Do you have $GNUPG_AGENT_INFO set on your machine? I thought I remembered seeing it in one of your screenshots earlier, but I haven't yet been able to find it again just now.

No. Anyway, that solves the mystery.
The package is built in a controlled environment, so it's built correctly.
The validation must be using the host pkg, and thus exposed to local environment, and it's corrupting check.
I'm looking for command to test this theory, I just need a few minutes.

okay, here's the test:

revert that change you made to bsd.port.mk
build devel/subversion
run this exactly:

env -i TERM=xterm synth rebuild-repository

I did not need to use the absolute path.  Maybe you have to, not sure.
If your theory is correct, I expect it will not delete subversion this time.

I don't use X. I'm not sure that that matters, but I want to point it out before deciding to issue that command just in case.

I don't think it matters.  XTERM just needs some definition or synth complains

OK, I'll try it and let you know.

While waiting for the regeneration of the flavor index, I figured I might as well try this:
[root@silicon ~]# cat ./blah
#!/usr/local/bin/bash

echo $GPG_AGENT_INFO
[root@silicon ~]#
[root@silicon ~]#
[root@silicon ~]# ./blah
/root/.gnupg/S.gpg-agent::
[root@silicon ~]# env -i ./blah

[root@silicon ~]#

OK, first, control test just to be sure:
(1) synth rebuild-repository
(2) synth just-build devel/subversion
(3) synth just-build devel/subversion

Behavior same as previously:
(1) synth deletes subversion
(2) synth builds subversion
(3) synth deletes then builds subversion
And now the test you asked for:
(4) synth rebuild-repository
(5) synth just-build devel/subversion
(6) env -i TERM=xterm synth rebuild-repository

Behavior different than previously:
(4) synth deletes subversion
(5) synth builds subversion
(6) synth does not delete subversion

so that confirms your theory
I'll see if I can fix synth so you don't need this workaround.

Thanks, but hold on, I'm not so sure that it's synth's problem... I'm in the middle of typing something up about this, but I just saw your comment and figured I should say something before finishing mine.

So it seems like this is due to the combination of several factors, all of which are necessary for the problem to happen:
(1) Subversion's makefile using the option GPG_AGENT
(2) GNUPG-AGENT requiring (or at least suggesting, I dunno) the exported environment variable $GPG_AGENT_INFO
(3) FreeBSD's make stuff deciding that since (A) GPG_AGENT is one of the options for Subversion, and (B) the environment variable $GPG_AGENT_INFO exists, it should therefore set the variable INFO to the value of $GPG_AGENT_INFO
(4) FreeBSD's make stuff further deciding that since INFO is set, Subversion therefore requires print/indexinfo
(5) Subversion not actually needing print/indexinfo
(6) Synth deciding that since it was told Subversion needs print/indexinfo but that the Subversion executable as built does not actually need print/indexinfo, it should therefore delete Subversion
From all that, it seems to me that Synth is doing exactly what it should be doing based upon what it has been told by make and upon what making Subversion actually results in.
I gather that you're intending to change Synth so that it wipes out the local environment... but isn't that potentially problematic in the event that some port actually does require print/indexinfo?
I guess I don't know enough about all this, but I'm wondering if perhaps the actual problem is that Make shouldn't be saying Subversion requires print/indexinfo. If GNUPG-AGENT requires it, then GNUPG-AGENT's make process should say so, not Subversion's -- even if that means that Subversion requires print/indexinfo indirectly.
Am I mistaken here?

I gather that you're intending to change Synth so that it wipes out the local environment... but isn't that potentially problematic in the event that some port actually does require print/indexinfo?

yes, that's exactly what I going to do.
No, it is not problematic because INFO is now set through the port framework like it's supposed to be.
You are correct in saying it's not strictly a synth issue because GNUPG-AGENT should affect ports live as well.  But the whole point of synth is to control the environment as it does during the build.  Really a builder should be opened for the make queries to avoid environment corruption, but it was easier to use the host make.
So that's why I consider it a synth bug -- because it failed to control the environment.
Plus I just realized that 2 major bug fixes were never published.  2.13 needs to come out anyway.

OK, great. Thanks. In the meantime, doing the workaround's no big deal.
Incidentally, just as another little point of evidence for the theory: All this did start happening right around the time that I started using GNUPG-AGENT with Subversion, so I guess that the problem (whatever it actually is at the lowest level) might have been very longstanding rather than due to something like a change in FreeBSD's make, or Subversion's makefile.

yes, it just took a special combination to hit.
So it looks like I am using the chroot make but the environment is probably bleeding through.  I'll test to be sure, then work on the fix.

confirmed, it's all bleeding through.

looks good:

I'll tag this v2.13 if you can verify it works.
Go to the ports-mgmt/synth and modify the makefile by adding:
GH_TAGNAME= cc05e2d
and changing DISTVERSION to 2.13
and changing PORTREVISION to 0
then generate a new distinfo, build, and test.

Great, thanks so very much!
I will definitely give it a try and let you know, but I'm not very confident that I will be able to do so tonight.

Works great! I think... I noticed one thing that I'm guessing might just be an unimportant thing caused by the abnormal way I did this (i.e. directly changing Synth's Makefile), but I figured I should run it past you to be sure. After having done a synth status, synth just-build, synth rebuild-repository, and pkg upgrade:
[root@silicon /stuff/packageInfo]# pkg version -v > targets/host/installedPackages
[root@silicon /stuff/packageInfo]# grep -v up-to-date targets/host/installedPackages
synth-2.13                         >   succeeds index (index has 2.12_1)
[root@silicon /stuff/packageInfo]#

So whatever "index" this is referring to was not updated as a part of all this. I am guessing that that's expected and nonproblematic, but again, I just want to run it past you to be sure.

it's fine.  The pkg program is checking the publish ports index to try to determine which installed packages are out of date, and it's squawking that this port is newer than what's published.  expected; not an issue.

I tagged it and published it as a release.
Would you do me a favor and contact the freebsd port maintainer for synth and ask him to update to that release?
You can close this issue too.

Will do.
Once again, thanks very much!


Update test_agents_client.py, test_agents_client_async.py, and conftest.py

Description

Updates test files to include streaming functions and user_functions using various input types.
Updates both test files to use with self.create_client() as client:  instead of creating and deleting the client in each function
Skips certain tests depending on region deployment or sanitation issues, which I am looking into now
Updates conftest.py to remove batch sanitizer for ID, but leaves agents tests skipped -- I will upload recordings next.

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-projects

@microsoft-github-policy-service agree company="Microsoft"

From: microsoft-github-policy-service[bot] @.>
Sent: Friday, November 22, 2024 3:10 PM
To: Azure/azure-sdk-for-python @.>
Cc: Sophia Ramsey @.>; Mention @.>
Subject: Re: [Azure/azure-sdk-for-python] Update test_agents_client.py, test_agents_client_async.py, and conftest.py (PR #38656)
@sophia-ramseyhttps://github.com/sophia-ramsey please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
@microsoft-github-policy-service agree [company="{your company}"]
Options:

(default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@microsoft-github-policy-service agree

(when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@microsoft-github-policy-service agree company="Microsoft"
Contributor License Agreement
Contribution License Agreement
This Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
and conveys certain license rights to Microsoft Corporation and its affiliates (“Microsoft”) for Your
contributions to Microsoft open source projects. This Agreement is effective as of the latest signature
date below.

Definitions.
“Code” means the computer software code, whether in human-readable or machine-executable form,
that is delivered by You to Microsoft under this Agreement.
“Project” means any of the projects owned or managed by Microsoft and offered under a license
approved by the Open Source Initiative (www.opensource.orghttp://www.opensource.org/).
“Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any
Project, including but not limited to communication on electronic mailing lists, source code control
systems, and issue tracking systems that are managed by, or on behalf of, the Project for the purpose of
discussing and improving that Project, but excluding communication that is conspicuously marked or
otherwise designated in writing by You as “Not a Submission.”
“Submission” means the Code and any other copyrightable material Submitted by You, including any
associated comments and documentation.
Your Submission. You must agree to the terms of this Agreement before making a Submission to any
Project. This Agreement covers any and all Submissions that You, now or in the future (except as
described in Section 4 below), Submit to any Project.
Originality of Work. You represent that each of Your Submissions is entirely Your original work.
Should You wish to Submit materials that are not Your original work, You may Submit them separately
to the Project if You (a) retain all copyright and license information that was in the materials as You
received them, (b) in the description accompanying Your Submission, include the phrase “Submission
containing materials of a third party:” followed by the names of the third party and any licenses or other
restrictions of which You are aware, and (c) follow any other instructions in the Project’s written
guidelines concerning Submissions.
Your Employer. References to “employer” in this Agreement include Your employer or anyone else
for whom You are acting in making Your Submission, e.g. as a contractor, vendor, or agent. If Your
Submission is made in the course of Your work for an employer or Your employer has intellectual
property rights in Your Submission by contract or applicable law, You must secure permission from Your
employer to make the Submission before signing this Agreement. In that case, the term “You” in this
Agreement will refer to You and the employer collectively. If You change employers in the future and
desire to Submit additional Submissions for the new employer, then You agree to sign a new Agreement
and secure permission from the new employer before Submitting those Submissions.
Licenses.

Copyright License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license in the
Submission to reproduce, prepare derivative works of, publicly display, publicly perform, and distribute
the Submission and such derivative works, and to sublicense any or all of the foregoing rights to third
parties.
Patent License. You grant Microsoft, and those who receive the Submission directly or
indirectly from Microsoft, a perpetual, worldwide, non-exclusive, royalty-free, irrevocable license under
Your patent claims that are necessarily infringed by the Submission or the combination of the
Submission with the Project to which it was Submitted to make, have made, use, offer to sell, sell and
import or otherwise dispose of the Submission alone or with the Project.
Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement.
No additional licenses or rights whatsoever (including, without limitation, any implied licenses) are
granted by implication, exhaustion, estoppel or otherwise.

Representations and Warranties. You represent that You are legally entitled to grant the above
licenses. You represent that each of Your Submissions is entirely Your original work (except as You may
have disclosed under Section 3). You represent that You have secured permission from Your employer to
make the Submission in cases where Your Submission is made in the course of Your work for Your
employer or Your employer has intellectual property rights in Your Submission by contract or applicable
law. If You are signing this Agreement on behalf of Your employer, You represent and warrant that You
have the necessary authority to bind the listed employer to the obligations contained in this Agreement.
You are not expected to provide support for Your Submission, unless You choose to do so. UNLESS
REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING, AND EXCEPT FOR THE WARRANTIES
EXPRESSLY STATED IN SECTIONS 3, 4, AND 6, THE SUBMISSION PROVIDED UNDER THIS AGREEMENT IS
PROVIDED WITHOUT WARRANTY OF ANY KIND, INCLUDING, BUT NOT LIMITED TO, ANY WARRANTY OF
NONINFRINGEMENT, MERCHANTABILITY, OR FITNESS FOR A PARTICULAR PURPOSE.
Notice to Microsoft. You agree to notify Microsoft in writing of any facts or circumstances of which
You later become aware that would make Your representations in this Agreement inaccurate in any
respect.
Information about Submissions. You agree that contributions to Projects and information about
contributions may be maintained indefinitely and disclosed publicly, including Your name and other
information that You submit with Your Submission.
Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and
the parties consent to exclusive jurisdiction and venue in the federal courts sitting in King County,
Washington, unless no federal subject matter jurisdiction exists, in which case the parties consent to
exclusive jurisdiction and venue in the Superior Court of King County, Washington. The parties waive all
defenses of lack of personal jurisdiction and forum non-conveniens.
Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and
supersedes any and all prior agreements, understandings or communications, written or oral, between
the parties relating to the subject matter hereof. This Agreement may be assigned by Microsoft.

—
Reply to this email directly, view it on GitHubhttps://github.com/Azure/azure-sdk-for-python/pull/38656#issuecomment-2495071117, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BLIDZ7KQAMSJ726USPWLSAL2B62VLAVCNFSM6AAAAABSKLEYLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOJVGA3TCMJRG4.
You are receiving this because you were mentioned.Message ID: @.***>


channel

Hello, thank you very much for your contribution,
I have a 4 channel switch, is it possible to rename each channel individually?

Hey there,
Yes you can rename each channel individually regardless of the number of channels.
You need to do it in the Home app, not in the plugin configuration. Go into Home app, long press the switch that you wish to rename it’s channels. After that there must be a settings icon at the bottom left of the screen, press that and there will be some options to configure the switch. Click the “Accessories” option and in there you will see each channel as a seperate tile. Long press the channel you wish to rename, click the settings icon at the bottom left again and in there you can rename it.
I hope this helps.

Yes, through the homekit app I had managed,
I figured there was a way to rename the plugin.


Feature - Add Email Functionality

Email functionality is important to allow users / admins the following functionality:

[x] - Add email functionality
[x] - Create Email Configuration Documentation
[x] - Send Activation Emails for New Users - validating account information provided.
[ ] - Send Password Reset links / codes / instructions
[ ] - Enabling 2-Factor authentication
[ ] - Sending on-demand or scheduled emails to subscribers
[ ] - Notifying Admins / Users about triggered events / issues

Email functionality added via version 0.139

I am getting the error "fastapi_mail.errors.ConnectionErrors: Exception raised (535, '5.7.8 Username and Password not accepted."
My password works within Azure Functions, thus I suspect when you are reading/writing the password to the database you are not accounting for characters that need to be escaped (i.e. @, #, %).


If I override validation_end and test_epoch_end, TrainerEvaluationLoopMixin.evaluate works incorrectly on the test set

🐛 Bug
Suppose we override validation_epoch_end and test_end, but not validation_end and test_epoch_end. (I actually did this since I am a newbie and haven't yet figured out how everything works; also it seems validation_end is the same as validation_epoch_end, and test_end seems to be the same as test_epoch_end). Suppose I run trainer.test(model). Consider lines 300-312 in evaluation_loop.py. Then we have (test_mode and self.is_overriden('test_end', model=model)) == True, so the first if block is executed, that is eval_results = model.test_end(outputs). But look at the second if and its elif. We have (test_mode and self.is_overriden('test_epoch_end', model=model)) == False, hence the elif of the second if will also be executed, that is eval_results = model.validation_epoch_end(outputs). And we will have validation results recorder as test results, which is a mistake.
This problem is present in the commit 60b8246. And the inverse problem (which happens if we override only test_epoch_end and validation_end is present in 0.7.1.

I can look into this.
To summarize, there is a problem when we mix *_epoch_end (new version) and *_end (old naming)  for validation and test. There is no problem if we would consequently use only one of the two, either the deprecated or the new way. Is this correct?
I propose this fix:
if test_mode:
    if is_overriden("test_end"):
        # get results and warn user
    elif is_overriden("test_epoch_end"):
        # get results
else:
    # same as above but with "validation_end", "validation_epoch_end"

@awaelchli yes


added dropout

looks like there are a lot of formatting changes in here, which is okay, but it's usually a good idea to break those out into separate commits, so you can just have one commit that says "added dropout" and does only that

ok. I will do that from now on.


Signals store implementation breaks direct action persistence

Expected Behavior
When you interact with a mark via its handles, the mark's properties should persist once you select another mark.
Actual Behavior
No direct manipulation-originated properties persist when you select another mark: it "snaps" back to where it was.
Steps to reproduce behavior

This happens because the SignalValue mixin does not set anything on the store. A simplistic fix would be to set store values via dispatched signals while dragging a mark, and to use handle interactions to set a flag that a direct manipulation is ongoing in order to suppress the "redux flows its signals back into vega" behavior while the user is still directly manipulating the mark.
(Introduced in #310)

@deathbearbrown & I discussed two potential approaches to this today, which I want to capture here to articulate my proposed solution. To recap, the bug exists because our current flows are as follows:
(flow 1): Lyra-originated signal change gets dispatched to redux store; a store listener passes that change from the store on to vega.
(flow 2): An interaction within vega causes an internal vega-originated signal change which is listened to and rendered by the properties component, but it never makes it to the store.
What's happening in the above gif is that we're modifying a host of signal values at once by dragging the mark, but then when we use the property inspector to set one of them from Lyra's side that value gets added to the store and all of the other modified values are overwritten by their "stale" store equivalents, causing the mark to snap back.
The simplistic approach would be to always dispatch signal changes from the vega listeners that fire when a signal changes within vega, flowing those values into lyra's redux store. But the redux store listener tries to sync its state to vega, so what would happen here is that, say, you drag a mark to the right: its x property updates within vega and is dispatched to the redux store; meanwhile, you keep dragging. When the redux store learns about the signal it tries to set that in vega; the signal is now out of date, so your mark shakes back and forth between where vega thinks it should be going and where Lyra knows it was.
Solutions to that approach include

Dispatch the signal from the lyra vega listener, as usual, but flag it as originating from vega; something like the action { type: 'SET_SIGNAL', signal: 'some_signal', value: 600, fromVega: true }. The store listener which syncs the lyra state back to Vega would then skip any values that are marked as having been last-touched by vega instead of lyra's React UI.
Never update vega based on a signal change within the redux store, but ALWAYS dispatch signals to both vega and the redux store simultaneously. To elaborate,

If a signal arises in Lyra, send it both to the store (to persist it for future re-renders) and to vega (to reflect the change). Vega and store are now in sync.
If a signal arises from vega, e.g. if the user is dragging a mark, then pass it on to the redux store but do not try to pass it back to Vega; vega's up to date already, and the store and vega are now in sync.

After discussing these options it feels pretty clear that option (1) is much uglier and requires us to manage a lot more state manually, while option (2) makes it clear which changes need to be synced back and forth when. I am pursuing option (2).


Validate Mixed Clusters (windows + linux) for Azure US Gov cloud

What kind of request is this (question/bug/enhancement/feature request):
feature request
Steps to reproduce (least amount of steps as possible):
When using a non-default Azure cloud (for example US Gov), creating a Windows cluster fails due to a mismatch in the 'cloud' argument between the RKE-tools and the kubelet. The Azure Cloud provider states the valid values for the 'cloud' parameter (https://github.com/kubernetes-sigs/cloud-provider-azure/blob/master/docs/cloud-provider-config.md) but RKE-tools attempts to set the cloud name directly based on the cloud setting - which is incompatible for non-default cloud settings.
For example, the azure cloud provider states 'AzureUSGovernmentCloud' is a valid entry, whilst the command az cloud show shows the cloud name is AzureUSGovernment. rke-tools uses the 'cloud' entry as part of the cloud-config (https://github.com/rancher/rke-tools/blob/64c1facb4b6e5685f9ec70d0bf8074035d8acc3e/windows/cloud-provider.psm1#L20), and therefore fails with the following error message:
INFO: Waiting for servcie-sidekick to prepare the entrypoint.ps1 ...
ERROR: The cloud 'AzureUSGovernmentCloud' is not registered.
FATA: Failed to set 'AzureUSGovernmentCloud' as cloud type:
INFO: Waiting for servcie-sidekick to prepare the entrypoint.ps1 ...
ERROR: The cloud 'AzureUSGovernmentCloud' is not registered.
FATA: Failed to set 'AzureUSGovernmentCloud' as cloud type:
INFO: Waiting for servcie-sidekick to prepare the entrypoint.ps1 ...

Result:
This error loops and prevents the Windows node from joining.
Environment information

Rancher version: v2.3.3
RKE version: local v1.0.0
k8s version: local v1.16.3 ; cluster v1.15.7
HA is enabled

per convo with ross/hussein we might be able to solve this with existing config

Available with v2.3.6-rc7.

Per the customer, this is working now.


Clean up unit types for mass/ distance/ area/ volume.

Modify the schema definition to use more common designations - also fix a typo for liter.
i.e.

This issue is addressed by PR #400 referenced above.


Method level reader extensions

It should be possible to enrich swagger model by vendor based extensions stored on operation level. To do that we need to add extension point when operation is processed and method context exists. This allow to process e.g. some vendor annotation which are stored on method level and could be used by documentation.

Not entirely sure what's your end goal here, but you should definitely add a test for it (which would also explain your case).

I added example as you asked. In short lets assume that come company created set of annotation which could be used on method level e.g. "@VendorFunnyAnnotation". If it is used this indicates that that method could return some error code and we would like to add that error code to swagger documentation.

@frantuma can you review this please?

@webron @kendzi
It looks good to me, but it needs to be rebased and to have SimpleResourceWithVendorAnnotation annotated with @Path("/") at class level to allow it to be scanned during test.

done

@webron @frantuma anything else should I rebase of fix?

Upvote this pull request! It really simplifies unobtrusive tuning of documentation generation process.
Are there any reasons why not to merge?

+1

I re-base it once again. Please merge it.

@webron @frantuma guys, are there any reasons why this PR can not be merged?

Time 😕
@frantuma since you reviewed it in the past, feel free to merge if you feel confident about it.


help zod validation before

hi @iendeavor what is the best way to check the data with zod parse before persist?

IMO, the states itself should be valid during entire application lifecycle, hence we should validate new states before (i.e., initialization, in actions, during hydration) assign it to store.
So we don't need to validate it during persistent.

For example, LocalStorage changed by user manually String, and we set String, but expect Number. for this better use merge method?

What kind of your app is? Why users would manually change LocalStorage?

two apps on one page with the same local storage, and the user change state from another app


Delete Command for Doctor

After discussion, it was decided to make the "Doctor" field compulsory so this command is unnecessary.


Cannot install spl-stake-pool-cli v0.4.0

Attempted to install spl-stake-pool-cli v0.4.0, but there was a problem with dependencies.
$ cargo install spl-stake-pool-cli
    Updating crates.io index
  Installing spl-stake-pool-cli v0.4.0
error: failed to compile `spl-stake-pool-cli v0.4.0`, intermediate artifacts can be found at `/tmp/cargo-installDKBxXV`

Caused by:
  failed to select a version for the requirement `crypto-mac = "^0.7"`
  candidate versions found which didn't match: 0.11.1, 0.11.0, 0.10.1, ...
  location searched: crates.io index
  required by package `hmac v0.7.0`
      ... which is depended on by `hmac-drbg v0.2.0`
      ... which is depended on by `libsecp256k1 v0.3.5`
      ... which is depended on by `solana-sdk v1.7.4`
      ... which is depended on by `solana-account-decoder v1.7.4`
      ... which is depended on by `solana-client v1.7.4`
      ... which is depended on by `spl-stake-pool-cli v0.4.0`

In fact, v0.3.0 does not install either.
$ cargo install spl-stake-pool-cli --version 0.3.0
  Downloaded spl-stake-pool-cli v0.3.0
  Downloaded 1 crate (35.2 KB) in 1.89s
    Updating crates.io index
  Installing spl-stake-pool-cli v0.3.0
error: failed to compile `spl-stake-pool-cli v0.3.0`, intermediate artifacts can be found at `/tmp/cargo-installhZR5ue`

Caused by:
  failed to select a version for the requirement `crypto-mac = "^0.7"`
  candidate versions found which didn't match: 0.11.1, 0.11.0, 0.10.1, ...
  location searched: crates.io index
  required by package `hmac v0.7.0`
      ... which is depended on by `hmac-drbg v0.2.0`
      ... which is depended on by `libsecp256k1 v0.3.5`
      ... which is depended on by `solana-sdk v1.7.3`
      ... which is depended on by `solana-account-decoder v1.7.3`
      ... which is depended on by `solana-client v1.7.3`
      ... which is depended on by `spl-stake-pool-cli v0.3.0`

Only v0.2.0 installs properly.

Same issue here. any solution?

Same issue here. any solution?

Yes. https://github.com/vkomenda/solana-program-library/tree/stake-pool-v0.4.0-compile-fix

One of the dependent packages got yanked unfortunately, which has broken some of our old packages, bubbling up to this one.  I will be deploying version 0.5 of these crates within the coming week with the new program.
In the meantime, please feel free to use @vkomenda 's fix locally to build them yourself! Thanks for the contribution

Version 0.5 is now published, so you can do cargo install spl-stake-pool-cli to have the package once again.  Note that this operates on a new deployment of the program, so an old pool from version 0.4 will not be visible.

Closing, let me know if you have any other questions


windows closed by commands such as <c-w>c

The undoclosewin.vim plugin also restores windows closed by commands such as <c-w>c or ZZ. Is it outside of the scope of undo_quit_.vim or is it impossible to implement this reliably ?
If not, how about allowing undoquit to undo closes of windows by such commands as well (perhaps by taking a look at undoclosewin.vim's implementation) ?

From what I see, undoclosewin uses a different method. I'll see what I can do.

Hmm, undoclosewin seems to work in a more complicated way than I expected. It listens to the BufWinLeave event, but that one gets fired even when you're editing a new buffer in the same window :/. I guess this is why the internals of the plugin do some duplicate checks, although I'm not so sure how reliable they end up being...
Either way, this would be pretty complicated to support, so I think I won't implement it. In my experiments, ZZ works fine, it's only <c-w>c that doesn't throw a QuitPre autocommand. One way to get this working for you would be to remap <c-w>c:
nnoremap <c-w>c :call undoquit#SaveWindowQuitHistory()<cr><c-w>c

This seems to work for me, but I wouldn't put it in the plugin, since I don'w want to override someone's mappings. Maybe I'll write it down as a tip in the documentation.


BigInteger: Replace ==ZERO by isZero.

Replacing == ZERO by isZero()
Motivation
Similar of #301 but for BigInteger. Equals are more costly than testing isZero or isNegative.
Special case
BigInteger.pow(BigInteger) uses exponentiationBySquaring which is now using isZero, but I was not able to reach this code path in my tests.
JVM was triggering an OutOfMemory (Java heap space) after 90s of running (my exponent was BigInteger.parse(Long.MAX_VALUE + "1")).
I took a shortcut by commenting the call to pow(Long), so that it forces the use of exponentiationBySquaring, and allow me to benchmark with "little" values (1 googol being "little").
Benchmark (JVM)
Best of 3 runs, custom iterations (see benchmark code), JVM, M3 Pro with 36GB RAM, duration in seconds

Method
BEFORE
AFTER
% time reduction

subtract
1.13
1.08
4%

ZERO.subtract()
0.581
0.502
14%

subtract(ZERO)
0.683
0.330
52%

pow* (exp by squaring)
1.10
1.08
2%

modInverse
0.586
0.577
2%

times(Char)
2.27
2.16
5%

pow
0.081
0.070
14%

Benchmark code
    @Test
    fun perfSubtractZero() {
        val bd = BigInteger.parseString("123")
        val duration = measureTime {
            repeat(100_000_000) { bd - BigInteger.ZERO }
        }
        println("subtract(ZERO): $duration")
    }

    @Test
    fun perfZeroSubtract() {
        val bd = BigInteger.parseString("123")
        val duration = measureTime {
            repeat(100_000_000) { BigInteger.ZERO - bd }
        }
        println("ZERO.subtract(): $duration")
    }

    @Test
    fun perfSubtract() {
        val a = BigInteger.parseString("123")
        val b = BigInteger.parseString("34")
        val duration = measureTime {
            repeat(100_000_000) { a - b }
        }
        println("subtract: $duration")
    }

    @Test
    fun perfPowWithExponentiationBySquaring() {
        // Warning, this test has biased value, it should use an exponent > Long.MAX_VALUE to go
        // through exponentiationBySquaring. For benchmarking this test I've commented out the usage of pow(Long)
        val a = BigInteger.parseString("10")
        val b = BigInteger.parseString("100")
        val duration = measureTime {
            repeat(1_000_000) { a.pow(b) }
        }
        println("pow*: $duration")
    }

    @Test
    fun perfPow() {
        // Warning, this test has biased value, it should use an exponent > Long.MAX_VALUE to go
        // through exponentiationBySquaring. For benchmarking this test I've commented out the usage of pow(Long)
        val a = BigInteger.parseString("10")
        val b = BigInteger.parseString("100")
        val duration = measureTime {
            repeat(1_000_000) { a.pow(b) }
        }
        println("pow: $duration")
    }

    @Test
    fun perfModInverse() {
        // 3803 and 3329 are both primes
        val a = BigInteger.parseString("3803")
        val b = BigInteger.parseString("3329")
        val duration = measureTime {
            repeat(1_000_000) { a.modInverse(b) }
        }
        println("modInverse: $duration")
    }

    @Test
    fun perfTimes() {
        val a = BigInteger.parseString("38")
        val duration = measureTime {
            repeat(1_000_000) { a.times('b') }
        }
        println("times(Char): $duration")
    }

Raw data
Before
Run 1
subtract: 1.526356041s
ZERO.subtract(): 581.206625ms
pow: 1.199554083s
subtract(ZERO): 682.647833ms
modInverse: 586.281166ms
times(Char): 2.274098500s
pow: 89.229875ms
Run 2
subtract: 1.380918708s
ZERO.subtract(): 621.464125ms
pow: 1.098721042s
subtract(ZERO): 693.304667ms
modInverse: 608.127292ms
times(Char): 2.287946833s
pow: 83.628250ms
Run 3
subtract: 1.133838833s
ZERO.subtract(): 645.497916ms
pow: 1.234771250s
subtract(ZERO): 687.548750ms
modInverse: 649.144083ms
times(Char): 2.287897334s
pow: 80.517ms
After
Run 1
subtract: 1.078803625s
ZERO.subtract(): 536.864958ms
pow: 1.128199250s
subtract(ZERO): 329.929625ms
modInverse: 611.962750ms
times(Char): 2.214370791s
pow: 79.141750ms
Run 2
subtract: 1.137907458s
ZERO.subtract(): 525.679166ms
pow: 1.083095208s
subtract(ZERO): 544.093ms
modInverse: 599.358250ms
times(Char): 2.156597666s
pow: 86.663125ms
Run 3
subtract: 1.449096584s
ZERO.subtract(): 502.667083ms
pow: 1.076523292s
subtract(ZERO): 393.253875ms
modInverse: 574.755417ms
times(Char): 2.203168959s
pow: 69.521125ms

Hi @glureau thank you for all the pull requests, they are highly appreciated. I won't have time/access to the repo next couple of weeks, so I'll look into the requests once I get back. Thanks once again!

Thank you for all your work! Great library and nice to have such a good support and response time for an open source project. Enjoy your days off!
PS: I've published a 0.3.10-SNAPSHOT2 on my fork https://github.com/users/glureau/packages?repo_name=kotlin-multiplatform-bignum for my own needs with all the improvements if anyone else is interested to test it, but I recommend to wait a bit more if you can ;)


test(jest): convert codebase to jest and remove karma + jasmine

test(jest): convert the codebase to jest and remove karma + jasmine
Proposed Changes
Removed karma and jasmine in favor of jest.
Potential Breaking Changes
All import React from 'react'; were converted to import * as React from 'react';.
Acceptance Criteria

[ ] The proposed changes are covered by unit tests
[ ] The potential breaking changes are clearly identified
[ ] README.md is adjusted to reflect the proposed changes (if relevant)

@j-mcgregor From a configuration standpoint, what helped the most was removing the babel stuff as it was conflicting with ts-jest and also using the custom identity-object-proxy code that works for esm modules. The last one made all the tests that were relying on scss imports work without any modification to the actual tests.
What helped the most about fixing the failing tests have been to mock react with jest.mock instead of jest.spyOn. SpyOn wasn't actually working for a reason that I cannot comprehend. We ended up spying on the react object that wasn't the one used at run time by the source code.


Consider to support more strconv functions

Hi!
Maybe you will be interested in:

https://pkg.go.dev/strconv#FormatComplex
https://pkg.go.dev/strconv#FormatFloat
https://pkg.go.dev/strconv#Unquote
https://pkg.go.dev/strconv#Quote (and other Quote*)

As mentioned in #2 this linter is more about fmt.Sprint than strconv
Where do you see strconv.Quote or strconv.Unquote being faster than some current code ?
FormatComplex and FormatFloat looked more powerful functions with their precision argument than something optimized to be fast.
Do you have examples ?

Do you have examples ?

fmt.Sprintf(`"%s"`, "hello")
fmt.Sprintf("%q", "hello")
strconv.Quote("hello")
`"` + "hello" + `"`

fmt.Sprintf("`%s`", "hello")
fmt.Sprintf("%#q", "hello")
"`" + "hello" + "`"

fmt.Sprintf("%q", 91)
"'['"

strings.Trim(`"hello"`, `"`)``
strconv.Unquote(`"hello"`)

fmt.Sprintf("%f", 42.42) // And a lot of other verbs.
strconv.FormatFloat(42.42, 'f', 6, 64)

fmt.Println(fmt.Sprintf("%e", 42i+42)) // And other verbs.
fmt.Println(strconv.FormatComplex(42i+42, 'e', 6, 64))

Not all are equivalent cf https://go.dev/play/p/9s4GhmIBEz_J
What I see in some codebase is fmt.Sprintf("constantstring%s" like 0x%x

What about https://github.com/catenacyber/perfsprint/commit/ea8b325cd6f75097103b8c9c9f99902743aea94f ?

Please, make a PR in the next time :)
It is more suitable for review

Offtopic:
the latest version (v0.2.2) contains features but the version was increased as a bug fix.
It's better for us if you follow semver:

breaking changes -> major (vX.y.y)
new features -> minor (vy.X.y)
bug fixes -> patch (vy.y.X)

Yes, sorry for the confusion, I suggested a patch version because I didn't consider the flag as a new feature (with a default value equal to the existing behavior). I didn't know about other changes.

@catenacyber about https://github.com/catenacyber/perfsprint/commit/ea8b325cd6f75097103b8c9c9f99902743aea94f

I left some comments
It looks like thing that is not related to your linter

The change is questionable, because sometimes people use fmt.Errorf in any case for consistency. But set of linters checks is not configurable.
Usually error path is not performance bottleneck, because it happens much less often.

Also we already have the similar checks:

https://staticcheck.dev/docs/checks/#S1028
https://go-critic.com/overview.html#dynamicfmtstring (propose to add "%s" oO)
https://github.com/mgechev/revive/blob/master/RULES_DESCRIPTIONS.md#errorf
https://github.com/Djarvur/go-err113#reports (do not define dynamic errors, use wrapped static errors instead)

And this is another one reason for pull requests instead of commits.
Anyway, as u wish.

The change is questionable, because sometimes people use fmt.Errorf in any case for consistency. But set of linters checks is not configurable.

Ok, adding an option to configure this

Usually error path is not performance bottleneck, because it happens much less often.

Indeed, and I hope fmt.Sprintf("%d" is neither a performance bottleneck. But 0.5% CPU improvement is always good to take

https://staticcheck.dev/docs/checks/#S1028
https://github.com/mgechev/revive/blob/master/RULES_DESCRIPTIONS.md#errorf

Eheh, perfsprint will optimize the fmt.Sprintf inside errors.New first

https://go-critic.com/overview.html#dynamicfmtstring

Interesting

https://github.com/Djarvur/go-err113#reports

Looks a different class

And this is another one reason for pull requests instead of commits.

I have been doing that since

Is there something clear to do her e?

Thanks for feedback and related changes 🙏