Adding a more useful ChangeLog

For the last year or two I've been keeping a Vim ChangeLog of sorts at https://www.arp242.net/vimlog, which lists the most prominent and useful user-visible changes.
I think it would be useful to add this to Vim; now it's just this website that few people visit or know about aside from the odd occasion where I mention it somewhere – that's okay, because like I said, I update it for my own reasons. But I think it would be useful for others too.
The question is where and how; the easiest is just a link somewhere, but that's likely easily missed; a new :help changelog.txt seems to make the most sense to me, i.e. something like:
2021           *changelog-2021*
----

Add list to 'breakindentopt'                         8.2.3160, 8.2.3198 (Jul 22)
    Add additional indent for lines that match a numbered or
    bulleted list (using the 'formatlistpat' setting).

Add |setdigraph()|, |setdigraphlist()|, |getdigraph()|               8.2.3184 (Feb 15)
    |getdigraphlist()|
    List and define digraphs from functions.

[..]

2020           *changelog-2020*
----

[..]

Which looks like:

This could also be added to the startup screen maybe.
The website is generated with a Python script from a list; see the source; adding some new format like a plain-text output isn't too much work, I can just do that. After that it can either be updated manually or from the script.

Some background and motivation for doing this in the first place:
I mostly maintain this for my own purposes, as there are often small (and sometimes not-so-small) enhancements to Vim. For example I never would have known about the addition of list to breakindentopt until I hear it through the Vim grapevine on some chat or whatnot, or until Vim 9 is released with a fully updated changelog. This would be a shame as it's quite a useful option. A lot of people are probably missing out on features their Vim supports simple because they don't know about them; set spelloptions=camel, g<Tab>, the built-in fuzzy matching, set nrformats+=unsigned, and a bunch of others.
There's :help version.txt etc, but it's not really up-to-date for 8.2; a fixable problem for sure, but grouping things by v8.2, v8.1, etc actually isn't all that useful; 8.2.0000 is from December 2019 – a wonderful glorious time in the distant past when we could travel freely and go to pubs whenever we wanted.
Few people – if anyone – upgrade from 8.1.0000 to 8.2.0000, they update from 8.2.[..] to 8.2.[..]. For example going from Debian 10 to Debian 11 means going from Vim 8.1.0875 to Vim 8.2.2434; which useful changes does this have for me as a user? Not so easy to find that out from :help version8.txt as it's not sorted by date; I need to manually diff it against a previous version, or something, to actually know what new stuff and changes I have (and hope it's complete).
Distros like Arch or Void generally include something reasonably close to the latest master; the latest update for Void went from 8.2.2513 to 8.2.2874; not easy to find out what that gives me either.
Getting this from git log isn't very easy; just git log is very verbose; I generally update this by doing a git log runtime/doc, reasoning that user-visible changes come with documentation updates, although you need to filter quite a few things from this as well, and git diffs also isn't really the most user-friendly UI.
It doesn't list absolutely everything, just what's useful for (most) users.. It also groups things if the patches are reasonably close: for example the fillchars had several changes in a two-week period several months ago: that's listed as just one entry. In short, it's a good quick overview that adds a lot of value for "normal" users not tracking Vim development.

Martin Tournoij wrote:

For the last year or two I've been keeping a Vim ChangeLog of sorts at
https://www.arp242.net/vimlog, which lists the most prominent and
useful user-visible changes.
I think it would be useful to add this to Vim; now it's just this
website that few people visit or know about aside from the odd
occasion where I mention it somewhere – that's okay, because like I
said, I update it for my own reasons. But I think it would be useful
for others too.

This can be interesting for users.  Including it with Vim means it would
quickly get outdated, I think it's fine to point to the website.  Since
it starts with Vim 8.0 adding it just above "help new-8" seems like a
good place.
--
hundred-and-one symptoms of being an internet addict:
225. You sign up for free subscriptions for all the computer magazines
/// Bram Moolenaar --<EMAIL_ADDRESS>-- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Including it with Vim means it would quickly get outdated

To be clear: I wouldn't have suggested this if I wasn't also prepared to update it for the foreseeable future. I do this now anyway.
But yeah, just adding a link is also good – whatever you're most comfterable with. Could possible also move the repo to vim/changelog or some such and update it from there(?) That would give that advantage that you, Christian, etc. could also easily update it if need be.

Ah, yes I remember your webpage, nice work.
We used to have a section on vim.org that included the latest patches. I wonder if we could show the content from your webpage there?

I suppose this can be closed now, it is mentioned in the help with the recent runtime update https://github.com/vim/vim/commit/53f7fccc9413c9f770694b56f40f242d383b2d5f

Cheers, thanks


Migrate serving operator to use knative.dev/serving-operator import path

I have broken this into two commits:

The manual changes I made.
The scripted changes I made.

Ran sed -i 's@github.com/knative/serving-operator@knative.dev/serving-operator@g' $(find -name '*.go' | xargs grep github.com/knative/serving-operator | cut -d':' -f 1 | uniq)
Related to https://github.com/knative/pkg/pull/489 and https://github.com/knative/serving/pull/4521

/assign mattmoor

/lgtm
/assign @chaodaiG
Needs to be coordinated with Prow changes.

@trshafer
I have one question regarding the import change: if we add a new package github.com/knativeserving-operator/pkg/reconciler/knativeserving into the source code, are we able to use knative.dev/serving-operator/pkg/reconciler/knativeserving directly in the PR?

@houshengbo yes I believe all of the imports for serving-operator will be knative.dev/serving-operator prefixed.

/lgtm

/retest

/retest

/test pull-knative-serving-operator-integration-tests

/retest


bundle fira mono subset font

had to create a new subset in fontforge, bevy's included font wouldn't load for whatever reason. probably one of the millions of TTF settings I don't understand :P
fixes #25

Niiiice 👍


Support for GPU based codebuild container

We aim to launch a GPU-based pipeline on CodeBuild, however, to do so, we require a GPU-based node. Currently, the CodeBuild Jenkins plugin only supports LINUX_CONTAINERS. We would appreciate assistance in launching a GPU-based CodeBuild project using the CodeBuild Jenkins plugin.

This plugin supports overriding the environment type with all currently supported types, though some of the documentation that the plugin provides is out of date and only mentions Linux and Windows. You should also be able to trigger builds for an existing CodeBuild project that uses the GPU environment type. What specific error are you running into?

@shankarhpatel - As @leoherran-aws mentioned, you should be able to use any compute type that is available in CodeBuild. Resolving.


Feat/sma 809 potential account factory (Draft)

couple of things may be reverted from this change. first, here is the list of changes below and then I would dive into discussion and link the PR for further experimental changes.
1. Stakeable
Added common/Stakeable contract (which is Ownable) that can be inherited by the factory [ Or any entity which needs a stake on the entry point for that matter ]
2. AccountFactory minor changes
base StakeManager was wrong.
now Factory inherits from Stakeable which makes it also Owned. Using this owner we could further add access controlled actions like whitelisting one or more modules, Or setting ERC7484 registry which checks on module being installed
also it felt right to rename getCounterFactualAddress -> computeAccountAddress :))
3.small) Took a snapshot of current AccountFactory in case we start editing this one in current branch
that would mean altering createAccount method from
function createAccount(address validationModule, bytes calldata moduleInstallData, uint256 index)
to something
which can
i. accept generic initData to be directly posted on the account (account.call(initData)) / initData to call specific method on the account INexus.initializeAccount(initData)
ii. accepts array of modules and setup datas, or packed data and factory knows how to decode those and check agaisnt some whitelist.
4.  BiconomyMetaFactory. inspired from kernel's factory staker
Stakeable Ownable Factory, idea is to use this as meta factory and it's address will be part of the initcode and under the hood you can use any approved (only approved ones) factory using deployUsingFactory() method.
clear benefit is you can gatekeep factories
if the approved/whitelisted factory has generic call data then issue reported by holterhaus still remains. perhaps these factories can have initial validator/few modules enshrined or whitelisted
in the future you can just add a new factory under the hood and start using it.
con might be added gas but that comes with any kind of whitelisting anywhere or when addressing security concerns.
5. Bootstrap.sol
singleton bootstrap contract inspired from ERC7579 reference implementation
this contract has util methods to prepare the module installation calldata
it would work like this in Nexus initialisation
function initializeAccount(bytes calldata initData) external payable virtual {
        // checks if already initialized and reverts before setting the state to initialized
        _initModuleManager();

        // this is just implemented for demonstration purposes. You can use any other initialization
        // logic here.
        (address bootstrap, bytes memory bootstrapCall) = abi.decode(initData, (address, bytes));
        (bool success,) = bootstrap.delegatecall(bootstrapCall);
        if (!success) revert();
 }

using Bootstrap util contract one can make bootstrap config using array of modules to be installed upon.
implementation is not altered in this branch to use this bootstrap contract
but experimental changes are here with evolved Bootstrap contract
https://github.com/bcnmy/nexus/blob/test/showcase-alterations-using-bootstrap/contracts/utils/Bootstrap.sol#L82
P.S - This does not help resolve Holterhaus reported issue but only to allow installing multiple modules. If we go with this approach I haven't thought about how to decode bootstrap config and make checks for individual module addresses or payloads.

also linking this here
https://github.com/bcnmy/nexus/pull/74

I agree to all the proposed changes.
Ownable can help us managing stuff that will allow to mitigate HolterHus issue
having generic bytes data can also be useful. enabling several modules would be really useful
Question re MetaFactory

it's address will be part of the initcode
can you elaborate on this please?

I agree to all the proposed changes. Ownable can help us managing stuff that will allow to mitigate HolterHus issue having generic bytes data can also be useful. enabling several modules would be really useful
Question re MetaFactory

it's address will be part of the initcode
can you elaborate on this please?

I made several functions in bootstrap contract for packing things to generic data
one is broad where you can enable n validators, n executors, hook and n fallbacks
I'm trying to think what would be used more often during deployment and what would be done post deployment by choice and less frequently.
so then I thought maybe n validators and 1 hook is enough? preparing data for this scoped init. wdyt?

address will be part of the initcode
oh i mean this will be the actual factory recognised by initcode userop
initcode = address(meta factory) + selector(deployWithFactory)initData

but doing this both is possible to solve Holterhaus reported issue?
If I make generic data can you show how we would decode and check whitelist?

i mean this will be the actual factory recognised by initcode userop

I see. yeah, this is interesting. so this metafactory will be cosidered a factory by 4337. so it has to be staked.

but doing this both is possible to solve Holterhaus reported issue? If I make generic data can you show how we would decode and check whitelist?

Can we move decoding and checking the wl/attestations to the factories that actually deploy the sa?

yes, it is stakeable. child factories can be just ownable

yes > decoding and checking the wl/attestations to the factories that actually deploy the sa

on this we have to decide which all kinds of factories we need,
a. one with K1 valdiator enshrined?
b. one with x modules just whitelisted. we will need to send large amount of data and decoding logic for these modules.
c. one with registry check on all modules
have to decide on wl vs registry
on previous call w rhinestone attestation flow is not super clear to me so I would refrain from that right away.
wdyt?
what makes clear sense is meta factory and freedom to intro more factories and whitelist / enshrine / guard trail stuff inside them.
as long as format is clear say createAccount(bytes calldata initData, bytes32 salt)
and inside you're calling account.call(initData) vs perhaps account.initialise(initData) / account.initialise(_validators, _executors, _hook, _fallbacks)
it would increase gas ofc but have to be reasonable in choices a bit.

wdyt?

I think, with this meta factory concept, we can start with k1-factory and whitelist-factory. And wait until module registry flow is clearer.

wdyt?

I think, with this meta factory concept, we can start with k1-factory and whitelist-factory. And wait until module registry flow is clearer.

cool sounds good.
I will start making some changes

wdyt?

I think, with this meta factory concept, we can start with k1-factory and whitelist-factory. And wait until module registry flow is clearer.

in this case should I keep methods for all factories same createAccount(_data, _salt) or doing something like factory.call(packedwithfunctionselector) in meta factory?

Got some thoughts on the recent PR. I think we can simplify things and make it more efficient

Move the init logic into the NexusAccount directly this way we can get rid of Bootstrap.sol and BootstrapUtil.sol
enshrine whitelist of modules in the factory itself or maybe in the Meta (I'm not sure where will it be used here yet as it's used nowhere for the moment)
simplifying the initData structure by encoding everything within the NexusAccount reduces the need for decoding and number of  external calls

this will reduce gas with less external calls, simplify initData structure and reduce the number of contracts (files)
User
 |
 | Initiates account creation
 v
+----------------------+
| NexusMetaFactory     |
| - Verify Factory     |
+----------------------+
           |
           | deployWithFactory(factory, factoryData)
           v
+----------------------+
| Specific Factory     |
| - Verify Modules     |
| - Initialize Account |
+----------------------+
           |
           | createAccount(initData, salt)
           v
+----------------------+
| NexusAccount         |
| - Initialize Modules |
| - Configure Account  |
+----------------------+
           |
           | Initialization Complete
           v
         Account Created

Lmk what your thoughts

There are some review comments I am keeping and leaving a note here.
NexusAccountFactory
// Review may not need stakeable here
ModuleWhitelistFactory
// Review if we should verify calldata[0:4] against the function selector of initNexus
K1ValidatorFactory
// Review: if salt should include K1 Validator address as well


Render preview card without changing document

I love the idea of these Notion-style link preview cards. It looks really good.
But I would rather they are rendered without having to hard-code information into the note file.
Is it possible to leave only the URL in place and just call the URL, it information and render the card upon loading the note/adding a URL?
To stop this happening for every link, maybe it's possible to include a simple attribute within link mark-up?

Storing metadata like descriptions was the main reason why I started this project, so that I could search with more related keywords later. So yes, that is possible, but I'm probably not going to implement that. But you are welcome to make a pull request about this. You can add an option to toggle this feature.


Cannot build UWP x64 or ARM.

error MSB3270: There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference "C:\Users\John.nuget\packages\octane.xam.videoplayer\2.1.0\lib\UAP10\Octane.Xamarin.Forms.VideoPlayer.UWP.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
error MSB3270: There was a mismatch between the processor architecture of the project being built "ARM" and the processor architecture of the reference "C:\Users\John.nuget\packages\octane.xam.videoplayer\2.1.0\lib\UAP10\Octane.Xamarin.Forms.VideoPlayer.UWP.dll", "x86". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
x86 builds fine.

Mmmmh. A general rule of thumb I follow is EXE targets the OS, by specifying x86 or x64 and DLLs are left open (i.e., AnyCPU) so they can be instantiated within a 32-bit or a 64-bit process. The UWP version of the video player targets AnyCPU. I verified I am able to build the UWP Chill Player app and run it with the current version of the video player.
Kind of sounds like a local configuration issue. Have you tried setting your UWP project to target AnyCPU? Does this forum recommendation below help at all?
https://forums.xamarin.com/discussion/25538/xamarin-xaml-example-problem-using-pcl


WW3 fails to compile on M1/gnu with "sed invalid command L"

On Apple Silicon M1 with gcc/mpich toolchain, the build.sh script fails when WW3 is included:
	exec /Applications/Xcode.app/Contents/Developer/usr/bin/make -j 1 WW3_COMP="gnu" COMP_BINDIR="/Users/Lemmen/devel/noaa/CoastalApp/WW3_INSTALL" ww3_nems
No module selected.
+ cd /Users/Lemmen/devel/noaa/CoastalApp/WW3/model/esmf
+ export COMP_SRCDIR=/Users/Lemmen/devel/noaa/CoastalApp/WW3/model COMP_BINDIR=/Users/Lemmen/devel/noaa/CoastalApp/WW3_INSTALL WW3_COMP=gnu
+ COMP_SRCDIR=/Users/Lemmen/devel/noaa/CoastalApp/WW3/model
+ COMP_BINDIR=/Users/Lemmen/devel/noaa/CoastalApp/WW3_INSTALL
+ WW3_COMP=gnu
+ exec /Applications/Xcode.app/Contents/Developer/usr/bin/make -j 1 WW3_COMP=gnu COMP_BINDIR=/Users/Lemmen/devel/noaa/CoastalApp/WW3_INSTALL ww3_nems

                *****************************
              ***   WAVEWATCH III setup     ***
                *****************************

[INFO] local env file wwatch3.env found in /Users/Lemmen/devel/noaa/CoastalApp/WW3/model/bin/wwatch3.env
sed: 1: "/Users/Lemmen/devel/noa ...": invalid command code L
make[1]: *** [setup] Error 1
make: *** [/Users/Lemmen/devel/noaa/CoastalApp/WW3_INSTALL/nuopc.mk] Error 2

@Takis:
Carsten and I are pulling the latest CoastalApp (develop branch) but WW3 cannot be checked out automatically.
Carsten also tried with a version of WW3 he downloaded  but the build failed with errors related to METIS and PARMETIS.
Can u plz check to see if you can build successfully?
Thx.


FIX ISSUE - Fix the issue of the containers on the main page

Greetings !!
i would like to fix this issue of the containers as the price of the items are coming outside the box and it ofcourse doesnt look nice .
Also i would like to add some more css properties to this containers to enhance the website's UI.

hey @codervivek5 I would like to work on this issue and improve it. Can you please assign this to me?

hey @codervivek5 I would like to work on this issue and improve it. Can you please assign this to me?

@TAnisha016  You need to create your own pull request with your innovative ideas on how you can develop or modify or enhance the website .I hope you understand :) .
Thanks

Yes I completely understand, I'm a beginner so I was confused previously
but now I know that I need find the ideas myself then offer it. Thank you
for contacting.
On Mon., 3 Jun. 2024, 7:21 pm Abhay ;), @.***> wrote:

hey @codervivek5 https://github.com/codervivek5 I would like to work on
this issue and improve it. Can you please assign this to me?
@TAnisha016 https://github.com/TAnisha016 You need to create your own
pull request with your innovative ideas on how you can develop or modify or
enhance the website .I hope you understand :) .
Thanks
—
Reply to this email directly, view it on GitHub
https://github.com/codervivek5/VigyBag/issues/1269#issuecomment-2145258598,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BCRRPCGXNY76H4VODH2OH5LZFRYEJAVCNFSM6AAAAABIU4LHNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBVGI2TQNJZHA
.
You are receiving this because you were mentioned.Message ID:
@.***>


[SuggestionProvider] Highlight locally executed actions when remote execution is used

Add a SuggestionProvider which, if remote execution is used, highlights which actions were run locally and suggests migrating them to remote execution, too. In default mode, the four longest local actions are listed.
Fixes #95.

Example output:
Suggestion: "Migrate locally executed actions to remote execution"
Although remote execution was used for this invocation, some actions were still executed locally. Investigate whether you can migrate these actions to remote execution to speed up future builds and improve hermeticity:
	- Executing genrule //src:target_b (23ms)


Cleanup last references to dockerhub

All remaining usages are in on-demand built images.
I also removed a dead Dockerfile that is unused
[ ] Configuration Infrastructure
[ ] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure
Pull Request Attributes
Please check any characteristics that apply to this pull request.
[ ] Does not have any changes that may affect Istio users.

@howardjohn: The following test failed, say /retest to rerun all failed tests:

Test name
Commit
Details
Rerun command

unit-tests_istio
bd50fdee1c31bde7345747f0d9a2f2eca8e337db
link
/test unit-tests_istio

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.

/retest


Cdk Overlay backdrop does not respect noopanimations

Reproduction
Use StackBlitz to reproduce your issue: https://stackblitz.com/fork/components-issue
Steps to reproduce:

import NoopAnimationsModule
Create a dialog
https://stackblitz.com/edit/angular-fdgmah (based on example dialog stackblitz)

Expected Behavior
What behavior were you expecting to see?
The dark overlay appears immediately with no animation
Actual Behavior
What behavior did you actually see?
The overlay backdrop fades in over 400ms.
Environment

Angular: 9.1
CDK/Material: 9.1
Browser(s): Chrome
Operating System (e.g. Windows, macOS, Ubuntu): Linux

Looks related to #10145


Closes: #1 issue

Updated validations.py python script.
Fixed the behavior of validate_user function in validations.py.
Fixes #<issue_number_goes_here>

It's a good idea to open an issue first for discussion.

[ ] Tests pass
[ ] Appropriate changes to README are included in PR

@googlebot I signed it!


[BUG] Vial of Arcane Extraction

Vial of arcane Extraction not working.
Version: Apotheosis-1.20.1-7.0.5, playing ATM9
Vial of arcane extraction does not extract anything in the smithing table

This one is driving me crazy I just wanna unsocket my gems


issue resolved

Sorry for making such a mess here. I am completely new to github.

SO my issue was not resolved after all. My new blueprint appears in game but it only lists the GutDried as a requirement but neglects the WolfPeltDried.
    "RequiredGear": ["GEAR_WolfPeltDried"],     "RequiredGearUnits": [2],      "RequiredGear": ["GEAR_GutDried"],     "RequiredGearUnits": [2],     "KeroseneLitersRequired": 0,     "RequiredTool": "GEAR_SewingKit",     "OptionalTools": ["GEAR_HookAndLine"],     "RequiresForge": false,     "RequiresWorkbench": true,     "RequiresLight": true,     "CraftedResult": "GEAR_craftable_hat_01",     "CraftedResultCount": 1,     "DurationMinutes": 180,     "CraftingAudio": "PLAY_ClothingRepair"
How do I have to adjust the code to make it work?

The correct definition should be
{
	"RequiredGear": ["GEAR_WolfPeltDried", "GEAR_GutDried"],
	"RequiredGearUnits": [2, 2],
	"KeroseneLitersRequired": 0,
	"RequiredTool": "GEAR_SewingKit",
	"OptionalTools": ["GEAR_HookAndLine"],
	"RequiresForge": false,
	"RequiresWorkbench": true,
	"RequiresLight": true,
	"CraftedResult": "GEAR_craftable_hat_01",
	"CraftedResultCount": 1,
	"DurationMinutes": 180,
	"CraftingAudio": "PLAY_ClothingRepair"
}

Values in [ ] are arrays, meaning they can contain more than one value.
So for RequiredGear, RequiredGearUnits and OptionalTools you just list all the things you want within the brackets.
If it's only one item you still need the brackets, because it is expected to be an array.

Excellent, thank you for your help and patience!


Added VSCode

Added a new section of Using VSCode, and a detailed guide on Remote-Tunnels in VSCode

Hi @aroepe ,
I added a new section of Using VSCode and a detailed guide on "Remote-Tunnels" in VSCode. Please help review and approve.
Thanks,


Create .travis.yml

The owner of the this repo would need to go to https://travis-ci.org/profile, log in with GitHub credentials, select the free plan, and flip the repository switch on to enable free automated testing of all pull requests.  Travis will lint with flake8 and then run python test.py.
Add flake8 tests to find Python syntax errors and undefined names.
E901,E999,F821,F822,F823 are the "showstopper" flake8 issues that can halt the runtime with a SyntaxError, NameError, etc. Most other flake8 issues are merely "style violations" -- useful for readability but they do not effect runtime safety.

F821: undefined name name
F822: undefined name name in __all__
F823: local variable name referenced before assignment
E901: SyntaxError or IndentationError
E999: SyntaxError -- failed to compile a file into an Abstract Syntax Tree

You will need to go to https://travis-ci.org/dataplayer12/shavenet and under "More options" at the upper right and manually kick off the first build.  After that, it will become automatic.


Allow to pass n arguments to the sx prop and remove falsy styles to enable easy conditional styles

Is your feature request related to a problem? Please describe.
Kinda, conditional styles using the sx prop (and probably the css prop)
Describe the solution you'd like
I'd like to be able to write styles in a similar way than classnames handles things.
I wrote a small helper function that removes falsy styles
export const sx = (...styles: (SxStyleProp | Falsy)[]) =>
  styles.reduce<SxStyleProp>(
    (acc, style) => ({
      ...acc,
      ...(style ? style : {}),
    }),
    {},
  );

Of course this only reduces one level of nesting, the solution would need to be recursive because of all the possible selectors (media queries, pseudo selectors, etc)
Anyways, this allowed me to write my Button component the following way
export const Button = ({
  block,
  variant = 'primary',
  ...props
}: ButtonProps) => (
  <BaseButton
    variant={variant}
    fontSize={1}
    {...props}
    sx={sx(
      {
        outline: 'none',
        cursor: 'pointer',
      },
      block && { display: 'block', width: '100%' },
    )}
  />
);

Describe alternatives you've considered
I considered to write some helper functions similar to invariant e.g.
const invariantStyle = (cond, style) => cond ? style : {};

then
sx={{
    ...invariantStyle(block, { display: 'block', width: '100%' })
}}

but this is not as idiomatic as the previous alternative, it's more verbose and overall worse.
Additional context
None.
Let me know what you think.

Sorry for the mention @jxnblk, but what do you think of this. Also, I wasn't sure if this was the correct repo, if not I can move it to rebass repo.

I just noticed you can't do this as I originally proposed it because the sx prop can't take many arguments as if it were a function lol, but maybe what we can do is accept an array. It would be compatible with functionalities like https://github.com/system-ui/theme-ui/pull/174

Closing as project is dead.


added github logo

I have added the github logo in the navbar as mentioned in issue #5

read https://github.com/shivang21007/Weather-web-app/blob/main/CONTRIBUTING.md
you should discusse issue before making any PR.


Update to 1.32.0

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.


Token filters - trim [DOC]

What do you want to do?

[ ] Request a change to existing documentation
[x] Add new documentation
[ ] Report a technical problem with the documentation
[ ] Other

Create a separate page for Token filter: trim
Part of META issue: https://github.com/opensearch-project/documentation-website/issues/1483
*Version: all

I can take this one


Python 2.6 compatibility

Issue Type

Bug report

Ansible and Ansible Lint details
ansible --version
ansible <IP_ADDRESS>
ansible-lint --version
Python Error (but it's 3.4.17)

ansible installation method: one of source, pip, OS package
OS package (RHEL 6.9 EPEL)
ansible-lint installation method: one of source, pip, OS package
newly built package from https://koji.fedoraproject.org/koji/buildinfo?buildID=1005669

Desired Behaviour
It should not quit with a Python error.
Actual Behaviour (Bug report only)
Currently it just quits with an error.
ansible-lint
Traceback (most recent call last):
  File "/usr/bin/ansible-lint", line 9, in <module>
    load_entry_point('ansible-lint==3.4.17', 'console_scripts', 'ansible-lint')()
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 299, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 2229, in load_entry_point
    return ep.load()
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 1948, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/usr/lib/python2.6/site-packages/ansiblelint/__init__.py", line 28, in <module>
    import ansiblelint.utils
  File "/usr/lib/python2.6/site-packages/ansiblelint/utils.py", line 495
    {'include', 'include_tasks', 'import_tasks'}.isdisjoint(task.keys())]
              ^
SyntaxError: invalid syntax

The fix is changing line 495 in utils.py to
set(['include', 'include_tasks', 'import_tasks']).isdisjoint(task.keys())]
I tested this in https://github.com/larsweiler/ansible-lint/blob/927d84ff4fff1cef12b7c3bd4b10362747d5ef7f/lib/ansiblelint/utils.py#L495

If you have a fix, could you turn the fix into a pull request?

Sure, pull request #305 created.

Closed - thanks for raising #305


chore(docs): Fix a few links to docs

Docs links changed

Benchmark results
Metrics with a significant change:

note_trial_decrypting_time_in_ms (32): 33.0 (-79%)

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Values are compared against data from master at commit 80be57d6 and shown if the difference exceeds 1%.
L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
128 txs

l1_rollup_calldata_size_in_bytes
45,412
179,524
716,068

l1_rollup_calldata_gas
221,608
866,776
3,447,004

l1_rollup_execution_gas
314,095
984,516
3,666,661

l2_block_processing_time_in_ms
1,156
4,335
17,212 (-1%)

note_successful_decrypting_time_in_ms
260 (+3%)
1,001 (+12%)
3,349 (-2%)

note_trial_decrypting_time_in_ms
68.5 (+11%)
:warning: 33.0 (-79%)
153 (+2%)

l2_block_building_time_in_ms
16,422
64,827
260,220

l2_block_rollup_simulation_time_in_ms
11,845
46,726
188,401

l2_block_public_tx_process_time_in_ms
4,548
17,962
71,507

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
5 blocks
10 blocks

node_history_sync_time_in_ms
13,416 (-5%)
25,675 (-7%)

note_history_successful_decrypting_time_in_ms
2,183 (+4%)
4,269 (-5%)

note_history_trial_decrypting_time_in_ms
141 (-49%)
193 (-17%)

node_database_size_in_bytes
17,293,392
33,169,488

pxe_database_size_in_bytes
29,923
59,478

Circuits stats
Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit
circuit_simulation_time_in_ms
circuit_input_size_in_bytes
circuit_output_size_in_bytes

private-kernel-init
221
44,777
26,073

private-kernel-ordering
179
44,393
14,809

base-rollup
1,251
128,850
881

root-rollup
83.2 (+1%)
4,088
677

private-kernel-inner
311
71,816
26,073

public-kernel-private-input
216
32,375
26,073

public-kernel-non-first-iteration
214
32,417
26,073

merge-rollup
7.66
2,608
881

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
0 deployed contracts
1 deployed contracts

tx_size_in_bytes
15,455
32,993

Transaction processing duration by data writes.

Metric
0 new commitments
1 new commitments

tx_pxe_processing_time_ms
395
1,121

Metric
1 public data writes

tx_sequencer_processing_time_ms
556


Improve env ls error output

What does this PR do?
Improve env ls error output
Review checklist (to be filled by reviewers)

[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached
[ ] Feature or bugfix must have tests
[ ] Git history must be clean
[ ] If PR adds a configuration option, it must be added to the configuration file.

Ok, seems not very popular i


Labels with spaces produce invalid type names

With this schema:
export const RegisterAccountParams = Joi.object({
  name: Joi.string()
    .label("Company Name")
    .required(),
  phoneNumber: Joi.string()
    .label("Company Phone Number")
    .required(),
  customerEmail: Joi.string()
    .label("Customer Email")
    .required(),
  website: Joi.string()
    .label("Website")
});

this output is generated:
/**
 * This file was automatically generated by joi-to-typescript
 * Do not modify this file manually
 */

import { Customer Email, Company Name, Company Phone Number, Website } from '.';

export interface RegisterAccountParams {
  customerEmail: Customer Email;
  name: Company Name;
  phoneNumber: Company Phone Number;
  website?: Website;
}

The import statement is clearly incorrect. It seems to me that joi-to-typescript takes label to mean that we're referencing another named exported schema, which is not our intention.
Labels are handy for customizing the error messages that Joi throws on validation failures. Is there a way that this behaviour might be made configurable, or perhaps default to ignoring label modifiers on object properties?
To be clear, we expect an output similar to this one:
export interface RegisterAccountParams {
  customerEmail: string;
  name: string;
  phoneNumber: string;
  website?: string;
}

Labels are an integral part how this library works. I am using label so this library will work with hapi-swagger.
I would like to swap from label() to id() but im not sure if that is even possible.
If you can I suggest swapping from label() to description()

Unfortunately, description will not work for our use case. We use label for its effect on Joi's error output. description has no such behavior. Perhaps we should instead write a custom error handler to capitalize and transform our camelCase property names, rather than use label.
At any rate, for labeled properties in every case to output the label value in type positions seems like a bug, or perhaps a logical error. This behavior would make sense if the value for label matches a type name that has already been parsed. In other cases, such as when the label value contains spaces, this assumption does not hold, and this package generates invalid TypeScript.
Is there some compromise that can be made, perhaps either throwing an error if the label value contains spaces, or making this label behavior more configurable? Perhaps spaces should be ignored, and values transformed into CamelCase. I would be willing to structure my schemas differently to support a solution, especially if it preserves existing functionality.
For example, my case above already partially works in the case of the website property if I define and export a schema under the Website name, like so:
export const Website = Joi.string()
  .label("Website");

This way, the Website schema still uses a capitalized name in the event of a validate error. I have tested this case; to export Website this way today generates a Website type as an alias to string and uses that as the type for the website optional property. This behavior is technically correct, and compiles, and so is acceptable to me.
The other properties' labels contain spaces, and therefore will not compile this way under the current version of joi-to-typescript.
If joi-to-typescript could be made to ignore or transform label modifiers that contain spaces, then the rest of the schema might be defined this way:
export const CompanyName = Joi.string()
  .required()
  .label("Company Name");

export const CompanyPhoneNumber = Joi.string()
  .required()
  .label("Company Phone Number");

export const CustomerEmail = Joi.string()
  .required()
  .label("Customer Email");

export const RegisterAccountParams = Joi.object({
  name: CompanyName,
  phoneNumber: CompanyPhoneNumber,
  customerEmail: CustomerEmail,
  website: Website
});

This should allow the types to generate properly, albeit with some gratuitous type aliases to string

Hi @AverageHelper if you are interested in doing a Merge Request I can look at your idea further.

#99 seems to work for my use case.

Cheers dude, I'll get this released

version 1.14.1 released, thank you for the contribution :)
This has made me think more about moving the label() options to id() especially for this type of use case


java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8

Windows 10, running openjdk 11 (64 bit).  Running version 3.22 using AES256.
At first glance I thought it was related to https://github.com/xerial/sqlite-jdbc/issues/351 or https://github.com/xerial/sqlite-jdbc/issues/269...  but I'm not sure for two reasons:

Those issues have been closed for quite some time.  I believe the fixes should be in the code already.
The issues seem to be related to multithreading...  This is occuring in my main method which is only being called the one time.

I cannot reproduce it--got the stack trace from a bug report.
Relevant stack trace:
java.lang.UnsatisfiedLinkError: org.sqlite.core.NativeDB._open_utf8([BI)V
        at org.sqlite.core.NativeDB._open_utf8(NativeDB.java:-2)
        at org.sqlite.core.NativeDB._open(NativeDB.java:71)
        at org.sqlite.core.DB.open(DB.java:174)
        at org.sqlite.core.CoreConnection.open(CoreConnection.java:220)
        at org.sqlite.core.CoreConnection.<init>(CoreConnection.java:76)
        at org.sqlite.jdbc3.JDBC3Connection.<init>(JDBC3Connection.java:25)
        at org.sqlite.jdbc4.JDBC4Connection.<init>(JDBC4Connection.java:24)
        at org.sqlite.SQLiteConnection.<init>(SQLiteConnection.java:45)
        at org.sqlite.JDBC.createConnection(JDBC.java:114)
        at org.sqlite.JDBC.connect(JDBC.java:88)
        at java.sql.DriverManager.getConnection(Unknown:-1)
        at java.sql.DriverManager.getConnection(Unknown:-1)

Any ideas?  Will the newest release potentially fix this?  Will you get jar's out for the newest release or do I need to build myself?
Edit:  looks like there are more issues still open that could be relevant: https://github.com/xerial/sqlite-jdbc/issues/337 and https://github.com/xerial/sqlite-jdbc/issues/225

@camhart
I've quickly checked issues that your are referencing, and as you said, the code it self is exactly the same as xerial repo. The only thing that changes is the SQLite native library that is inside the jar. I personally never encountered this error.
niktsar@69a5741 => this solution is already implemented in the original source code.
I might have missed one flag at compilation time. I'll check that soon.

Will the newest release potentially fix this? Will you get jar's out for the newest release or do I need to build myself?

I currently have some problems (most of them are solved by using a newer gcc-version) with the cross-compilation for some platforms ( arm based build especially). This is why there is not a new jar for the moment.
If you are targeting 32/64bit "x86" platforms on Windows or Linux you could eventually try to build it yourself.  For that you will need docker and you will have to make changes at line 101 of the Makefile in order to select the desired platforms.
One thing to note :
wxSQLite3 introduced in version 4.0.0 the ability to have multiple encryption algorithm, and therefore the default algorithm is not AES. It has switched to CHACHA20. For more information on how to use and set cipher I will redirect you to the wxSQLite3 readme : https://github.com/utelle/wxsqlite3/tree/master/sqlite3secure.
If you want the old algorithm as default cipher type, It is possible to change the default algorithm.
If you want AES256 you will just have to change line 64 of the Makefile to -DCODEC_TYPE=CODEC_TYPE_AES256 and if it is not compatible with your existing databases, you might need to add -DWXSQLITE3_USE_OLD_ENCRYPTION_SCHEME

@camhart I've solved all problems and created a new release with SQLite 3.25.3 and all the improvement from the wxSQLite repo. The note at the end of my previous comment is still applicable. If any issue let me know.

Thanks for this!

now i found this issue


Template editor confirmation window scales incorrectly

This is how it looks in 1920x1080:

Adding this tidbit, but sorry if it is the wrong category:
The same, in a way, happens when enabling Dalamud's Multi-Monitor support but it gets really small in terms of width instead.


IsCodeLike needs rewrite

@erights @waldemarhorwat have ideas.
+ @bakkot too since failure to resolve concerns from issue #1 would obviate this.

@erights
As discussed in person, IsCodeLike is not meant to preserve security properties; security properties about what can execute are in the host callout, so the fact that any user code can add a symbol is not security significant.  It just allows more consistency in the host callout since host callouts don't need to do checks like "if called via eval and the argument is not a string or a value I consider codelike."
There are backwards compatibility concerns with eval that might arise if we were to just have eval always stringify.
{
  let NaN = 42;
  isNaN(eval(0/0));  // -> true
  isNaN(eval(String(0/0)));  // -> false
}
// If we always stringified, both would always -> true

@waldemarhorwat
As discussed in person, the threat model is that an attacker may control strings, numbers, and so may craft the kinds of objects that you might get from JSON.parse(x).
We want to keep those away from eval, so are concerned with
// In the absence of CSP
const attackerControlledString = ' ["alert(1)"] ';
eval(JSON.parse(attackerControlledString));  // currently just returns an array

@waldemarhorwat @erights Do you have outstanding concerns regarding isCodeLike shape, after Mike's explanation? It's not clear to me if this issue was resolved in December, looking at the minutes.

@waldemarhorwat @erights, friendly ping. I wanted to understand if there are remaining concerns after Mike's explanation.

@waldemarhorwat @erights ping, I wanted to apply for stage 2 at the next meeting, and I wanted to understand if you consider this a blocker. The proposal was changed recently, please see the updated text.

I'm still missing the big picture here. If I understand this correctly, you want to allow implementations to disallow strings in eval and allow only vetted objects to be eval'd. That just shifts the problem from trying to sneak exploits past function A (eval) to trying to sneak exploits past function B (the function that sets isCodeLike). What justifies the extra complexity?

That just shifts the problem from trying to sneak exploits past function A (eval) to trying to sneak exploits past function B (the function that sets isCodeLike).

Correct, with the note that function B is also guarded (via CSP in the web platform).

What justifies the extra complexity?

https://github.com/tc39/proposal-dynamic-code-brand-checks#motivation. In short, the host controls of allowing or disallowing eval completely are not good enough in practice, as the majority of the programs (web applications) end up requiring eval. This was discussed in #1, see e.g. https://github.com/tc39/proposal-dynamic-code-brand-checks/issues/1#issuecomment-501346106.
Having brand checks allows the authors to guard eval payloads selectively. For a practical example: with it, we can make sure that only the payloads for the anti-abuse eval-based VM engine are allowed in the application without opening up the application for eval fully. We're essentially moving the guard to a more effective place - from the sink to the value producer.

One extra thing I realised might not be clear without having worked with Trusted Types, that seems relevant: The guards for the 'code like' producers in the web platform are set up on their factories (Trusted Type policies) - this allows us to restrict code-like object creation like capabilities (one can only create a codelike, if one has a reference to a policy object, and creation of policy objects is guarded), so e.g. we can be sure that only a given module will produce codelikes, and unless the capability is exported from that module, nothing else will successfully call eval, even though they have a reference to eval function.

@waldemarhorwat does my explanation clear up things? I wanted to apply for stage 2 advancement and the deadline is approaching. I want to understand if you (or @erights) consider this a blocker for stage 2.

@waldemarhorwat does my explanation clear up things? I wanted to apply for stage 2 advancement and the deadline is approaching. I want to understand if you (or @erights) consider this a blocker for stage 2.

Still waiting for y'all feedback. I tentatively applied for stage 2, happy to discuss this before or at the plenary.

Still waiting for y'all feedback. I tentatively applied for stage 2, happy to discuss this before or at the plenary.

This can be closed as there is no longer an IsCodeLike concept (there's a host hook that serves a similar purpose but the security semantics are down to the host platform now)


More flexibility with multitouch gesture events

Give the possibility to get the local position with your own global position.
Add the global position on all changedTouches object
Best way to gesture the double tap event on touchstart and getting each position.
This feature give us the possibility to manage multitouch event in the save object ex: Resizing Gesture event with two touch moving in the same time.
add optimisation and speed up the code

It's done for you mister @englercj :) I love the new framework of the code, it took me a few minutes to understand what had changed between v2 and v3...

Thanks for all the hard work, I really appreciate it!
The part I'm not crazy about in this PR is that it generates a lot of throw away objects. Each time a touch starts or ends we create a new Point object.
Also, isn't getTouchData already doing what you added in the touch start/end events?

Ok @englercj right now it's very better ! :)
The idea is to send global position with all changedTouches. Currently the e.data.global just give the position of one touch in the elements, but if you want do some gesture event, like pressing double touch on one element and extend out to resize (pinch), you need to give also the global position of each others changedtouche.
So when you check e.data.originalEvent.changedTouches[0].globalX now with my modification you get the global position to a specific touch, and if you have double, you can get it on e.data.originalEvent.changedTouches[1].globalX.
So for gesture you need to use:

"e.data.originalEvent.touches.length" to know how many touches are in the elements.
"e.data.originalEvent.changedTouches" to know which touches have ben changed
"e.data.originalEvent.changedTouches[0,1,2...].globalX and Y" to get the global position of the touch
"e.data.originalEvent.changedTouches[0].identifier to identify who really is the touch, because the order can be differences denpending of the traking of your tocuhes.

I'M currently working on a app using pixijs, and I have gesture event, zoom in and out, moving in a area with bounds limit, bouces and velocity depend on avanced speed traking of you touchMove etc.
Currently, I am on v2, but I'll pass v3 when it is more stable.


server crashes with "qemu: uncaught target signal 6" on Mac M1 silicon

Using the 0.8.0-SNAPSHOT image, but running on a Macbook and Docker, I think the image uses x86 emulation.  There is a bug (perhaps unfixed) in how qemu relates to this emulation.
That resulted in the server dumping core with the message "qemu: uncaught target signal 6".
I worked to build the image for arm64 (aka mac M1 or M2 silicon) using the edit to the Dockerfile in #28 and using --platform=arm64 and that seems to fix the issue (after specifying --no-cache on the docker build. e.g.,
docker build --platform=linux/arm64  -t grobid/software-mentions:0.8.0-SNAPSHOT-arm64 --build-arg GROBID_VERSION=0.8.0-SNAPSHOT-arm64 --file Dockerfile.software .
Perhaps images could be built as multi platform with --platform=linux/amd64,linux/arm64 as described here:
https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/
(but see below, that seemed to work briefly but now fails, which is very odd).

Well, I'm completely stumped.  10 minutes ago this image (built with --platform=linux/arm64) was avoiding this error that says qemu: uncaught target signal 6.  I was seeing calls to the annotate_tei method and the counter for processed files from the client was going up (slowly); that said, no software.json files were written, so it wasn't perfect.
Now, same image, same data, is immediate throwing that error.
I've tried everything I can think of, can't get this to run on M1 Mac (via Docker, I also tried to get the server to run directly, using the compile instructions) but none of that worked.  I guess I'll try via AWS?

Working on the mac m1 build for Docker is really difficult when you don’t have the hardware.  I don’t exactly know how to go about it, perhaps some other grobid users have it working?  It’s definitely something to do with qemu, but I’m not sure if the versions are pinned or if they could be updated?

I played with this a little more.  A few notes for others that might come this way:

Following the hint at the end of https://github.com/tensorflow/tensorflow/issues/52845#issuecomment-1272337911 I backed out the stage_1 base image to FROM python:3.8-slim then did a RUN pip install tensorflow tensorflow-io.  Building with docker build --platform=linux/arm64/v8 -t grobid/software-mentions:0.8.0-SNAPSHOT-aarch64 --build-arg GROBID_VERSION=0.8.0-SNAPSHOT-aarch64 --file Dockerfile.software . that completes fine.  And the builder stage seems to build as arm64 fine (btw, I have no idea of the difference, if any, between aarch64 and arm64)
Then one runs into a problem with DeLFT 0.3.3 that shows up from a dependency that is trying to build tensorflow-gpu (which is deprecated, apparently they are the same but they've stopped building a package with that name?). Also showed up as a problem installing tensorflow==2.9.3
I forked DeLFT at https://github.com/jameshowison/delft and added git to the install so I could mess with the dependencies and eventually figured out that the setup.py was the place to change some of the pinned version numbers.  I changed tensorflow to >=2.9.3 but had to remove tensorflow-addon entirely (it is now deprecated, so I don't think there are built versions available for aarch64?)
With those dependency changes then the pip install line works.
Unfortunately I then run into trouble with the # install jep (and temporarily the matching JDK) step.  That seems to be directly grabbing a jdk and I'm guessing a x86 one because the error is:

 > [stage-1 14/34] RUN /tmp/jdk-17/bin/javac -version:
0.456 qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No such file or directory

Ah, I see that it's actually in the name openjdk-17.0.2_linux-x64_bin.tar.gz
Does the jep install need to be done this way, could more standard package installs help?

It is possible that the jep install will work with:
RUN JAVA_HOME="$(dirname $(dirname $(readlink -f $(which java))))" pip3 install jep==4.0.2

based on reading: https://stackoverflow.com/questions/43655291/dynamically-set-java-home-of-docker-container
That does seem to work for me in the Dockerfile.software

So, maybe making progress.  I can get the docker build to finish, and it does create an aarch64 image.
Unfortunately, it hits this error:
screenit-softcite-server_software_mentions-1  | INFO  [2023-08-01 19:34:43,591] com.hubspot.dropwizard.guicier.DropwizardModule: Added guice injected health check: org.grobid.service.controller.HealthCheck
screenit-softcite-server_software_mentions-1  | com.google.inject.CreationException: Unable to create injector, see the following errors:
screenit-softcite-server_software_mentions-1  |
screenit-softcite-server_software_mentions-1  | 1) Error injecting constructor, java.lang.UnsatisfiedLinkError: /opt/grobid/grobid-home/lib/lin-64/libwapiti.so: /opt/grobid/grobid-home/lib/lin-64/libwapiti.so: cannot open shared object file: No such file or directory (Possible cause: can't load AMD 64 .so on a AARCH64 platform)
screenit-softcite-server_software_mentions-1  |   at org.grobid.service.GrobidEngineInitialiser.<init>(GrobidEngineInitialiser.java:29)

So lin-64/libwapiti.so is something built earlier in the chain.

@kermitt2 Hi Patrice, I'm trying to return to this, any idea if there was progress here?  I'll check over on grobid/grobid as well.

Hi James, I am calling for help @lfoppiano for the issue because he concentrates all the experience for running Grobid on mac and on the challenge of building a arm64 docker image.
Afaik aarch64 and arm64 are the same.

Hi @jameshowison,
this subject is still open, since we still don't have a CI that build images for ARM yet.
First, could you try to run this image on your Mac and let me know if it works (try to process a few files)?
https://hub.docker.com/layers/lfoppiano/grobid/0.8.0-arm/images/sha256-79b85da73bae5c2a483e381c1e1231bc73dc0d6b987f16b867a3eb6e8154d7b8?context=explore
Given that software-mention is based on Grobid I think the simplest is to build its docker image from the grobid one, unless I'm overlooking something 😅


Request for Option to Disable Reset in unocss-useful Preset

I hope you're doing well. I'm encountering conflicts with other UI frameworks due to the reset included in the unocss-preset-useful preset. Could we add an option to disable this reset injection? It would enhance compatibility and usability for a wider range of projects.

I finally found out there is a setting but the readme.md didn't mention.

    /**
     * Enable reset styles
     *
     * @default true
     */
    enableResetStyles?: boolean;


Add dial timeout

Some service provider block personal ip address and some do not give any response.
In my case, naver.com act as waiting villain.

Hello @nilslice , sorry for late response.
Ok, I will PR again

Hi, I'm closing this after opening a new PR using your branch as a base. See https://github.com/nilslice/email/pull/4 for more details. Thank you!


Emulator locale needs to be changed manually

The documentation should reflect that the emulator locale needs to be changed locally to see the added language. The web-chat changes automatically. The Emulator does not.

Open the Bot Framework Emulator
Open the Settings tab.
Set your desired locale in the Locale field and click Save
Connect to the bot

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 51e3f9d9-a593-40a3-bd68-1235966cca23
Version Independent ID: 6984f534-80f3-6bd8-0392-b1cedf86393a
Content: Multiple language support - Bot Composer
Content Source: composer-docs/how-to-use-multiple-language.md
Service: bot-composer
GitHub Login: @zxyanliu
Microsoft Alias: kamrani

Thanks for pointing this out. We added instructions in the linked PR.
Closing now that changes are merged.


Support ForNpgsqlUseIdentityAlwaysColumns with HasData

Currently Entity Framework Core's data seeding feature HasData does not support ForNpgsqlUseIdentityAlwaysColumns, because GENERATED ALWAYS AS IDENTITY does not allow inserting values in the identity column if OVERRIDING SYSTEM VALUE is not specified in the INSERT clause.
This could be supported by adding InsertDataOperation hook to NpgsqlMigrationsSqlGenerator. For inspiration, here's the SqlServerMigrationsSqlGenerator implementation using SET IDENTITY_INSERT.
See also the earlier discussion.

No problem, I'll try to get this in soon.

Btw, how do you see, should this also fix the next value for sequences similar to other implementations, so we would not have to rely on negative indexes?

@ljani I'll have a look, but I don't think this will help the sequence conflict issue. In PostgreSQL, a serial column is simply a column with a default value coming from a sequence. If the application provides a value (like seeding does), there's no way AFAIK of making the sequence "aware" of that. The comment you linked to for SQL Server is about identity columns, which are a specific feature of that database which resembles the new PostgreSQL identity rather than serial columns.
It may be possible to check, after applying migrations, whether data has been seeded, and to manually update the sequence to be above the maximum value in the database - but I'm really not sure how easy/practical that would be.
Coming to think of it, I'm not sure that the negative indices issue won't exist even with PostgreSQL identity columns... Even if we tack OVERRIDING SYSTEM VALUE on the insert statement, I don't know if PostgreSQL actually updates the identity column's behind-the-scenes sequence or not. This will need to be tested.

Done, seeding now works with IDENTITY ALWAYS. However, you still need to use negative values to avoid conflicts.

@roji 	so what's the current fix? Always explicitly set Id to 0 or negative value?

@Sigvaard that's right - seed with negative values to make sure seeded values don't collide with values later generate from the identity sequence.

@roji is this documented somewhere with example?

@Sigvaard as you correctly noted, this is more of a PostgreSQL question than an Npgsql question - PostgreSQL simply doesn't automatically update sequences when you manually insert into columns managed by them.
I personally think that the negative values workaround is good - there's really no concrete disadvantage unless you consider something wrong esthetically with negative IDs.
In theory, whenever we scaffold a migration that adds seed data, we could also restart the sequence at value x, where x is the max of the current values in the column in the database and the max value to be seeded. While this may work, it presents some challenges:

ALTER SEQUENCE <seqname> RESTART WITH x doesn't accept an expression for x, only a literal. This makes it impossible to make sure the new sequence is value is bigger than any existing value in the table.
The setval() function does allow expressions, but is non-transactional, so rolling back the migrations transaction (because of a later failure) will not roll back this change. This may not be a huge problem since the new value is guaranteed to be bigger than the current one anyway.

So this can be done, and I do admit that people have been running into this issue - it would be nice if people could just seed their IDs as they see fit and forget about negative values. @austindrenski @YohDeadfall what do you think?

So this can be done, and I do admit that people have been running into this issue - it would be nice if people could just seed their IDs as they see fit and forget about negative values.

I agree, it would be more intuitive if negative values were not required.

ALTER SEQUENCE  RESTART WITH x doesn't accept an expression for x, only a literal. This makes it impossible to make sure the new sequence is value is bigger than any existing value in the table.

Could we use this for initial migrations? The idea being that if we detect that a migration is being generated from something like context.Database.EnsureCreated(), we use the transacted version (since we can count the seeded values), otherwise we fallback to the setval() version?

Agreed with @austindrenski. If you display a negative id somewhere, it should be without a minus sign which could be done using some dirty magic.

Could we use this for initial migrations? The idea being that if we detect that a migration is being generated from something like context.Database.EnsureCreated(), we use the transacted version (since we can count the seeded values), otherwise we fallback to the setval() version?

Although this is possible, what would be the value of using ALTER SEQUENCE only in the case of initial migrations, and setval() otherwise? I think it's preferably to choose one technique and stick with it rather than having two, and then we open the door to behavioral changes between an initial migration and a subsequent one...
I also don't really see a difference between an initial migration and a subsequent one in terms of either transactionality or the ability to count the seeded values - both migrations are executed in a transaction (and expected to roll back cleanly on failure), and both can look at the model and find the maximal seeded value for a column (at least I think so...).

Agreed with @austindrenski. If you display a negative id somewhere, it should be without a minus sign which could be done using some dirty magic.

I'm not sure I understand... The idea is to stop forcing users to seed negative values by making sure the sequence is always bigger than the larger value...

Although this is possible, what would be the value of using ALTER SEQUENCE only in the case of initial migrations, and setval() otherwise? I think it's preferably to choose one technique and stick with it rather than having two, and then we open the door to behavioral changes between an initial migration and a subsequent one...
I also don't really see a difference between an initial migration and a subsequent one in terms of either transactionality or the ability to count the seeded values - both migrations are executed in a transaction (and expected to roll back cleanly on failure), and both can look at the model and find the maximal seeded value for a column (at least I think so...).

Perhaps I need to take a closer look at the relevant source... My thought process was this: if the transactability is desirable, use the version that respects the transaction where possible.
But that might not actually make much sense in this context. If so, disregard.

I think that transactability is indeed desirable for all migrations - initial or subsequent. However, in this very specific case it may be OK to not roll back the sequence, since it could only have been increased, so no harm was done - at worst there will be a gap in the sequence values.
But we definitely need to think about this some more, and remember that there's a well-working workaround (negative values) - so I definitely wouldn't go into anything complex or risky here.


chore: bump dependent packages

Description
chore of bumping dependent packages via npm audit fix
References
N/A
Review Checklist

[x] I have clicked on "allow edits by maintainers".
[ ] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[x] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Superseded by https://github.com/openfga/js-sdk/pull/25


gerbera: 1.8.2 -> 1.9.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/gerbera/gerbera/releases.
meta.description for gerbera is: "UPnP Media Server for 2020"
meta.homepage for gerbera is: "https://docs.gerbera.io/"
meta.changelog for gerbera is: ""
Updates performed

Version update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/0ndpp7mjq78snr0gv8wqfimsbsdlk1zl-gerbera-1.9.0/bin/gerbera passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 1.9.0 with grep in /nix/store/0ndpp7mjq78snr0gv8wqfimsbsdlk1zl-gerbera-1.9.0

found 1.9.0 in filename of file in /nix/store/0ndpp7mjq78snr0gv8wqfimsbsdlk1zl-gerbera-1.9.0

directory tree listing: https://gist.github.com/021a9c540ac125f41e8efc8889e637ed

du listing: https://gist.github.com/a285fe41e6796b8392de5b2850230872

Rebuild report (if merged into master) (click to expand)

1157 total rebuild path(s)

341 package rebuild(s)

340 x86_64-linux rebuild(s)
304 i686-linux rebuild(s)
212 x86_64-darwin rebuild(s)
301 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
alot
ansible
ansible-lint
ansible_2_10
ansible_2_11
arcan.arcan
arcan.arcan-wrapped
arcan.durden-wrapped
arcan.everyone-wrapped
arcan.pipeworld-wrapped
arcan.prio-wrapped
arcan.xarcan
aws-sdk-cpp
beancount
bluespec
brave
bundix
cabal2nix
cachix
cargo-criterion
cargo-expand
cargo-release
ccextractor
charliecloud
check-mssql-health
chirp
cl
cloudflared
common-updater-scripts
containerd
coqPackages.interval
crate2nix
criterion
crow-translate
crystal2nix
dep2nix
diff-so-fancy
diffoscope
diffoscopeMinimal
docker
docker-edge
docker-gc
docker_20_10
dydisnix
dyncall
easyeffects
ejabberd
elixir
elixir_1_10
elixir_1_11

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/0ndpp7mjq78snr0gv8wqfimsbsdlk1zl-gerbera-1.9.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A gerbera https://github.com/r-ryantm/nixpkgs/archive/064b1e0c30b2f41fbd6ee67bd8238693104efe41.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/0ndpp7mjq78snr0gv8wqfimsbsdlk1zl-gerbera-1.9.0
ls -la /nix/store/0ndpp7mjq78snr0gv8wqfimsbsdlk1zl-gerbera-1.9.0/bin

Pre-merge build results
NixPkgs review skipped

Maintainer pings
cc @ardumont for testing.

Result of nixpkgs-review pr 132214 run on x86_64-linux 1

1 package blacklisted:

tests.nixos-functions.nixos-test

1 package failed to build:

nixos-install-tools

1 package built:

gerbera


It doesn't work.

I have followed installation instructions and my game does not seem to be able to launch when double clicking NMSELauncher.exe - nor does it work through running as administrator.
Using version 1.1.0 NMSEAlphav1.1.0 from NexusMods.
PS: I'm using the experimental version that Hello Games released.
UPDATE
It works! I had to follow these steps:

If your NMSE is constantly crashing delete everything inside your \binaries\ folder and verify your cache (either with gog or steam)
(Taken from here)

Only problem is: my HUD cannot be toggled. (Pressing F5 has no effect whatsoever)

You need to make sure you're launching the game through NMSELauncher. Also make sure that there is an folder in binaries Called NMSE with your NoHUD.dll inside.
Take a picture of directory and link it to me.


P0443 r2

This is a first in a series of PRs to align our executor implementation to the ongoing standardization process.

Could you please rebase your changes to not include the cmake changes that are already on master to make reviewing easier?

@sithhell done.


Add isort and flake8 to format checks

Merging this since the discovered format problems should be addressed in separate PRs.


OSRA-389 OSRA-390 father_alive -> father_deceased

https://osraav.atlassian.net/browse/OSRA-389
https://osraav.atlassian.net/browse/OSRA-390
Replace father_alive in the Orphan model with father_deceased to match
OSRA spreadsheets.

add new boolean column father_deceased to orphans table and populate it
with the inverse values of existing father_alive; remove father_alive
column
rename father_alive to father_deceased in the pending_orphans table
modify importer settings to process column G of spreadsheets as
father_deceased instead of father_alive and to use "Y" & "N" only
(not Arabic words for 'dead' & 'alive')
refactor orphan validations pertaining to father's death for clarity and to
use father_deceased as the main point of reference
switch from using father_alive to father_deceased in models, tests,
views, etc.
restore orphans factory's ability to randomly produce orphans with living or
deceased fathers
update spreadsheet fixtures to follow latest template format and to have
info consistent with new usage of father_deceased

can you send me a copy of the production db? I would like to test this PR

@razorcd PM sent on Slack

What is the plan B in case we get a problem in production?

@gmunumel Roll back the commits, restore db from backup. Painful but doable.

I guess you are going to try to apply this change at midnight.

Yes, we have access to the production db, so we can make sure that all orphan records are still valid after the update. @razorcd ran this against a copy of the production db last night and everything looked fine. Let's be very confident in our code before merging, that way we won't have to keep our finger on the 'Alarm' button as we push to production :)

hahaha, yes. :D

:shipit:

Ready to go :+1:


Can we sync/handle burn-ins for streaming ensembles?

See callable class evaluator idea in #101
Having classes for evaluators might help us move towards storage of object states over time -- which help with this issue. Perhaps these classes should also be called Election or something easier to understand when initializing an ensemble, which can have a default election scheme, as well.

Making a note here, that if we switch to functions/classes for the evaluators, probably want to drop the EVALUATORS global, so the import will look like from menelaus.ensemble import Ensemble, eval_confirmed_approval (or similar) rather than from menelaus.ensemble import Ensemble, EVALUATORS.

The two cases from literature which it'd be good to have handled were Maciel 2015 and Du 2014.
Du:

On a second read, I think the elaboration is more to do with which detectors are chosen for the ensemble, based on their performance in one or more reference datasets. The core loop is -- if any of the members alarm, reset everything and retrain. The minimum_approval evaluator handles that case.

Maciel:

The idea here is, if a detector alarms, then it waits for a certain number of samples for confirmation from another detector. In the meantime, it resets and starts "retraining," and its output is ignored. If another detector fires within the window, the whole ensemble enters the drift state.
The wait time could be smaller than the burn-in/window size/etc. for member detectors, so we'll need to put a warning in the docstring.
The example from the original paper makes use of detectors which we don't currently have implemented. Maybe worth a TODO later.
The novelty here, and the motivation for the class evaluators over functions, is that the Evaluator needs to remember its own state in between updates - it's not a strict function of the detector list.

I wrote something up that I think does most of what's needed for the Maciel case. Probably can shuffle the references to the detector list between init and call. Need to do another pass to make sure its behavior should be equivalent to the paper.
class MacEvaluator():
	def __init__(self, sens, wait_time, detectors)
		self.waiting_counters = [0 for d in detectors]
		#list of the same size as the detector list/dict
		# this needs to persist between iterations
		self.sens = sens

	def __call__(self, detectors):
		num_drift = 0
		num_warning = 0
		states = [d.drift_state for d in detectors]
		for i, state in enumerate(states):
			if state is "drift" and self.waiting_counters[i] == 0: #if detector i is in a "waiting" state, its response should be ignored
				num_drift += 1
				waiting_counters[i] += 1
			elif detector.drift_state is "warning":
				num_warning += 1
			elif self.waiting_counters[i] != 0: #if the detector is in a "waiting" state, increment its counter
				self.num_drift += 1 # waiting detectors should count toward this total
				self.waiting_counters[i] += 1

		if num_drift >= self.sens:
			result = 'drift'
		elif num_warning + num_drift >= self.sens:
			result = "warning"
		else:
			result = None

		#see if any of the detectors have fallen out of confirmation
		#this may be better framed as a "reset" method. whatever
		#double-check that this occurs in the right place, as we have to do it post-update and the paper does it pre-update
		for i, state in enumerate(states):
			if state is not "drift" or waiting_counters[i] > wait_time:
				self.waiting_counters[i] = 0

		return result

Also, I really like the idea of calling them Elections.

Much later if we come across the issue of an election needing information about the ensemble properties, there is precedent I've seen in other work for passing that along:
class A():
    def __init__(self, rules_to_execute):
        self.rules_to_execute = rules_to_execute

    def compute(self):
        for rule in self.rules_to_execute:
            output = rule(self)
            # store/process output

There's also an SO answer describing passing references around of the outer object.
There is no problem with that whatsoever - self is an object like any other and may be used in any context where object of its type/behavior would be welcome.

In Python, as exemplified by the standard library, instances of self get passed to functions (and also to methods, and even operators) all the time.

(but no need to commit to that yet)


fix(driver)!: create dedicated events for umount2 syscall and rename them to "umount2"

What type of PR is this?
/kind bug
/kind cleanup
Any specific area of the project related to this PR?
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
/area libscap-engine-bpf
/area libscap-engine-kmod
/area libscap-engine-modern-bpf
/area libsinsp
/area tests
Does this PR require a change in the driver versions?
No
What this PR does / why we need it:
This PR addresses part of the https://github.com/falcosecurity/libs/issues/911 issue.
Before this patch, umount2 was associated with event pair PPME_SYSCALL_UMOUNT_E, PPME_SYSCALL_UMOUNT_X and "umount" name. Every syscall should have its own events pair, with the right name (in this case "umount2"). This PR is the first step in that direction!
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:
fix(driver)!: create dedicated events for `umount2` syscall and rename them to "umount2"

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97
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 [Andreagit97]

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

LGTM label has been added.  Git tree hash: b8c53e06e94bc1b472039562ba633b4fabc90873

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP
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 [Andreagit97,FedeDP]

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

LGTM!
/hold until we formalize agreement around non-shared event names across the board, see https://github.com/falcosecurity/libs/pull/936#issuecomment-1456350010.

I need to rebase it on master, after #937

New changes are detected. LGTM label has been removed.

adapted using the new ppm_sc table

after the rebase the CI is failing on ARM64 i supposed that there is something strange under the hood, i will take a look :eyes:

Hey, folks here there is something strange.. we are using libsinsp::events::names_to_sc_set() API to convert event_names to sc_set while its dual libsinsp::events::sc_set_to_names convert sc_set to sc_names :/ this is quite confusing in my opinion. Right now we can keep it as it is in this PR but my proposal would be:
1. create 2 methods that convert `event_names` -> `sc_set` (what is doing `names_to_sc_set`) and vice-versa `sc_set` -> `event_names`

2. restore original behavior of `libsinsp::events::names_to_sc_set()`  so `sc_names` -> `sc_set`

3. rename all methods like `names_to_sc_set` in something more meaningful like `sc_names_to_sc_set`, "names" alone is too generic IMHO

@FedeDP @jasondellaluce @incertum

It is the expected current behavior given shared event names across syscalls, e.g. Falco rule calls accept -> activate both accept, accept4. Would propose to hold this PR or any further back and forth until @jasondellaluce formalizes agreement on "requiring Falco to call the real syscall string name in the rules at all times in case of a syscall event".
Then perhaps we should first have another PR that changes this for other shared event cases, e.g. the accept -> activate both accept, accept4case and similar ones. The current workaround innames_to_sc_setcan then be removed again in that very same PR as it will then be redundant, but it's a big!` for all Falco end users.
re  names_to_sc_set, I think it is fine to keep the name, but we could rename it (on board either way).
Last step -> rebasing this PR one more time and the confusion and hiccups should have gone away by then.

Does this PR require a change in the driver versions?
No

I think we actually need a schema minor version bump. I'm going to do that in #975

I think we actually need a schema minor version bump. I'm going to do that in https://github.com/falcosecurity/libs/pull/975

Minor SCHEMA version was already bumped since last release in https://github.com/falcosecurity/libs/commit/dae8bc2f77205679fa6c443b500b72e3d5cc1311

LGTM label has been added.  Git tree hash: 3f534979c4f5549e3a6bf168f6d91b0da3703167

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, incertum
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 [Andreagit97,FedeDP,incertum]

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

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: Andreagit97, FedeDP, incertum
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 [Andreagit97,FedeDP,incertum]

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


Don't download already existing and up-to-date files.

Tested and found that files which do not need to be download are in fact not being downloaded.


Add errno getter for Android

Thanks!
@bors r+

:pushpin: Commit c9d1e39 has been approved by malbarbo

:hourglass: Testing commit c9d1e3923a6140263ce0252a9a6b16c916c5fb6b with merge 5cacf97831941c4985e1a814aed2a15879a5ae26...

:sunny: Test successful - status-appveyor, status-travis
Approved by: malbarbo
Pushing 5cacf97831941c4985e1a814aed2a15879a5ae26 to master...


Allow sync to be NULL when not needed

When using non-caching storage, the user can omit the sync function in struct lfs_config.
This would be more intuitive.
(After spending hours debugging why the program stuck after prog is called... I went back to the doc and see the descriptions about sync. It says "simply return 0" which I thought to be "simply 0". Is it just me?)

Alternatively, LFS_ASSERT(lfs->cfg->sync != NULL).

Alternatively, LFS_ASSERT(lfs->cfg->sync != NULL).

Thanks. Done in https://github.com/littlefs-project/littlefs/pull/1052

Hi @wangdongustc, thanks for the PR.
My preference is #1052 (asserting).
Eventually the config system needs a rework to better support compile-time configuration. If LFS_CFG_SYNC can be defined at compile time, it shouldn't be too difficult to make the default behavior a noop with an ifdef and without a runtime check.

Revised in https://github.com/littlefs-project/littlefs/pull/1052


igvm_c: Fix linker issues with sample and tests and clean up output

It was reported on https://github.com/coconut-svsm/svsm/pull/237 that on certain environments, the C unit tests and sample fail to build due to missing library dependencies. Also, the status of the build is hard to determine due to the amount of warnings generated by cbindgen. See the comment thread in that PR from @cclaudio.
The required list of libraries can be determined with the following command:
cargo rustc --verbose --features "igvm-c" --manifest-path=igvm/Cargo.toml -- --print=native-static-libs

This PR updates the Makefile to reflect the output of this command. In addition, the cbindgen -q flag is used to suppress warnings - it would be good to fix the warnings but this would require the generation of redundant additional output in the header files which is not ideal.
Finally, add a section to the README to describe how to install the library.

LGTM, I'll merge it.


Small update to OpenMaxHelpCommand

This should open the help Url specific to the Max version being used, falling back to 2018 if it cannot be found.

Hi Ross, this somehow slipped under my radar, sorry! Will take a look at it some time this week, thank you for your contribution.

Hey @cb109
Wondering if I could request that you merge your develop branch to master and push a release? I configured a new workstation recently with my usual Sublime setup and had to replicate your changes from this PR manually, as the Package Control version of Sublime3dsMax was never updated.
Thanks!

Yep that's worked thanks, Package Control updated this morning and I get the correct help for my Max version. There was one (non serious) syntax warning:
sublime3dsmax.py:142: SyntaxWarning: name 'mainwindow' is used prior to global declaration

Cool, thanks! Will fix that warning for the next release.


Minor fixes to release mode & refactoring

Refactor
Remove some unnecessary lines that add an init input to the corpus, but which will be overwritten further below.
Fix
Actually use the the release build when the release flag is set.

Oh nice finds! Please format the code and once it's green I'll merge :smile:


LPE errors and frequency issue Companion Link vs ESP8266 Mavros

Hi there,
I'm trying to control a quad in a Vicon environment. I have an Odroid XU4 connected to a pixhawk via FTDI cable through telem2 and USB.
I'm using firmware:  px4fmu-v2_lpe.px4
The issue is I'm struggling to get /mavros/local_position/pose at a reasonable rate to the Odroid.
The confusing part -
I've chosen Companion Link (921600 baud, 8N1) from the dropdown menu in QGC. This leads to ~30Hz  data frequency from FCU, but /mavros/local_position/pose is not changing with the vicon data.
Instead, I'm getting a constant stream of mocap timeout and mocap position init with the correct vicon pose data. However, /mavros/state is streaming the correct data.
When I choose ESP8266 (921600 baud, 8N1) (which I did out of desperation despite the previous setting being recommended), I get /mavros/local_position/pose CORRECT but at ~1Hz, and the output lpe reinit P(0,0) negative and very few, but still some mocap timeout warnings. /mavros/state output is correct here as well.
The USB to micro USB connection seems to work well, but I know that connection for data is discouraged.
In both cases Vicon data is being streamed at ~100Hz.
sigh I hope this was an adequate explanation. I'm at a big of a loss and thus struggling to describe what's happening. Any help is hugely appreciated :)

How does the Odroid get vicon data?

I think you need to publish to /mavros/mocap/pose. The topic /mavros/local_position/pose represents the published pose the UAV from the state estimators. If that is the case, let me further point out from my experience that the ESP8266 seems to struggle to work with streaming MOCAP data due to network latency issues. Suggestions have been made to reduce all other topic streams, modify streaming rates of data (requires 20hz I think), use regular telemetry or other wifi telemetry, or even play with UDP vs TCP (Multicasting or VRPN streaming). If you find a reasonable solution to use the ESP8266, please post what worked for you.

Hey, thanks for the input :)
Unfortunately, no specific solution regarding the ESP8266
In my case turned out to be a timing issue more than anything, but I still don't understand the results. I ended up using the telem2 port and using vrpn_client_ros onboard the odroid. Prior to that, I had been using vicon_bridge on a laptop set as ROS_MASTER on the same network (ie Vicon) as the odroid, allowing them to share the data. The problem was that the timestamp for ROS on the laptop and for the odroid differed, whereas vrpn allows for ignoring the time on the vicon server.


WIP: Easing Functions et al

Let's make the monolithic shader configurable to some extent.

[ ] Wrap the monolithic shader in a factory function
[ ] Teach the factory function some parameters

[ ] Billboard toggle (one less uniform!)
[ ] Animation functions for:

[ ] Scale
[ ] Alpha
[ ] ...?

Aaaah, what happened heeerrreee


VehicleDamage plugin

Adds a plugin that detects vehicle collisions and its intensity
Signed-off-by: Gonzalo de Pedro<EMAIL_ADDRESS>

@gonzodepedro , I updated this PR to:

Rename the plugin from VehicleDamage to KineticEnergyMonitor, which is a bit more generic.
Added an example world
Added an integration test.

23 - UNIT_Server_TEST (Timeout)


feat: Remove webhook flag

Description of your changes

Fixes #
I have:

[x] Run make reviewable to ensure this PR is ready for review.

How has this code been tested

Special notes for your reviewer

Removed validation for required webhook service name. We have a default webhook svc name fleetwebhook in options


Could not find org.springframework.ai:spring-ai-openai-spring-boot-starter

I tried to add spring-ai dependency in my gradle project.
But I faced the following issue.
dependencies {
	implementation 'org.springframework.ai:spring-ai-openai-spring-boot-starter'
}

Execution failed for task ':compileJava'.
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not find org.springframework.ai:spring-ai-openai-spring-boot-starter:.

The issue is the same, If I fixed version it as 0.8.0-SNAPSHOT.
Is it only possible in the maven project to add this dependency?
Did I miss something in the documentation?
Give me some advice, please.
Thank you.

I'm not using gradle much but given the 0.8.0 has not been released yet isn't above behaviour expected? E.g. you need to set the version to 0.8.0-SNAPSHOT?

I referenced this page.
The issue is the same when using version 0.7.1-SNAPSHOT.

For 0.7.1-SNAPSHOT, coordinates should be:
org.springframework.experimental.ai:spring-ai-openai-spring-boot-starter
Notice, experimental in the group ID. This won't be present in 0.8.0 release version, which is not yet released.

Sorry for the confusion.  I'm currently trying to make sure the docs are correct in this regard.  Indeed the big difference in that while the project was in the experimental github organization, we needed to use the word experimental as part of the groupID.  Now that the project moved out of the experimental github org, the word experimental was removed.  Here is the latest in the readme (at least covering OpenAI and Azure OpenAI).
Main Branch
The main branch has move to version 0.8.0-SNAPSHOT.
It will be unstable for a week or two.
Please use the 0.7.1-SNAPSHOT if you don't want to be on the bleeding edge.

Azure OpenAI

    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-azure-openai-spring-boot-starter</artifactId>
        <version>0.8.0-SNAPSHOT</version>
    </dependency>

OpenAI

    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
        <version>0.8.0-SNAPSHOT</version>
    </dependency>

0.7.1-SNAPSHOT

Azure OpenAI

    <dependency>
        <groupId>org.springframework.experimental.ai</groupId>
        <artifactId>spring-ai-azure-openai-spring-boot-starter</artifactId>
        <version>0.7.1-SNAPSHOT</version>
    </dependency>

OpenAI

    <dependency>
        <groupId>org.springframework.experimental.ai</groupId>
        <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
        <version>0.7.1-SNAPSHOT</version>
    </dependency>

Closing the issue for now, hope is all works for you.


Why your Website is Down?

bqworks.com why is your website is down?
Any changes to get up? Are you okay David?
I hope you will up the site soon.
Thanks

Hi,
I wanted to give up the business, so I put the plugins for free on bqworks.xyz. I had a difficult period. Now I'm trying to get back to maintaining the plugins.

Let us know how can we help you?
The community will help you in, whatever you needed bro.
Thanks
Faraz

I appreciate your kind intention and appreciative words, Faraz.
Best,
David

@davidghi Thats good to hear, you´ve done an awesome job here and I really hope you keep it up. Best wishes and regards, Michael

@davidghi - It's nice to see you are back! If you need any support to help keep this project alive let me know! I don't have much of a budget but I am willing to donate, link to your WP plugin (if it's still around), help with development, etc. Let me know. This script is the best out there!

AJ

Thank you both for the appreciative words! :)


feature: allow to set custom schema type

Thanks!

@atassis done!

I am giving full names for commit tags.
I will look at the code more precisely when I get well, and then think, what can we do to move on yup-ast package properly. I was thinking to rewrite this package by myself, though we are not going to use it in our company, still, it might be useful for someone else. Good job done by writing this on TS from scratch, btw 👍


charts: update volume related configuration and rbac

- with the latest node-manager changes, we also need to update here

That changes should be merged after https://github.com/harvester/node-manager/pull/10

Better to start from master branch and backport to the release one, and we need to bump version in the release branch.

Better to start from master branch and backport to the release one, and we need to bump version in the release branch.

Thanks for the reminder! Updated!

Need to include the CRD file https://github.com/harvester/node-manager/pull/10/files#diff-5270618f5e98c90c08716eeeb09acb482045eeeaaf2021fccdcea5b24f6b5479

Updated! Thanks for the reminder


Deleted payment methods come back after call to Adyen function

Describe the bug
After successfully deleting a previously saved payment method (Credit Card) from the user interface in SFCC, Adyen will repopulate the deleted payment methods
To Reproduce
Steps to reproduce the behavior:

Delete one or more saved payment methods (Credit Card) from a logged-in user account
Click 'Back to My Account' or visit any other route which adyen hooks into with the updateSavedCards() method (PaymentInstruments-SavePayment, Account-Show)
Inspecting the customer object at the beginning of the updateSavedCards() method should show the customers wallet reflects the deleted payment instruments. After getOneClickPaymentMethods() is called and new payment instruments are created in updateSavedCards() you should see that any deleted credit cards have returned to the customers wallet

Expected behavior
Deleted payment methods should not be recreated after their deletion
Screenshots

Starting from a state of 3 saved payment methods, delete all payments

After Deleting all payments, clicking “Back to My Account” shows no saved payment methods *the issue would also occur at this point if we weren't replacing the “Account-Show” route entirely in our controller, as adyen also updates all saved cards on the account-show route

Click Add New Payment Method and re-add the card ending in ‘1111’

Adyen’s savePayment method will prepend to the PaymentInstruments-SavePayment route and call the “updateSavedCards” function. If you capture the customer object at this moment, you’ll see that their wallet only contains the one pending payment method being added

The ‘updateSavedCards’ function deletes all existing saved cards and gets the ones to add via the ‘getOneClickPaymentMethods’ function. When you capture the state of it’s return value, you’ll see it contains all the cards previously removed.

Back in ‘updateSavedCards’ you’ll see the credit cards being added contain the ones that were previously removed in this case the one ending in 0007

Desktop (please complete the following information):

OS: Windows 10
Browser: chrome
Version: SFRA 6.0.0, Adyen 21.2.0, SFCC 22.5

Hi @kyleruscigno,
Thanks for raising this issue and for elaborating on it to this extent.
This behavior should be fixed and we'll be looking into this as soon as possible.
Kind Regards,
Wouter
Adyen

@wboereboom  Any progress on this? We are having this issue as well

Hi @codyluth,
Unfortunately we have not had the opportunity to start developing a fix.
I will update this ticket as soon as we get the capacity to start working on this.
Kind Regards,
Wouter
Adyen

Just an update on this thread:
We have not been able to reproduce this issue on v22.1.0
Please let me know if this issue persists for you on this version so we can continue our investigation.
Kind Regards,
Wouter
Adyen

@wboereboom Thanks for getting back to us.  Our QA team re-tested and it seems we are still having this issue with our saved payment methods.  We are on v22.1.1 of the Adyen cartridge.

@codyluth the issue is fixed here: https://github.com/Adyen/adyen-salesforce-commerce-cloud/pull/811

@lemonxtt Thanks Lemonxtt.
I figured out that was the issue last month while working on an unrelated issue we were having. I forgot to update this thread with the info I had found, but it seems I didn't need too.
I am glad it will be fixed for the next cartridge update!


Add support for twitter:image

And the other relate attributes like twitter:image:alt. I know this isn't necessary because most platforms use opengraph and twitter interchangeably, but it's important for completions sake.

@edazpotato Yeah, I thought about this while implementing it and decided to go with the minimal set for now. But I don't have strong feelings about this one way or the other, so we can add it. In the meantime, if you already want to set it, you can use extend.meta to do so

Thanks! I'll use extend.meta until this gets implemented

Any updates on this?


Adds support for Globally-configurable options.

Built on top of https://github.com/quantopian/qgrid/pull/23.
Adds some documentation and two new public API methods: set_defaults and set_js_option.
set_defaults accepts all the same optional parameters as show_grid, and any values passed passed will be used as defaults to future show_grid calls.  This includes a new parameter, js_options, a dictionary of options that's JSON-formatted and templated into our generated html/javascript.
set_js_option allows users to override single Slickgrid options without having to re-copy the existing ones.
@snth I took most of what you had already implemented and made it so that you can globally configure all SlickGrid instances for a given session.  This would also pave the way for allowing reliable configuration of notebook base URLs.
Can you confirm that this still solves the issues that were being addressed in #23?

@ssanderson looks great, thanks for doing this.  I tried this locally and it works well other than the one Python 3 compatibility issue I commented on.
I don't feel strongly either way on the naming, but I have a slight preference for grid_options because I think @snth is right that we'll want to add column options soon (and we'll want to call those column_options).