Partial XHR polyfull for Node.js

This is a continuation of #6454 with some minor cleanup and additions.

CC @jimmyangel this will be in the May 1st release.

@mramato are you going to add @jimmyangel  to CONTRIBUTORS.md?

Hi @hpinkos @mramato, I can work on a couple of tests but could you please tell me where to plug them in so that they executed under nodejs (as opposed to a browser)?

Hi @hpinkos @mramato, I can work on a couple of tests but could you please tell me where to plug them in so that they executed under nodejs (as opposed to a browser)?

Thanks for the offer, but we actually don't have any Node unit tests at this time, so there's no where for you to put them.  We want to have them eventually, but the plan is to figure out how to leverage our existing tests in node rather than have a separate set of node-specific tests.

@mramato are you going to add @jimmyangel to CONTRIBUTORS.md?

Sorry, I thought he was already in there but didn't check, I'll add him

Thanks for the offer, but we actually don't have any Node unit tests at this time, so there's no where for you to put them. We want to have them eventually, but the plan is to figure out how to leverage our existing tests in node rather than have a separate set of node-specific tests.

Ok. FYI, I have created a package that uses sampleTerrain in node as a utility (and library) to add elevation to arbitrary GeoJSON data. It includes a few Jasmine tests that end up exercising the XHR functionality here. You could potential reuse, or simply add a command line invocation with a couple of test files. Just let me know if I can help.


fix skypilot jobs failing on VMs (sky bumped to 0.6.0)

Describe changes
I bumped the skypilot integration to use the latest 0.6.0 version which solves a bug where the jobs don't run on the VM, leading to empty DAGs on the ZenML Dashboard.
Testing
I tested this PR on the release/0.58.2 branch and it worked as expected. I haven't tested this based on develop and will find a 0.60.0 tenant to test this on.
Pre-requisites
Please ensure you have done the following:

[ ] I have read the CONTRIBUTING.md document.
[ ] If my change requires a change to docs, I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] I have based my new branch on develop and the open PR is targeting develop. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.
[ ] If my changes require changes to the dashboard, these changes are communicated/requested.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Other (add details above)

@htahir1 good catch. updated the docs and tested on 0.60.0. will merge as soon as the slow ci passes


[BUG] Tags with '#' are not displayed correctly

Describe the bug 描述你遇到的错误
I tried to use C# as a tag for a post.
Frontmatter:
tags:
  - 'C#'
  - '.NET'
  - Patterns

On the "tags" page, everything works fine, but on content itself, the tag is missing in the footer:

The problem exists regardless of enclosing the tag in ' or not. It seems like the # character is triggering this behavior.
Expected behavior 期待的行为
No response
Screenshots 屏幕截图
No response
Build Environment 构建环境
No response
Preview Environment 预览环境
No response
Additional Information 补充信息
No response

It failed here
https://github.com/HEIGE-PCloud/DoIt/blob/ff904e9aae3bca25b464bb4e8de80da39ff1da3a/layouts/posts/single.html#L58
the url needs to be escaped before passing to urlize.
I don't know what's the reason behind it, but the taxonomy handling code looks really ugly.
To fix it, change that line to
{{- $category := partialCached "function/path.html" (urlquery .) (urlquery .) | printf "/categories/%v" | $.Site.GetPage -}}

but I am inclined to refactor the section entirely.

Thanks for the fast reply! I'll happily wait for the refactoring 🙂 Its probably not the most important bug anyways.

Turned out the refactoring is non-trivial. I've pushed a fix for this, the refactoring can be tracked and implemented separately.

Thank you @HEIGE-PCloud !


[Bug] alarm test bug fixed

[Bug] alarm test bug fixed
What changes were proposed in this pull request
Issue Number: close #xxx

Brief change log

Verifying this change

This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:

Does this pull request potentially affect one of the following parts

Dependencies (does it add or upgrade a dependency): no

Could you add som background? I don't know why need to change these code.

Could you add som background? I don't know why need to change these code.

you can see: AlertServiceImpl line 81 for more detail.


Error at startup

Error at startup. Everything works without RED4ext.

That issue is shown by a plugin, make sure you have everything up to date.


Weird forced formatting compatibility with prettier on "WorkspaceWatcher:onWillSaveTextDocument"

Please select the area your bug applies to. (Multiple selections are Possible. You can leave blank if you're not sure.)

[ ] Workspace.  VSCode workspace, vaults, Intellisense/autocomplete, Dendron settings
[ ] Lookup.  Dendron's Lookup Command
[ ] Views.  Dendron Preview, Tree View, Side Panels in the UI
[ ] Schema.  Dendron Schemas
[ ] Pod.  Data import from / export to Dendron
[ ] Publish.  External Site Publish
[x] Markdown.  Markdown features, such as syntax support and features

Describe the bug
Weird forced formatting with prettier on opening command palette and losing focus of VS Code. (It seems losing focus on editor triggers the format)
To Reproduce
Steps to reproduce the behavior:

Install and enable prettier , set it as default formatter of markdown (won't trigger this bug if not)
Go to any markdown file
Add some blank lines at the end of file
Open Command palette with default hotkey F1 or cmd + P
The blank lines disappears
Test with other "incorrect" markdown syntax like starting a line with space  + dash -

Expected behavior
Not format the markdown on opening command palette.
Screenshots

Desktop (please complete the following information)

OS: iOS
Versions

Dendron Extension: 0.116
VS Code version: 1.72.2

Additional context
I tested disabling all markdowns , but vscode "extension bisect" located the problem to prettier for some reason. When I tried to produce an MRE with prettier, in another VSCode instance, the bug disappeared. And I manually located to Dendron + prettier. It only happens when you have both extensions enabled.
Dendron Log file
Please attach the output of > Dendron:Dev: Open Logs here
{"level":30,"time":1667085527091,"pid":58709,"hostname":"Pablo-LIONs-Mac-Studio.home","name":"dendron","ctx":"WindowWatcher:onDidChangeVisibleTextEditors","editorPaths":[]}
{"level":30,"time":1667085527091,"pid":58709,"hostname":"Pablo-LIONs-Mac-Studio.home","name":"dendron","ctx":"refreshBacklinksChangeActiveTextEditor"}
{"level":30,"time":1667085527093,"pid":58709,"hostname":"Pablo-LIONs-Mac-Studio.home","name":"dendron","ctx":"WindowWatcher:onDidChangeVisibleTextEditors","editorPaths":["/Users/pablo/test.md"]}
{"level":30,"time":1667085527211,"pid":58709,"hostname":"Pablo-LIONs-Mac-Studio.home","name":"dendron","ctx":"refreshBacklinksChangeActiveTextEditor"}
{"level":30,"time":1667085533536,"pid":58709,"hostname":"Pablo-LIONs-Mac-Studio.home","name":"dendron","ctx":"WorkspaceWatcher:onWillSaveTextDocument","url":"/Users/pablo/test.md","reason":"FocusOut","msg":"enter"}

Thank you for the report.
Do you have any VSCode setting that automatically saves documents on focus change?
That will cause a save to trigger, and prettier will automatically format the markdown at this point.
Dendron will not try to format the document on save. On save, Dendron on ly updates the metadata of the note (i.e. updated timestamp)

When I tried to produce an MRE with prettier, in another VSCode instance, the bug disappeared.

Can you also check if in this instance you don't have VSCode set to automatically save? and that if you enable it, it happens without enabling Dendron?

I tested in another window without dendron and it didn't happen. But yea I had configured auto-save on losing focus. I've wanted to test your suggestion but I always forget it... I'll do it later today or tomorrow.

Hi @hikchoi , I've got a bad news 😂 I just checked that I have auto save set as "off" .. for this workspace (I guess by dendron?) Which makes I understand even this issue less...


Font size in the Picker Date-Time causes overflow problems in small screens

Framework7 version: 3.6.5 and 4.0.0 beta 29
Platform and Target: iOS and Android (Read below)

Describe the bug
The problem occurs with the iOS theme on screens with dimensions like the iPhone SE and the iPhone 8 and with the MD theme on screens with dimensions like the iPhone SE.
To Reproduce
View the Picker page in Kitchen Sink example from the framework7.io site with devices with this screen size.
Screenshots

This solution seems to work with both v3 and v4 on screens with dimensions like the iPhone SE and the iPhone 8:
@media (max-width: 375px) and (orientation: portrait) {
	.picker-columns {
		font-size: 20px !important;
	}
}

@media (max-width: 320px) and (orientation: portrait) {
	.picker-columns {
		font-size: 16px !important;
	}
}


Blank screen issue with ViewPager2

Hi guys
I have an issue with displaying pdf files with ViewPager2
With ViewPager it was working without any issue.
Now I have 2 fragments. The logic is very simple
I have 1 fragment in which I pass 2 different parameters (paths).
Then depending on the key that inside the Bundle I run a specific flow
Everything was doing in inactivity created
The number of pages is 2.
In the first binding the first page is generated. I could see the right information
Then I swipe to the second page. The onCreateView method is called and I can see the right information for the second page too.
When I bind the second page - the first fragment is still alive cause the onDestroyView wasn't called.
Right now I'm on the second page and want to swipe to the first one.
Swiping to the first one and noticing the white screen instead of information that was bind from the beginning. The onDestroyView wasn't called for the second fragment too.
Swiping to the page and see that there is a white screen here too.
I also tested the onPageChange and onPageScroll listeners.
They are not sending any data after I want to see the same page for the second time.
For example - Page 1 - I'm receiving a data -> scroll to Page 2 - I'm receiving a data -> scroll to Page 1 -> white screen - I'm NOT receiving data.

Here is the link from another user related to this issue to:
https://stackoverflow.com/questions/62643982/why-is-my-pdfview-in-fragment-not-showing-properly-in-my-viewpager2-i-cant-see
If you need more info - let me know

This sounds like your moving forward and backwards between two page one page on each fragment ?
If thats the case redraw the fragment when it comes into view,
I would also be looking at stubs using this approach.

@edgarkhimich, i had the same issue, try to set
pager.offscreenPageLimit = 3 // The number of fragments which should be kept on either side of view pager

i have the same issue, we can set ViewPager2#setOffscreenPageLimit() the limit than 1 to avoid it, but it is not a best solution.

I am thinking what could be the cause for this issue, it does not even print any exception to the trace, in the above case total pages are hardly few, i need to load pdfs of more than 100+ pages, a single back attempt causes 2 forward/backward pages blank
Each page is isolated to render individual pages of pdf, whats the issue with viewpager, something is hidden here to be explored

I tried this:
pager.offscreenPageLimit = 3 // The number of fragments which should be kept on either side of view pager
But not work for me.
Is there any other way?
Please help if.
Thanks.


runtime: support memory hotplug via probe interface on aarch64

Description of problem
There are 2 phases in Memory Hotplug. 1) Physical Memory Hotplug phase. 2)  Logical Memory Hotplug phase.
The First phase is to communicate hardware/firmware and make/erase environment for hotplugged memory.
If firmware supports notification of connection of new memory to OS, this phase is triggered automatically. ACPI can notify this event. This also what kata supports, memory hotplug via acpi-driven.
But if not, there is another option, probe operation by hand.
And since memory hotplug via acpi is missing on qemu-system-aarch64, we hope to support the other probe solution.
the whole detailed info about probe interface could be found here.
This whole implementation of memory hotplug via probe interface is divided into two phases, the first is to check if guest kernel is capable of memory hot-add via probe interface, which is located at /sys/devices/system/memory/probe.
The second is let kata-agent tell guest kernel the physical address of new memory block.
echo start_address_of_new_memory > /sys/devices/system/memory/probe
Expected result
root@entos-thunderx2-desktop:~# docker run --runtime kata-runtime -it --rm -m 3G ubuntu
WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap.
root@9ebdb553ba9b:/# lsmem
RANGE                                 SIZE  STATE REMOVABLE     BLOCK
0x0000000040000000-0x00000000bfffffff   2G online        no       1-2
0x0000020000000000-0x00000200bfffffff   3G online        no 2048-2050

Memory block size:         1G
Total online memory:       5G
Total offline memory:      0B
root@9ebdb553ba9b:/# ls /sys/devices/system/memory/
auto_online_blocks  block_size_bytes  memory1  memory2  memory2048  memory2049  memory2050  power  probe  uevent

@Pennyzct ping, any updates? Thx. Is this waiting for review?

/zuul-recheck

Hi @Pennyzct - is this PR still alive/valid ?

Hi~ @grahamwhaley yes,yes,yes. So sorry for the long-time hanging up, I constantly got sidetracked.😭. since related agent/#443 commit has already been merged, i will dep ensure to include the change. update asap. ;)

Hi~ all. When I dep ensure -update github.com/kata-conatiners/agent, do i need to git add the files under vendor/? Since Gopkg.lock and Gopkg.toml is not enough, the travis ci is still failing.

Hi @Pennyzct - yes, you need to git add vendor/ after a dep ensure. I'll update the contributor guide as that isn't currently specified...

PR raised - https://github.com/kata-containers/community/pull/89.

@Pennyzct, @jodh-intel just because of curiosity, why are you using dep instead of go mod?

@umarcor - at this point, it may be mostly due to historical reasons - the kata, and forerunner, code bases have been around a few years now... I think go mod came in with golang 1.11 ?, and we still have our baseline golang supported version as 1.10.4 :-)
Now, if you'd like to propose a move to go mod, and submit a PR ;-) But, first probably best if it was discussed. /cc @sboeuf

Yes - at the time we introduced it, dep was the best tool available.

@umarcor @grahamwhaley @jodh-intel
I recently discussed this with @mcastelino and I think it is time for us to move to go modules. We need to open issues on every Kata repositories for this. And then let's start submit PRs.
@umarcor is it something you're interested in helping with?

/test

Hi @Pennyzct - the CI's are failing on this:
virtcontainers/kata_agent_test.go:262:32: cannot use g (type *gRPCProxy) as type "github.com/kata-containers/runtime/vendor/github.com/kata-containers/agent/protocols/grpc".AgentServiceServer in argument to "github.com/kata-containers/runtime/vendor/github.com/kata-containers/agent/protocols/grpc".RegisterAgentServiceServer:
	*gRPCProxy does not implement "github.com/kata-containers/runtime/vendor/github.com/kata-containers/agent/protocols/grpc".AgentServiceServer (missing MemHotplugByProbe method)
FAIL	github.com/kata-containers/runtime/virtcontainers [build failed]

It looks like you need to add a dummy implementation of MemHotplugByProbe() to virtcontainers/kata_agent_test.go.

/retest

02:33:23 time="2019-03-13T18:33:23Z" level=warning msg="Failed Maxval (59001.600000 < 66545.530000) for [memory-footprint-ksm]"
02:33:23 time="2019-03-13T18:33:23Z" level=warning msg="Check for [memory-footprint-ksm] failed [Failed]"
02:33:23 time="2019-03-13T18:33:23Z" level=warning msg=" with [[*F* memory-footprint-ksm 95.0% 118.4% 105.0% 10.0% 118.4% 118.4% 0.0% 0.0% 1]]"
02:33:23 time="2019-03-13T18:33:23Z" level=warning msg="Overall we failed"
02:33:23
02:33:23 Report Summary:
02:33:23 +-----+----------------------+-------+--------+--------+-------+--------+--------+-------+------+-----+
02:33:23 | P/F |         NAME         |  FLR  |  MEAN  |  CEIL  |  GAP  |  MIN   |  MAX   |  RNG  | COV  | ITS |
02:33:23 +-----+----------------------+-------+--------+--------+-------+--------+--------+-------+------+-----+
02:33:23 | P   | boot-times           | 95.0% | 100.8% | 105.0% | 10.0% | 95.3%  | 109.4% | 14.8% | 3.2% |  20 |
02:33:23 | P   | memory-footprint     | 95.0% | 100.3% | 105.0% | 10.0% | 100.3% | 100.3% | 0.0%  | 0.0% |   1 |
02:33:23 | *F* | memory-footprint-ksm | 95.0% | 118.4% | 105.0% | 10.0% | 118.4% | 118.4% | 0.0%  | 0.0% |   1 |
02:33:23 +-----+----------------------+-------+--------+--------+-------+--------+--------+-------+------+-----+
02:33:23 Fails: 1, Passes 2
02:33:23 Failed
02:33:23 checkmetrics FAILED (1)
02:33:23 restoring KSM settings

Hi~ @grahamwhaley @jodh-intel metrix ci failed. Do we need to re-trigger or just skip it?

Hi @Pennyzct - This PR is possibly being affected by the need to "reset" the metrics thresholds. If so, I think we can merge. Hoever, I've re-triggered to see how that compares to the last run...
/cc @chavafg.

Hi @Pennyzct any updates? Thx!

/test

Hi~ guys~ @kata-containers/runtime Do you remember this one? (I indeed totally forget it. 😓) I have already re-based. pls review~thanks. ;)

Hi~ @grahamwhaley @jodh-intel @devimc vsock CI is failing.
Running command '/usr/local/bin/kata-runtime [kata-runtime --log=/tmp/bundle160734754/log run --bundle=/tmp/bundle160734754 --console= --pid-file=/tmp/bundle160734754/pid --detach muijkDXHgC48j6oaHysi]'
command failed error 'exit status 1'
[kata-runtime --log=/tmp/bundle160734754/log run --bundle=/tmp/bundle160734754 --console= --pid-file=/tmp/bundle160734754/pid --detach muijkDXHgC48j6oaHysi]
Timeout: 120 seconds
Exit Code: 1
Stdout:
Stderr: Failed to check if grpc server is working: context deadline exceeded

FWIT, context deadline exceeded is related to this issue #1319, I also addressed a comment there about same error on ARM machine.
I had no clue why initrd CI machine failed. I will let you guys to decide to re-trigger or what~ ;)

@chavafg - that vsock issue is pretty old - did we fix/bypass it? If so, I wonder why we hit it again here?

@Pennyzct that error is not related to this pr, I'll take a look later,


Add link to project homepage

better than nothing, I think

On Thu, Nov 10, 2016 at 09:11:27AM -0800, Thomas Boerger wrote:

And what's up with the sdk file?

Pushed a link to the sdk with [gitea-page d9b02b8]

Done, linked to github.

LGTM

LGTM


MB_REGISTER_TYPE causes some excessive instantiations between fragments because of the different reference variations

MB_REGISTER_TYPE(5, MR::A<int> &)
MB_REGISTER_TYPE(6, MR::A<int> &&)
MB_REGISTER_TYPE(7, const MR::A<int> &)
MB_REGISTER_TYPE(8, MR::A<int>)

^ no good

Collapsing those now.


create_sql_aqent not working with AgentType.OPENAI_FUNCTIONS

System Info
Langchain version: ```langchain = "^0.0.236"````
Python 3.10.10
MacOSx 13.4.1 (c) (22F770820d)
Who can help?
@hwchase17 @agola11
Information

[ ] The official example notebooks/scripts
[X] My own modified scripts

Related Components

[X] LLMs/Chat Models
[ ] Embedding Models
[ ] Prompts / Prompt Templates / Prompt Selectors
[ ] Output Parsers
[ ] Document Loaders
[ ] Vector Stores / Retrievers
[ ] Memory
[ ] Agents / Agent Executors
[X] Tools / Toolkits
[ ] Chains
[ ] Callbacks/Tracing
[ ] Async

Reproduction
Mysql 5.7 db.
toolkit = SQLDatabaseToolkit(db=db, llm=OpenAI(temperature=0))

agent_executor = create_sql_agent(
    llm=ChatOpenAI(temperature=0, model="gpt-3.5-turbo-0613"),
    toolkit=toolkit,
    verbose=False,
    agent_type=AgentType.OPENAI_FUNCTIONS,
)

    response = agent_executor.run(question)

Error message:
none is not an allowed value (type=type_error.none.not_allowed)
Note: It does work with AgentType.ZERO_SHOT_REACT_DESCRIPTION
Expected behavior
I would expect a response from the agent
Observed:
none is not an allowed value (type=type_error.none.not_allowed)

I think you just suggested I do the same thing I'm doing. I don't see the difference.

Please update your langchain package. The issue has been resolved in the newer version.


no screen to generate account

Display a new screen after click on "generate new account", with fields:

account name (optional)
password
password confirmation

On click "Generate" send it to the Connector and display resulting account id on same screen and "done" button (returns to main screen)

Question about account management --
Is the goal to have everything managed by the node via IPC (web3.personal.newAccount) like Mist? It looks like we are using rpc("eth_accounts", []) to fetch a list of user accounts from the node, but from the Classic Wallet documentation it seems like the Connector will be storing account info.

I will return all account related info directly from connector instead of redirect these RPC calls to client (prity, geth). I work on that, it's not done.

ok thanks, just wanted to make sure i understood what was going on.

We have implemented simple mediator or a proxy, which main task to resend all RPC calls futher to client, just to have a working wallet prototype ;)
Related issue for emerald connector - No support for keystore files (UTC / JSON) encrypted with a passphrase

PR opened #19


🍱 Update assets URL

Blocked by https://github.com/ministryofjustice/modernisation-platform/pull/5504


[stdlib] Fix the example in LazySequenceProtocol docs.

I'm not sure this code ever worked, but this new version does. Also includes some style revisions to the surrounding text.

@swift-ci Please smoke test

@swift-ci Please Build Toolchain macOS Platform

macOS Toolchain
Download Toolchain
Git Sha - 3be83216754a731d2a90561479a759f8fcb14351
Install command
tar -zxf  swift-PR-24270-305-osx.tar.gz --directory ~/

@swift-ci Please smoke test

@swift-ci Please smoke test and merge

@swift-ci Please smoke test and merge


Add traefik and cert-manager to infra provision step

Currently traefik and cert-manager resources are created as initialization and preconditions of the k8ssandra-operator installation.
It was determined that having these included as part of the infrastructure foundation provisioning will better support the e2e script installations of k8ssandra.
The capability to install these as part of the k8ssandra installation will still be available, but optional through an EnableConfig setting.

In the latest branch, the ability to apply after provisioning or as a completely separate step is controlled with the enablement configuration flags.


ConnectionListener receives CLOSED event on reconnect

When the nats server is stopped (or the connection is lost) but then is started again, the ConnectionListener of the StreamingConnectionFactory receives a ConnectionListener.Events.CLOSED event after the Reconnected event.
This happens from version 2.2.0 and onward. On version 2.1.6 it doesn't happen and on reconnect only the Reconnected event is received.
Is this supposed to happen?

I will take a look

Hi, i'm running into the same issue. Did you find the time to look into it yet?

Ok, so i've investigated a bit further. The double disconnect also occurs when using just the jnats client. The "connection closed event" is specific to the streaming client though. See attached testcases to illustrate the example.
testcases.zip

The close event originates from this line of code: https://github.com/nats-io/stan.java/blob/master/src/main/java/io/nats/streaming/StreamingConnectionImpl.java#L401

I'm not sure if it is related or if it is a seprate issue, but it is what caused me to stumble upon this behavior in the first place, so that's why i'm adding it here.
If i add a publisher to the mix and restart NATS while both publisher and subscriber are connected and te publisher is sending messages the following happens:

The publisher keeps sending messages -> as expected
The log reflects that the subscriber has reconnected and resubscribed -> as expected
The subscriber message callback isn't called after anymore -> unexpected.

See the modified testcase:
NatsStreamingReconnectionTest.zip
Note To see this behavior i needed to downgrade to 2.1.6 of the streaming library because the latest version sends the unexpected close event after reconnecting.

I switched jobs recently so running behind on this, i will try to take a look this weekend.

i am pretty sure that this is related to the new ping behavior, i am not sure of the fix, but the close is happening because of a bad ping from during the disconnect or something

looking at the ping "error" we get - client has been replaced or is no longer registered - so the issue is maybe an outstanding ping or a valid ping that the server gets mad about because of the reconnect

@mvanderblom Are you running the NATS Streaming server with a persistent store? If not, the default being MEMORY, it is expected that when the server restart, since there is no state recovered, the reconnect would be rejected.

@kozlovic I was using the in-memory config. I've observed the behavior you describe. When running in memory, the streaming client disconnects after a restart of the server. When i'm running with file based storage, the client reconnects and resubscribes as expected.
I guess that solves my "bug" ;-) Thanks for helping out!
It might be helpfull to others to describe this behavior in documentation somewhere.
Don't know if it's already documented, but if so, i wasn't able to find it.
https://docs.nats.io/nats-streaming-server/configuring/persistence

@mvanderblom I submitted a PR for the doc here. Thanks for the feedback!

The doc PR has been merged and the change is now live. Closing this issue.


Relax dependencies requirements to be compatible with other libraries, like Solana

I'm working on a project which is using dydx-python and dydx-v3-python libraries.
Unfortunately, for both of them, they require the exact version of 2.22.0 of the requests library.
Because of that, I'm having a dependency conflict with the Solana library  which from the very beginning requires requests>=2.24.
So, how about we update the requirements.txt of these libraries (dydx-v3-python and dydx-python) to work with other versions of the requests as well? And maybe relax the other dependencies a little bit too?

Any updates on this? Im also having issues with Streamlit and Alpaca

Fixed, now allows requests>=2.22.0,<3.0.0


Unsaved LegalUser objects have incorrect person_type

>>> from mangopay.resources import LegalUser
>>> LegalUser().person_type
'NATURAL'

The result should be 'LEGAL' instead of 'NATURAL'.

Hello @Changaco,
Thanks for your feedback, we will fix it very soon, as it is a tiny but important mistake :)
Mickaël

Fixed by #128


Docker: Warning in grSoftVersion(): ...

When running GlycoDash in a Docker container, the following warning is shown in the console when switching from the data import tab to the spectra curation tab:
Warning in grSoftVersion() :
  unable to load shared object '/usr/local/lib/R/modules//R_X11.so':
  libXt.so.6: cannot open shared object file: No such file or directory

Not sure whether this is an issue. At first glance it does not seem to influence the results.

Seems to have been solved after creating a new Dockerfile.


publish<EMAIL_ADDRESS>

Requested by: @jjbayer
Merge target: (default)
Quick links:

View changes
View check runs

Assign the accepted label to this issue to approve the release.
Leave a comment containing #retract under this issue to retract the release (original issuer only).
Targets

[ ] pypi
[ ] sentry-pypi
[ ] gcs

Targets marked with a checkbox have already been executed.  Administrators can manually tick a checkbox to force craft to skip it.

#retract


Update thalamus

(This includes the Ultraliser change I made a different PR for)
This makes significant changes to the creation of placement-hints for the thalamus, in addition to adding more documentation on what is going on to create them. The new instructions are included in the docstring for the ThalamusAtlas class.
The only thing left to decide is where to (ideally permanently) store the handcut reticular meshes that are manually made in this process. The handcut meshes will need to be updated whenever there's a change to the thalamus annotation (I expect very few instances of this by the end of 2024, maybe only 1 or 2 times). However, if the thalamus annotation has not been changed, then the placement-hints can be freely regenerated using the handcut meshes whenever desired, e.g. whenever placement-hints for the entire atlas pipeline are generated.

Regarding the remaining issue of where to store the handcut meshes needed for the thalamus' placement-hints building, I chatted with @crisely09 and she agreed that the following is allowable:

Register the files as entities in an internal BBP-project on the Nexus
Put a link to the internal BBP resource on BBP's Nexus into the public code here on github (which would go in app/metadata/thalamus_metadata.json)

@mgeplf Would you be okay with this solution? This way our internal Atlas building process would still be able to access the files, but without adding raw data to the code.

@mgeplf Would you be okay with this solution? This way our internal Atlas building process would still be able to access the files, but without adding raw data to the code.

Fine w/ me.  How hard would it be to create some test data, so we can at least have an inkling it's working correctly.

 I'll probably make this change today, then leave as-is.
Also, Mike, I would say don't worry about this PR for now -- if you look at internal ticket DKE-1224, you'll see that we're going to start having the scientists build Docker images for their region-specific Atlas rules. It's not as clean as properly updating parts of the pipeline like this repo, not to mention avoiding the tests, but it will finally start getting the other circuits integrated into the Atlas build.

Codecov Report
Attention: 39 lines in your changes are missing coverage. Please review.

Comparison is base (11e099b) 79.91% compared to head (d183a67) 75.15%.

Files
Patch %
Lines

atlas_placement_hints/layered_atlas.py
15.21%
39 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #11      +/-   ##
==========================================
- Coverage   79.91%   75.15%   -4.76%
==========================================
  Files           9        9
  Lines         453      487      +34
==========================================
+ Hits          362      366       +4
- Misses         91      121      +30

Flag
Coverage Δ

pytest
75.15% <15.21%> (-4.76%)
:arrow_down:

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

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I've made all the changes I needed to make for the placement-hints to be successfully built, and verified/tested the output to be good, including using the appropriately-built Atlas pipeline inputs. I believe that all that remains is for it to pass the tests, which I don't know why it's not passing.

run tox -e format and push the changes made (also run tox -e lint to check it passes the lint CI, then check https://github.com/BlueBrain/atlas-placement-hints/actions/runs/8169361051/job/22333282867?pr=11 where it shows you a diff in a test

There is a tiny change I forgot to make (due to all the changes required for the Pipeline), so I will make that and then do the tox stuff you mentioned

I forgot to mention, to repro the error in the test, just do tox -e py3

Is there a particular configuration of BB5 modules I can use to build the test environment that tox needs? I've run into the issue I'm having before: despite loading the py-cgal-pybind module, any tox command I try to run in my install on BB5 tries to build a wheel for cgal-pybind. However, this always fails.
In order to build the tox environment on BB5, do I need to load separate modules that contain https://github.com/BlueBrain/cgal-pybind?tab=readme-ov-file#requirements ? I would think those libraries are present in the module for py-cgal-pybind, but loading that module doesn't solve the issue.
Alternatively, should I not be trying to run these tests on BB5? Do I need to instead run this on my local computer (and therefore need to be able to install cgal-pybind myself)?

ah yes, this is a pain, what I did is to comment the cgal line in setup.py, so tox does not try to install it. It is not really needed for the test I think

I've made the changes needed for passing tox -e format, but tox -e lint appears to fail at the pylint step, even though its output seems to only produce suggestions that look like warnings instead of errors to me. Do I need to make all the listed fixes, or is there a different reason it's failing? Here's the output from tox -e lint:
lint: commands[4]> pylint atlas_placement_hints
************* Module atlas_placement_hints.layered_atlas
atlas_placement_hints/layered_atlas.py:39:0: C0413: Import "import trimesh" should be placed at the top of the module (wrong-import-position)
atlas_placement_hints/layered_atlas.py:40:0: C0413: Import "from voxcell import VoxelData" should be placed at the top of the module (wrong-import-position)
atlas_placement_hints/layered_atlas.py:221:41: W0613: Unused argument 'hemisphere' (unused-argument)
atlas_placement_hints/layered_atlas.py:221:58: W0613: Unused argument 'thalamus_meshes_dir' (unused-argument)
atlas_placement_hints/layered_atlas.py:502:20: C0209: Formatting a regular string which could be an f-string (consider-using-f-string)
atlas_placement_hints/layered_atlas.py:507:8: R1722: Consider using 'sys.exit' instead (consider-using-sys-exit)
atlas_placement_hints/layered_atlas.py:563:12: R1722: Consider using 'sys.exit' instead (consider-using-sys-exit)
atlas_placement_hints/layered_atlas.py:580:16: C0209: Formatting a regular string which could be an f-string (consider-using-f-string)
atlas_placement_hints/layered_atlas.py:587:16: C0209: Formatting a regular string which could be an f-string (consider-using-f-string)
atlas_placement_hints/layered_atlas.py:598:16: C0209: Formatting a regular string which could be an f-string (consider-using-f-string)
atlas_placement_hints/layered_atlas.py:510:14: W0613: Unused argument 'layered_volume' (unused-argument)
atlas_placement_hints/layered_atlas.py:39:0: C0411: third party import "trimesh" should be placed before first party imports "atlas_placement_hints.distances.create_watertight_mesh.create_watertight_trimesh", "atlas_placement_hints.distances.distances_to_meshes.distances_from_voxels_to_meshes_wrt_dir", "atlas_placement_hints.utils.centroid_outfacing_mesh"  (wrong-import-order)
atlas_placement_hints/layered_atlas.py:40:0: C0411: third party import "voxcell.VoxelData" should be placed before first party imports "atlas_placement_hints.distances.create_watertight_mesh.create_watertight_trimesh", "atlas_placement_hints.distances.distances_to_meshes.distances_from_voxels_to_meshes_wrt_dir", "atlas_placement_hints.utils.centroid_outfacing_mesh"  (wrong-import-order)
atlas_placement_hints/layered_atlas.py:39:0: C0412: Imports from package trimesh are not grouped (ungrouped-imports)
atlas_placement_hints/layered_atlas.py:40:0: C0412: Imports from package voxcell are not grouped (ungrouped-imports)
************* Module atlas_placement_hints.app.placement_hints
atlas_placement_hints/app/placement_hints.py:339:0: R0913: Too many arguments (9/7) (too-many-arguments)
atlas_placement_hints/app/placement_hints.py:405:8: R1722: Consider using 'sys.exit' instead (consider-using-sys-exit)

------------------------------------------------------------------
Your code has been rated at 9.70/10 (previous run: 9.70/10, +0.00)

lint: exit 28 (13.85 seconds) /PATHREPLACEDHERE/> pylint atlas_placement_hints pid=28254
  lint: FAIL code 28 (18.89=setup[3.98]+cmd[0.22,0.22,0.40,0.21,13.85] seconds)
  evaluation failed :( (18.97 seconds)

I've tried to update tests/app/test_placement_hints.py to match the new workflow but I clearly don't know what I'm doing. The new workflow is described in atlas_placement_hints/layered_atlas.py::ThalamusAtlas. Basically, how the general thalamus testing should go is:

Run atlas-placement-hints thalamus with --create-uncut-thalamus-meshes-flag to create meshes, but NOT create placement-hints,
Perform the copying in tests/app/test_placement_hints.py::test_thalamus to "simulate" creation of hand-cut meshes, then
Run atlas-placement-hints thalamus again, but this time with --load-cut-thalamus-meshes-flag, again checking for an error exit code. This is the step that actually creates the placement-hints.

After step 3 has happened, then there should be a new placement_hints/distance_report.json that can work for the remaining tests. However, when I try to add the most recent code, I get simply an empty AssertionError message. Do I need to invoke a different runner or change something else? Apologies, I'm still relatively new at testing in Python and in general.
FAILED tests/app/test_placement_hints.py::test_thalamus - AssertionError:

To fix your tests, you have to modify the ThalamusMock here https://github.com/BlueBrain/atlas-placement-hints/blob/main/tests/placement_hints/mocking_tools.py#L196 so that it matches what you create with the updated code. Its hard to say what is diff without looking in details in what you did, but if you think its good, just adapt this Mock thing, and it should be good.

Okay, it will take me some time to go through this and update the tests then. I should be able to get to it within a few weeks, got a lot going on

Please allow the tests to run on the latest commit (don't cancel them please)

Darn, I was hoping that that small change could fix it. The main problem I'm having at this point is constructing a working test environment in the first place. Unfortunately, I believe I need additional help from someone at NSE like @mgeplf to figure this out. Even when I appear to install a working test venv (including cgal-pybind and ultraliser) on BB5, the tests on both this branch and even the main branch fail, and fail in similar ways. I think this means my issues are something to do with the environment, but I'm not sure. I'm going to try installing the test environment from scratch (on a linux), but I will likely need some help.

I can fix your tests a little later today or tomorrow, it does not look like a big deal, don't fight this too much, its not worth it haha

ok, @asoplata , tests fixed, you had to also change the region id in the other test file. I also ran format, so you can now see the lint errors in the last CI, you see quite a few due to your change in the main code. I'm not sure if what you did there could be accepted by NSE, you'll have to ping them maybe on slack to see if they have time to check it. I don't  have merge rights anyway on this repo.

Ah, to bypass cgal thing locally, just comment the cgal line in setup.py before you run tox, and module load it, so you have it for the tests that need it. But don't push the change in setup.py in your commit.

This should be merge-able now.

I believe this is a scientific change, don't know how to help here.

Which workflow?
The PR description reads "This makes significant changes to the creation of placement-hints for the thalamus", before approving and update the placement-hints in the Atlas pipeline I would like some scientific review of these new placement-hints.

@lecriste What does a scientific review entail? Do you want someone else to approve of the final changes on a scientific level?

Not necessarily. I'm just saying that before updating the Atlas pipeline to use this new code, it would be good to provide the consumer of placement hints (@eleftherioszisis and @mgeplf AFAIK) with this new version and ask for their feedback.

Sorry, I wasn't clear, the science is good, autin is world expert on that, and the result look quite reasonable to me. The only thing I'm wondering is if the option to save thalamus meshes (thalamus_meshes_dir) makes sense. I would not make it thalamus specific, but generic for all regions, but this should be done in another PR. Then, regardless of the scientific validity, I believe this PR should be reviewed anyway (as it has always been the case for NSE codes). Austin made some changes with typing, I'm not sure are the best, and ho also probably this save mesh option, but I'm not sure how to improve it, as I have not worked much on these codes, so I don't know the code quality you expect here.

Sorry, I wasn't clear, the science is good, autin is world expert on that, and the result look quite reasonable to me.

So it's OK to change the PH of the Thalamus region of these files to the values from this code?

Then, regardless of the scientific validity, I believe this PR should be reviewed anyway (as it has always been the case for NSE codes). Austin made some changes with typing, I'm not sure are the best, and ho also probably this save mesh option, but I'm not sure how to improve it, as I have not worked much on these codes, so I don't know the code quality you expect here.

I know less than you.


Replace LegacyMap with Map

Map sub-chapter still uses the depreciated LegacyMap type, updating the Mapping chapter with the type Map
Modify in other section using LegacyMap

I'll be happy to take care of this

Please can I be assigned to this issue

Hi @chachaleo Please can you assign this task to me so I can start working on it immediately.

This will be handled at once in #245


Suggestion: Commands to dump enchantment/potion names and IDs

We have commands to dump other things, so why not an enchantment dump? Something similar should be done for potions, too

https://github.com/jaredlll08/CraftTweaker/pull/282 provides a command to dump the potion names and ids

closed by PR


Expand server corpus

Started a rebuild of interop, to make sure it's not failing because of this pr.


How to support request post data by NSArray params

Alamofire.request("xxxx",method:.post,parameters:[key:value])
but I want to do this
Alamofire.request("xxxx",method:.post,parameters:['1','2','3','4'])
help me thanks!!

By default Alamofire doesn't support root arrays as parameters, and neither do most parameter encodings. Most require keyed types of some kind. However, you could write you own request method that allows arrays, and write a parameter encoding system that supports them as well. It would be something you'd have to build yourself.

ok  thank you  very much 😆

While Alamofire’s convenience API and parameter encoders don’t support such use, you can always create your URLRequests yourself and use Alamofire to perform them. That way you can take advantage of the rest of Alamofire’s features while having full control over your request creation.


Add comparison to SimpleX chat

Add a comparison to https://simplex.chat/ in the FAQ section.

As stated in the Compare page the Comparison list is not maintained much anymore because its to much effort and updates to often. This is not to say that it never will but maybe you can better understand why to use the Berty messenger when reading the Compare page.

You can have a look at it, it is available here and you can even contribute to it. But to be honest, it’s particularly hard to be extensive, tricky to be objective, and awful to maintain.


updated packages to fix local setup and vulnerabilities

Description
Few of the packages were old and hence were creating problem while running npm install command. I have updated the package to fix the issue and also it fixes few of the vulnerabilities.
I have created a card in backlog to prioritise and fix rest of the vulnerabilities.
https://issues.redhat.com/browse/RHIROS-904
Steps to test

Checkout the branch
Remove node modules folder
Run npm install command, it should install the mentioned packages successfully
Run npm start command and check if frontend is working properly.

Codecov Report
Base: 22.89% // Head: 22.89% // No change to project coverage :thumbsup:

Coverage data is based on head (b5c998a) compared to base (8547dec).
Patch has no changes to coverable lines.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #148   +/-   ##
=======================================
  Coverage   22.89%   22.89%
=======================================
  Files          48       48
  Lines         913      913
  Branches      164      164
=======================================
  Hits          209      209
  Misses        658      658
  Partials       46       46

Impacted Files
Coverage Δ

...c/Components/SystemDetail/SystemRecommendations.js
0.00% <ø> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Missing parent "GO:0140423    JSON effector-mediated suppression of pattern-triggered immunity'

I'm back on PHI base today.
This term:
GO:0140423   effector-mediated suppression of pattern-triggered immunity
still doesn't seem to be a descendant of
GO:0140404   effector-mediated modulation of host innate immune response by symbiont
I'm sure we keep adding this?

Hi,
I added the missing parent to the parent
GO:0140403 effector-mediated suppression of host innate immune response by symbiont
Thanks, Pascale


[release] Kelp v3.1.3

This is v3.1.3 because I made a release before I should have. Whoops.

Sidenote: NPM publish access will be revoked from everybody. NPM publish will only go to GitHub actions and publish on [release] pr's.

Queued to merge.


WIP: feat: managed mutation webhook

This webhook adds a managed label to each resource which is created or updated in a capsule namespace. This is required for the capsule-proxy to query any namespaced resource.
Helps with issues:

https://github.com/clastix/capsule-proxy/issues/303
https://github.com/clastix/capsule-proxy/issues/185

I have added an enabled switch for the webhook in the chart, since it brings quiet some workload and thee might be users, which don't use the capsule-proxy at all.
What this implementation does not respect, is the handling of existing resources. I would probably just add a simple script to the documentation, which adds the label to all existing resources in all tenant namespaces.

Implementation is moved entirely to capsule-proxy.


Regression on vite 4.3 build when resolving packages

Describe the bug
I am updating from vite 4.2.1 to 4.3 beta and I expect my build command to work the same without problem. After trying different 4.3 beta versions, the issue seems to be introduced between 4.2.1 and 4.3.0-beta.0.
Reproduction
https://stackblitz.com/edit/vitejs-vite-ehaytj?file=package.json&terminal=dev
Steps to reproduce

Download the reproduction
Setup the package manager using $ yarn set version berry
Run $ yarn build to build the release

System Info
System:
    OS: Linux 5.19 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (8) x64 Intel(R) Core(TM) i7-3632QM CPU @ 2.20GHz
    Memory: 208.00 MB / 7.22 GB
    Container: Yes
    Shell: 5.1.16 - /bin/bash
  Binaries:
    Node: 18.12.0 - /usr/bin/node
    Yarn: 3.5.0 - /usr/bin/yarn
    npm: 8.19.2 - /usr/bin/npm
  Browsers:
    Firefox: 111.0.1

Used Package Manager
yarn
Logs
transforming (958) .yarn/__virtual__/open-vector-editor-virtual-69cfb0ac1b/[plugin:vite:resolve] Module "string_decoder" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/__virtual__/bio-parsers-virtual-4a95e6c22e/0/cache/bio-parsers-npm-9.3.6-e8a2307998-0082495ed0.zip/node_modules/bio-parsers/lib/parsers/snapgeneToJson.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "string_decoder" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/__virtual__/bio-parsers-virtual-4a95e6c22e/0/cache/bio-parsers-npm-9.3.6-e8a2307998-0082495ed0.zip/node_modules/bio-parsers/lib/parsers/snapgeneToJson.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (1658) .yarn/__virtual__/@blueprintjs-core-virtual-401391ae3f/[plugin:vite:resolve] Module "path" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/vfile-npm-2.3.0-0781febdcc-59f1be789f.zip/node_modules/vfile/core.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "path" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/vfile-npm-2.3.0-0781febdcc-59f1be789f.zip/node_modules/vfile/core.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (1998) .yarn/cache/unist-util-stringify-position-npm-1.1.2-df0[plugin:vite:resolve] Module "path" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/replace-ext-npm-1.0.0-5d4ecb34ac-123e5c2804.zip/node_modules/replace-ext/index.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "path" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/replace-ext-npm-1.0.0-5d4ecb34ac-123e5c2804.zip/node_modules/replace-ext/index.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (2173) .yarn/cache/lodash-npm-4.17.21-6382451519-eb835a2e51.zi[plugin:vite:resolve] Module "string_decoder" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/<EMAIL_ADDRESS>See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "string_decoder" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/<EMAIL_ADDRESS>See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (2459) .yarn/cache/lodash-npm-4.17.21-6382451519-eb835a2e51.zi[plugin:vite:resolve] Module "events" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/stream-browserify-npm-3.0.0-4c0bd97245-4c47ef64d6.zip/node_modules/stream-browserify/index.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "events" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/stream-browserify-npm-3.0.0-4c0bd97245-4c47ef64d6.zip/node_modules/stream-browserify/index.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (2590) .yarn/unplugged/core-js-npm-2.6.12-0b93d77d31/node_modu[plugin:vite:resolve] Module "buffer" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/_stream_writable.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "buffer" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/_stream_writable.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (2672) .yarn/cache/lodash-es-npm-4.17.21-b45832dfce-05cbffad6e[plugin:vite:resolve] Module "events" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/_stream_readable.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "events" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/_stream_readable.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
[plugin:vite:resolve] Module "buffer" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/_stream_readable.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "buffer" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/_stream_readable.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (2709) .yarn/cache/lodash-es-npm-4.17.21-b45832dfce-05cbffad6e"buffer/" is imported by "buffer/?commonjs-external", but could not be resolved – treating it as an external dependency.
transforming (2805) .yarn/cache/lodash-npm-4.17.21-6382451519-eb835a2e51.zi[plugin:vite:resolve] Module "events" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/internal/streams/stream-browser.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "events" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/internal/streams/stream-browser.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (2882) .yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6[plugin:vite:resolve] Module "buffer" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/internal/streams/buffer_list.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
Module "buffer" has been externalized for browser compatibility, imported by "/home/motion/Developer/vite43/.yarn/cache/readable-stream-npm-3.6.2-d2a6069158-bdcbe6c22e.zip/node_modules/readable-stream/lib/internal/streams/buffer_list.js". See http://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (3017) .yarn/cache/lodash-es-npm-4.17.21-b45832dfce-05cbffad6e"string_decoder/" is imported by "string_decoder/?commonjs-external", but could not be resolved – treating it as an external dependency.
transforming (3416<EMAIL_ADDRESS>of eval in ".yarn/cache/bluebird-npm-3.7.2-6a54136ee3-869417503c.zip/node_modules/bluebird/js/browser/bluebird.js" is strongly discouraged as it poses security risks and may cause issues with minification.
✓ 3416 modules transformed.
✓ built in 2m 59s
"StringDecoder" is not exported by "__vite-browser-external", imported by ".yarn/cache/<EMAIL_ADDRESS>file: /home/motion/Developer/vite43/.yarn/cache/@gmod-gff-npm-1.3.0-f29c3629ad-c5df33d182.zip/node_modules/@gmod/gff/esm/api.js:2:9
1: import { Transform } from 'stream';
2: import { StringDecoder as Decoder } from 'string_decoder';
            ^
3: import Parser from './parse';
4: import { formatItem, formatSequence, } from './util';
error during build:
RollupError: "StringDecoder" is not exported by "__vite-browser-external", imported by ".yarn/cache/<EMAIL_ADDRESS>    at error (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:2125:30)
    at Module.error (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:13334:16)
    at Module.traceVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:13719:29)
    at ModuleScope.findVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:12234:39)
    at ChildScope.findVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:6974:38)
    at ClassBodyScope.findVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:6974:38)
    at ChildScope.findVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:6974:38)
    at FunctionScope.findVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:6974:38)
    at ChildScope.findVariable (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:6974:38)
    at Identifier.bind (file:///home/motion/Developer/vite43/.yarn/cache/rollup-npm-3.20.4-c260b8a18f-6b80ca4c45.zip/node_modules/rollup/dist/es/shared/node-entry.js:8124:40)

Validations

[X] Follow our Code of Conduct
[X] Read the Contributing Guidelines.
[X] Read the docs.
[X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
[X] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
[X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
[X] The provided reproduction is a minimal reproducible example of the bug.

It looks like the PR that introduced the regression is:

https://github.com/vitejs/vite/pull/12441

@smeng9 the reproduction you shared is a bit noisy, it would be helpful if you could try to create a smaller one to help us debug the issue.


Use reco::formulaEvaluator instead of TFormula?

From what I understood in CMSSW the reco::formulaEvaluator (from https://github.com/cms-sw/cmssw/pull/11516 ) is preferred because it is thread-safe and faster than TFormula, and it's easy to include (almost standalone, and minimal public interface), so it may also be the better choice here (I'm using it in bamboo because the jet corrector classes rely on it, so I can prepare a PR - in the long run it may be worth asking for it to be released outside CMSSW if this option is taken).

Good point. I was thinking about the consistency of JSON-format evaluator and the CMSSW-code in that context as well. There were some issues in the past with reco::formulaEvaluator not giving the same result as TFormula, e.g. https://github.com/cms-sw/cmssw/issues/21851
So in any case for deliverables such as JEC the output of the JSON formula evaluator and the CMSSW-modules need to be validated against each other, no matter what the choice for the JSON formula evaluator.

Good point. I was thinking about the consistency of JSON-format evaluator and the CMSSW-code in that context as well. There were some issues in the past with reco::formulaEvaluator not giving the same result as TFormula, e.g. https://github.com/cms-sw/cmssw/issues/21851
So in any case for deliverables such as JEC the output of the JSON formula evaluator and the CMSSW-modules need to be validated against each other, no matter what the choice for the JSON formula evaluator.

Let me paste the readme section here for convenience:

Formula support is currently planned via linking to ROOT libraries and using TFormula,
however if possible we would like to avoid this external dependency. One alternative could
be using the boost.spirit parser with some reasonable grammar--
this is the approach used for CMSSW's expression parser.
There are also various C++ formula parsers such as ExprTk,
and the python bindings may be able to call into numexpr,
though, due to the tree-like structure of the corrections, it may prove difficult to exploit vectorization
at levels other than the entrypoint.

At least that answers the question I had in https://github.com/nsmith-/correctionlib/blob/51331ef9f101ede5ba830fc0fab3756c7030432f/src/correction.cc#L65 so indeed now there are at least three reasons to drop TFormula:

ROOT dependency
Slow to compile
Not thread-safe

It would be interesting to know how fast reco::formulaEvaluator compiles (or probably rather it just is parsed into an AST). Perhaps @Dr15Jones can provide some input. One thing that I would like is to have a grammar defined, like how the reco::ExpressionEvaluator grammar is. The advantage is then we can also validate the grammar from the python side with something like lark. The other advantage is it may allow easy construction of parsers in other languages, e.g. javascript for a correction viewer web UI

Let me paste the readme section here for convenience:

Formula support is currently planned via linking to ROOT libraries and using TFormula,
however if possible we would like to avoid this external dependency. One alternative could
be using the boost.spirit parser with some reasonable grammar--
this is the approach used for CMSSW's expression parser.
There are also various C++ formula parsers such as ExprTk,
and the python bindings may be able to call into numexpr,
though, due to the tree-like structure of the corrections, it may prove difficult to exploit vectorization
at levels other than the entrypoint.

At least that answers the question I had in https://github.com/nsmith-/correctionlib/blob/51331ef9f101ede5ba830fc0fab3756c7030432f/src/correction.cc#L65 so indeed now there are at least three reasons to drop TFormula:

ROOT dependency
Slow to compile
Not thread-safe

It would be interesting to know how fast reco::formulaEvaluator compiles (or probably rather it just is parsed into an AST). Perhaps @Dr15Jones can provide some input. One thing that I would like is to have a grammar defined, like how the reco::ExpressionEvaluator grammar is. The advantage is then we can also validate the grammar from the python side with something like lark. The other advantage is it may allow easy construction of parsers in other languages, e.g. javascript for a correction viewer web UI


[PALOMABOT] AAVE stable yield chaser bot UI

Designs for new Bot AAVE stable yield chaser bot.
Figma: https://www.figma.com/design/6DYR6QFkucGd1bsOILr7V0/Paloma-Bot?node-id=3590-662813&t=vSjyX5bWAL41ShhO-4
Epic: https://www.notion.so/volumefi/EPIC-08-16-24-AAVE-stable-yield-chaser-vault-d18d0f4c6d334ef6a9d99bd5628d79f8?pvs=4

[ ] Current Stablecoin with the highest APY + token image

[ ] User select Chain. Available only in Ethereum and Optimism

[ ] User selects up to 5 deposit tokens.

[ ] My Bots: The user sees the following data: Current Stablecoin, Current APY, Deposit Amount, Deposit Token, Bot Earnings, and Status.
My Bots Designs: https://www.figma.com/design/6DYR6QFkucGd1bsOILr7V0/Paloma-Bot?node-id=3588-662628&t=vSjyX5bWAL41ShhO-4

[ ] Add Bot to Curve Bots as well. Designs: https://www.figma.com/design/vLd6scwseZilfUZJXI6oRQ/Curve-Bots?node-id=1058-15356&t=9OYwNa18WFFGmeWo-4

@webelf101 we'd like to use this on Optimism. Will you confirm that we can usse the back-end to choose OP chain for this?

Close as shipped.


JWT Token generation - still get 401's

First of all, fabulous package.  Just found it thanks to @ardalis and I'm moving my project to it.
This post will hopefully be helpful.  I have a workaround in place and there is no urgency to this issue.

I am having some problems with security.  The tokens are generated just fine and the claims are there, but when I use the bearer token to access an endpoint, it always comes back with a 401.
Using www.jwt.io I also noticed that it would not verify the signature unless I specified the HS256 algorithm specifically during token creation.
I am pulling the signing key from the same spot in the config for both aspects, I've stripped the code down until there's almost nothing going on.
What's interesting is the sample code from Steve's Modular Monolith course is identical to mine and works in his project that I downloaded to my machine.
When I copy the code to my project it fails.
For the life of me I can't find the problem.  It has been all day, so I had to move on.  I am successfully issuing tokens and protecting endpoints with the standard asp.net core shown below.
I only leave this here in case someone else has the same problem and you need more information on it.  Feel free to reach out if I can help.
builder.Services.AddAuthentication(options =>
{
  options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
  options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
  options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
}).AddJwtBearer(o =>
{
  o.TokenValidationParameters = new TokenValidationParameters
  {
    ValidIssuer = authOptions.Issuer,
    ValidAudience = authOptions.Audience,
    IssuerSigningKey = new SymmetricSecurityKey
      (Encoding.UTF8.GetBytes(authOptions.JwtSecret)),
    ValidateIssuer = true,
    ValidateAudience = true,
    ValidateLifetime = true,
    ValidateIssuerSigningKey = true
  };
});
builder.Services
  .AddAuthorization()
  .AddFastEndpoints()
  .SwaggerDocument();

And for token generation:
  private static string BuildJwtToken(AuthOptions options, IEnumerable<Claim> claims)
  {
    var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes(options.JwtSecret));
    var creds = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);
    var issuer = options.Issuer;
    var audience = options.Audience;
    var jwtValidity = DateTime.Now.AddMinutes(Convert.ToDouble(options.AccessTokenExpiresMinutes));
    var token = new JwtSecurityToken(issuer, audience, expires: jwtValidity, claims: claims, signingCredentials: creds);
    return new JwtSecurityTokenHandler().WriteToken(token);
  }

I am using an AuthOptions class like this:
public class AuthOptions()
{
  [Required]
  public required string JwtSecret { get; init; }
  public required double AccessTokenExpiresMinutes { get; init; } = 60;
  public required double RefreshTokenLifetimeDays { get; init; } = 365;
  public required double RefreshTokenExpiresHours { get; init; } = 24;
  public required string Issuer { get; init; } = "https://www.coolstuff.io";
  public required string Audience { get; init; } = "https://www.coolstuff.io";
}

thanks for the info. as well as the monthly sponsorship. greatly appreciated 🙏
FE provides "easier on the eye" abstractions for both setting up the middleware and creating jwt auth.
bld.Services.AddAuthenticationJwtBearer(
       s =>
       {
           s.SigningKey = "signing key";
           s.SigningStyle = TokenSigningStyle.Symmetric; //not necessary as it's the default value
       },
       b =>
       {
           b.TokenValidationParameters.ValidIssuer = "issuer";
           b.TokenValidationParameters.ValidAudience = "audience";
       })

var token = JwtBearer.CreateToken(
    o =>
    {
        o.SigningKey = "signing key";
        o.SigningStyle = TokenSigningStyle.Symmetric;            //not necessary as it's the default value
        o.SymmetricKeyAlgorithm = SecurityAlgorithms.HmacSha256; //not necessary as it's the default value
        o.Issuer = "issue";
        o.Audience = "audience";
        o.ExpireAt = DateTime.UtcNow.AddDays(1);
        o.User.Claims.Add(("Claim Type", "Claim Value"));
        o.User.Permissions.Add("Perm1", "Perm2", "Perm3");
        o.User.Roles.Add("Role1", "Role2");
    });

and it sets up the right default values which you can override if needed.

if you still have issues after trying the FE provided methods above, pls attach a small repro project and i'll look in to it.


Insert/update functionality

Is it available?

Yes, an OData::EntitySet behaves like a hash and supports insert and update via the 'shovel' method: https://github.com/ruby-odata/odata#entities
I would advise against using this gem in production unless you have intentions of actively contributing back to the project, because there are a number of gaps in terms of capabilities. I no longer work for the company where I originally developed this and am not actively maintaining it. But, I am happy to review and accept pull requests.


pg_dump causes certain page/queries to timeout/block

This is a continuation of the discussion over in a repository that initially tried to reproduce the problem.
The problem is the following:
If a slow running pg_dump is executed against the staging database, certain pages will time out with a 500 error code. Slow running here means the pg_dump is run over a slower network such that it takes several minutes. The errors don't appear immediately, only after the dump has been running for a minute or two.
One affected page is the home page.
Running queries that drive the home page uncovered that
-- blocks
SELECT * FROM recent_packages ORDER BY created_at DESC LIMIT 7;

will block, while
-- ok
SELECT * FROM recent_releases ORDER BY released_at DESC LIMIT 7;

does not. Both entities are materialised views and constructed almost identically. It's unclear why one would block and the other not.
Another odd result is the following: the page https://staging.swiftpackageindex.com/apple is driven by a single SQL query. Accessing this page during a pg_dump will, when the dump's been underway for a while, start throwing up 500s. However, the underlying SQL query can still be executed successfully via db client the whole time.
So there is certainly still something weird going on where a page we're building off an SQL query times out even though there's no evidence of the actual SQL query timing out or taking too long.

Johannes recommended running the author page query ("apple" query) within a transaction scope to see if that's perhaps causing the blocking:
BEGIN;
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT ... # your normal query here
;
COMMIT;

This makes no difference: the query completes fine with or without the transaction while the db is "locked up". Whatever is blocking the author page from loading, it doesn't seem to be the author SQL query.

@finestructure Wait, are you saying that this query
SELECT "packages"."id" AS "packages_id", "packages"."created_at" AS "packages_created_at", "packages"."updated_at" AS "packages_updated_at", "packages"."platform_compatibility" AS "packages_platform_compatibility", "packages"."processing_stage" AS "packages_processing_stage", "packages"."score" AS "packages_score", "packages"."status" AS "packages_status", "packages"."url" AS "packages_url", "repositories"."id" AS "repositories_id", "repositories"."created_at" AS "repositories_created_at", "repositories"."updated_at" AS "repositories_updated_at", "repositories"."forked_from_id" AS "repositories_forked_from_id", "repositories"."package_id" AS "repositories_package_id", "repositories"."authors" AS "repositories_authors", "repositories"."commit_count" AS "repositories_commit_count", "repositories"."default_branch" AS "repositories_default_branch", "repositories"."first_commit_date" AS "repositories_first_commit_date", "repositories"."forks" AS "repositories_forks", "repositories"."is_archived" AS "repositories_is_archived", "repositories"."is_in_organization" AS "repositories_is_in_organization", "repositories"."keywords" AS "repositories_keywords", "repositories"."last_activity_at" AS "repositories_last_activity_at", "repositories"."last_commit_date" AS "repositories_last_commit_date", "repositories"."last_issue_closed_at" AS "repositories_last_issue_closed_at", "repositories"."last_pull_request_closed_at" AS "repositories_last_pull_request_closed_at", "repositories"."license" AS "repositories_license", "repositories"."license_url" AS "repositories_license_url", "repositories"."name" AS "repositories_name", "repositories"."open_issues" AS "repositories_open_issues", "repositories"."open_pull_requests" AS "repositories_open_pull_requests", "repositories"."owner" AS "repositories_owner", "repositories"."owner_name" AS "repositories_owner_name", "repositories"."owner_avatar_url" AS "repositories_owner_avatar_url", "repositories"."readme_url" AS "repositories_readme_url", "repositories"."readme_html_url" AS "repositories_readme_html_url", "repositories"."releases" AS "repositories_releases", "repositories"."stars" AS "repositories_stars", "repositories"."summary" AS "repositories_summary", "versions"."id" AS "versions_id", "versions"."created_at" AS "versions_created_at", "versions"."updated_at" AS "versions_updated_at", "versions"."package_id" AS "versions_package_id", "versions"."commit" AS "versions_commit", "versions"."commit_date" AS "versions_commit_date", "versions"."latest" AS "versions_latest", "versions"."package_name" AS "versions_package_name", "versions"."published_at" AS "versions_published_at", "versions"."reference" AS "versions_reference", "versions"."release_notes" AS "versions_release_notes", "versions"."release_notes_html" AS "versions_release_notes_html", "versions"."resolved_dependencies" AS "versions_resolved_dependencies", "versions"."supported_platforms" AS "versions_supported_platforms", "versions"."swift_versions" AS "versions_swift_versions", "versions"."tools_version" AS "versions_tools_version", "versions"."url" AS "versions_url" FROM "packages" INNER JOIN "repositories" ON "packages"."id" = "repositories"."package_id" INNER JOIN "versions" ON "packages"."id" = "versions"."package_id" WHERE "versions"."latest" = $1 AND "repositories"."owner" ilike $2 ORDER BY "versions"."package_name" ASC [Optional(default_branch), Optional("apple")]

takes 2.5 seconds to run in normal operation? And 6 seconds whilst pg_dump is running?
That seems like a very very long time, right? But anyway, is the issue you're seeing that when running through the Vapor app, the query runs for more than 6 seconds, namely more than your 10 seconds request timeout limit?

takes 2.5 seconds to run in normal operation? And 6 seconds whilst pg_dump is running?

Yes, that's how bad my connection is :D Seriously, I get results almost immediately (my SQL client streams them) but it takes that long to complete. There's quite a bit of data being loaded in that query.
That's why I ran the query on our bastion host as well where we have excellent bandwidth and almost no latency - it all runs in <500ms. It's really just my network :/

Starting to see the following errors when running our test suite locally on a fast machine (M1) in docker:
    ✖ test_triggerBuilds_trimming, XCTAssertEqual threw error "connectTimeout(NIOCore.TimeAmount(nanoseconds:<PHONE_NUMBER>0))" -

Happens for different tests. I suspect we're only starting to see it now, because

we develop on macOS (where this doesn't seem to be happening) and typically only run the full suite on Linux in CI, which has slower machines
now with better VS Code remote container integration and arm64 docker images have we started to run the tests more frequently on M1s
it takes a couple of runs of the full suite to trigger the issue even on an M1, so it's easy to dismiss at first

I wonder if this test failure could be related to the pg_dump issue. If so, this might actually be a viable repro, because it's fairly easy to trigger once everything's set up.

I'm going to go ahead and close this. I don't think we'll be putting more time into this anytime soon.
We've worked around the issue with our db dumps and the test error doesn't seem to be happening anymore. I don't remember what all has changed since that last push to understand the issue but it seems time has cured all wounds 😅


Enable metrics via Prometheus Operator

Added support to enable metrics of docker-registry and enabled integration with Prometheus Operator (https://github.com/prometheus-operator/prometheus-operator)
This enables metrics and native seamless integration of docker-registry setup with Prometheus Operator. This functionality enables both passing of metrics and alert configuration to Prometheus. This functionality is by default disable and user can enable it.
Specification if metrics are enabled:

Metrics are be exposed on Pod and Service.
Pod port for metrics is set via configData while port for Service is set via values ( .Values.metrics.port )
ServiceMonitor and PrometheusRule are deployed which are part of Prometheus Operator monitoring.coreos.com/v1

Credits for exposing metrics: https://github.com/twuni/docker-registry.helm/pull/32
Example of configuration (Values.yaml) with enabled metrics and Alerts would look like:
....
metrics:
  enabled: true
  serviceMonitor:
    enabled: true
    labels:
      prometheus: prometheus
  prometheusRule:
    enabled: true
    labels :
      prometheus: prometheus
    rules:
      - alert: TooMany400s
        annotations:
          description: Too many 4XXs
          summary: More than 5% of the all requests did return 4XX, this requires your
            attention
        expr: 100 * ( sum( registry_http_requests_total{code=~"4.+"} ) / sum(registry_http_requests_total)
          ) > 5
        for: 1m
        labels:
          severity: critical
....

Any possibility on getting this merged? Would love to have metrics for our docker registry.

This PR does one important thing: provide the ability to expose the registry's debug port. Without that, I can see how monitoring it may be difficult.
Beyond that is convenience, however, expanding on the scope of this chart perhaps a bit too far, because it leans into a solution (Prometheus) for which users have other choices. That's my non-blocking and loosely held opinion.
As long as it doesn't break anything, though, and remains "opt in" functionality, I see no compelling reason not to approve, given at least a few folks have indicated it would be useful.

@canterberry, true including this may lead in favor of Prometheus Operator, but Prometheus was adopted early by CNCF and wildly used. This nicely round up solution for monitoring and simplify deployment for first time users.
Links: https://www.cncf.io/projects/, https://prometheus.io/docs/introduction/overview/
It is also by default disabled in values.yaml so you have to extra enable this.
But still if there are some concerns, I can move Prometheus operator out of scope of this PR and prepare new MR.

Released in v1.15.0.


Some official annoncuments are missing

There seems to be several official announcements missing, even with the noise filter turned off.
For Nov 17th, https://awsnews.info/ has two announcements while https://aws.amazon.com/new/ has 14. The same seems to be the case for earlier dates.
Is this a known issue?

Yes, I will be assessing this issue this weekend. Thanks for spotting.

Fixed: https://github.com/vladholubiev/awsnews.info-api/commit/28c41c5478abe2e1e2b73b61e470da630d377d4e


Use GPT4o by default instead of GPT4-Turbo

GPT4o is out now and better then GPT4 Turbo it's also not more expensive then gpt4 turbo, so this script schould be updated to use gpt4o instead of gpt4 turbo (don't know if anything in the API changed of if it's as simple as changing the model used).

@KeinNiemand, have you tried manually replacing the model name? I'm curious, I haven't tried the code yet, just wanted to know if switching to GPT-4o or GPT-4o-mini still works.

4o seems to work fine out of the box, I also made some adjustments in my version to use the batch API which makes is 50% less expensive, havn't put my version on github yet, put I might later (it also has some experminal changes to the promt which I havn't tested yet, bascially I just ask chatgpt to improve the prompt since the prompt seems extremely basic and usually giving the AI more info makes it better (like telling it's it's translating a novel and that it's an expert professional translator or whatever).
I also split the text into chunks based on tokens instead of characters I use 2000 tokens becouse giving the AI more context probably let's it make better translations (downside is that it might start leaving out stuff in the translation).

4o seems to work fine out of the box, I also made some adjustments in my version to use the batch API which makes is 50% less expensive, havn't put my version on github yet, put I might later (it also has some experminal changes to the promt which I havn't tested yet, bascially I just ask chatgpt to improve the prompt since the prompt seems extremely basic and usually giving the AI more info makes it better (like telling it's it's translating a novel and that it's an expert professional translator or whatever). I also split the text into chunks based on tokens instead of characters I use 2000 tokens becouse giving the AI more context probably let's it make better translations (downside is that it might start leaving out stuff in the translation).

Hello ! Did you PR or have published your own repo with those changes?
Thanks !

I made a fork and pushed my changes to it (in a separate branch) [https://github.com/KeinNiemand/translate-book/tree/BatchAPI](link to fork).
It's not really ready for me to make a pull request tough.

The changes to the prompt are completely untested.
The batch API can take up to 24h to complete in theory (in practice to took a few minutes at most) so I implemented functionality to save those reqeust to a file and continue the translation later (it will use the API to periodeicly check if the request are complete). It also requires uploading all the chinks as files to the OpenAI servers. I have not implemented any way to clean up those files or seperate them for diffrent epubs that you want to translate so if you want to translate something else you need to manually cleanup those files. The files uploaded to OpenAI also never get cleaned up which mean eventually you'll probably run out of space on the OpenAI account.

@KeinNiemand @jb41
Hi! I've used your code as the starting point for a much expanded version of this script that started out for my personal use, but I'm thinking about making it public. It's about 1000 lines long and supports both normal and batch processing, and can resume from errors in both modes so you don't lose what you've already paid for. It also no longer uses epub or beautifulsoup libraries, instead works on the files directly. I'm very new to how Github and FOSS works, so I don't know what the proper etiquette is for publishing this. I am planning of course to acknowledge your work in the readme, but is there anything else I should do? Let me know, and I appreciate your great work!

Don't worry, I'm also new to github, one day if I have some time I'll check out your code.
Thanks for the message.


Merge vendor branch with upstream/master

Just need someone to verify that the correct commits were pulled in from upstream/master and the merge was done correctly.
No need to review all the changes.

I can confirm that the correct commits are there. I'm going to make sure it actually can build things before I approve.

That would be a cool thing to automate with github ci.

Tested with both iOS and Android builds. Seems to work fine. 👍

Thanks Chip!


Chronicle of Shadows - can it be disabled on startup?

On 1.18.1, I'd like to disable the guide book until the player crafts it.  Is there a way to disable it on startup?

You have to override the advancement that is granting it.
I'll add a config eventually

You have to override the advancement that is granting it. I'll add a config eventually

How can we override it?

3b01eb3


Linking libcurl.so as as static library

Building packchk main fails with
"attempted static link of dynamic object libcurl.so"
for linux with the recent update to add xerces-c library.

That is strange, I am not seeing this failing in the github actions build for linux.
Also I thought we had agreed that we would not configure the option for xcerces library to accessing a url.
Could this be a problem of command line options during build?

There is a line in the CMakeFIle for packchk that forces the -static option when linking using gcc which triggers the problem. Is the  binary expected to link with libcurl.a or libcurl.so?

Hi @jlonnberg,
May I ask you to check the output of your cmake configuration command, please?
In the GitHub action as well as on my local system I can see the following diagnosis message:
 :
-- Performing Test XERCES_HAVE_STD_THREAD
-- Performing Test XERCES_HAVE_STD_THREAD - Success
-- Could NOT find CURL (missing: CURL_LIBRARY CURL_INCLUDE_DIR)
-- Looking for C++ include nl_types.h
-- Looking for C++ include nl_types.h - found
 :

I.e., it is missing libcurl. Hence, I assume it disables curl functionality which in turn hides the issue you are having. Once I install libcurlpp-dev on my Ubuntu 22.04 the diagnosis output changes to
 :
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.81.0")
 :

But this still links successfully and results in a statically linked executable. So, I guess there is something else different in your build env.
Cheers,
Jonatan

It lists
-- Found CURL: /usr/lib/x86_64-linux-gnu/libcurl.so (found version "7.68.0")
and the build fails with
[605/664] Linking CXX executable tools/packchk/linux64/Debug/packchk
FAILED: tools/packchk/linux64/Debug/packchk
: && /usr/bin/g++-9 -g -O0 -MD -Wall -static tools/packchk/CMakeFiles/packchklib.dir/src/PackChk.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/PackOptions.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/ParseOptions.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/RteModelReader.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/Validate.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/ValidateSemantic.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/ValidateSyntax.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/CheckComponents.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/CheckConditions.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/CheckFiles.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/CreateModel.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/PackChk_Msgs.cpp.o tools/packchk/CMakeFiles/packchklib.dir/src/GatherCompilers.cpp.o tools/packchk/CMakeFiles/packchk.dir/src/PackChkMain.cpp.o -o tools/packchk/linux64/Debug/packchk  libs/rtemodel/libRteModel.a  libs/rtefsutils/libRteFsUtils.a  libs/crossplatform/libCrossPlatform.a  libs/xmltreeslim/libXmlTreeSlim.a  libs/xmltree/libXmlTree.a  libs/rteutils/libRteUtils.a  libs/xmlreader/libXmlReader.a  libs/xmlschemachecker/libXmlValidator.a  libs/errlog/libErrLog.a  external/xerces-c/src/libxerces-c.a  /usr/lib/x86_64-linux-gnu/libcurl.so  -lpthread && :
/usr/bin/ld: attempted static link of dynamic object `/usr/lib/x86_64-linux-gnu/libcurl.so'
collect2: error: ld returned 1 exit status
How does you command line for the linking look like?

Okay, I cleaned my workspace and started from scratch and now I can reproduce the issue. This seems to be an issue with the Xerces build system.

Do we want PackChk to use Xerces with network access support? If yes, we need to investigate how to get this statically linked. If not, there seems to be an option option(network "Network support" ON) which could be set to OFF.

@JonatanAntoni I had agreed with Yves already that we wanted to exclude network support so I agree that the above option must be set to OFF. Does that problem solve your local build?

@jlonnberg, please feel free to reopen the issue if the build of packchk is still failing locally for you.


add quickjs benchmark

Other libs are pretty unusable in qjs :sweat_smile:
Executing QuickJS benchmark...

--- unicode-segmenter/grapheme ---

unicode-segmenter/grapheme (small input)
samples: 1000
duration (avg): 0.252

unicode-segmenter/grapheme (medium input)
samples: 1000
medium input (avg): 0.975

--- graphemer ---

graphemer (small input)
samples: 1000
duration (avg): 0.76

graphemer (medium input)
samples: 1000
duration (avg): 3.774

--- grapheme-splitter ---

grapheme-splitter (small input)
samples: 1000
duration (avg): 4.262

grapheme-splitter (medium input)
samples: 1000
duration (avg): 21.481


WIP

https://phabricator.endlessm.com/T33793

It looks like you took the code from LE's develop branch, but I don't see the commits. Is that intentional?

Yes, the LE commits don't apply directly into our main.py. Also their git history is not that clean. Example: https://github.com/learningequality/kolibri-installer-android/commit/688583d3100b45b089d553921add057abdfa0226. So I preferred to copy/paste the current code.

Also, can you update the Jenkinsfile so it uses a correct kolibri wheel?

OK, I was waiting for a new alpha release but even that won't give us a wheel file in PyPi. So I think we can wget it from their buildkite.com. I will have to adapt the Makefile to do:
wget -O kolibri-0.16.0.dev0+git.20220902161333-py2.py3-none-any.whl https://buildkite.com/organizations/learningequality/pipelines/kolibri-python-package/builds/6198/jobs/0182fefa-da30-4683-a144-e7a7c0d3067c/artifacts/0182ff0f-a9e4-4384-bf26-d941243db21c

Converting to draft until we have a kolibri-explore-plugin for 0.16 in PyPi.

It looks like you took the code from LE's develop branch, but I don't see the commits. Is that intentional?

Yes, the LE commits don't apply directly into our main.py. Also their git history is not that clean. Example: learningequality@688583d. So I preferred to copy/paste the current code.

Sure, but once you do that we effectively decouple our history from theirs. Is that the intention? Every upstream is going to have unclean history sometimes, but if you merge or rebase the final commit I don't think it really matters.

@dbnicholson ok, I will try merging / rebasing and fixing conflicts today. My worry is that we already have decoupled our history from theirs a while ago. Maybe another option is to start over again from their main branch and try to move our main.py customizations to a separate Python module.

@dbnicholson ok, I will try merging / rebasing and fixing conflicts today. My worry is that we already have decoupled our history from theirs a while ago. Maybe another option is to start over again from their main branch and try to move our main.py customizations to a separate Python module.

That's fair. Maybe in the interest of time let's just keep what you have right now. We can always pull it back together later.

retest this please


Can't create blog

When trying to start a blog, I get the following issue:
Command line output
I tried to perform a few different things to get certs up to date, but no luck.
Arch Linux - system updated just yesterday
ruby 2.2.1p85 (2015-02-26 revision 49769) [x86_64-linux] - managed through rvm
Gems:
middleman (4.1.7)
middleman-blog (4.0.1)
middleman-cli (4.1.7)
middleman-core (4.1.7)
middleman-livereload (3.4.6)
All the bundle install/update commands work and update the gems without issue. Other projects on my system have had a similar error and have required me to re-install rubies managed through RVM due to changes in OpenSSL with rubygems. But after re-compiling, all of them are fine.
The cert on directory.middlemanapp.com was issued on Monday, April 18, 2016 at 11:09:00 PM

Hi @joeperic – I just ran the same command in an environment using the same version of Ruby (2.2.1p85), and everything built normally. I'm on a Mac and using RBENV, so perhaps the problem has more to do with how Arch and RVM are interacting? Just adding another data point in the hope that this helps.

Thanks. I'll keep chugging along here.

Dirty hack: I copied everything from /etc/ssl/certs/* into ~/.rvm/usr/ssl/certs/ as well as into the /gems/bundler-1.11.2/lib/bundler/ssl_certs/ subdirectory for that rvm-managed version of ruby.
It's all better now!

Seems the issue was fixed closing.


qwindow_dateformat not correctly passed on

Function g.part2 does not pass on qwindow_dateformat to function g.conv.actlog, which causes an error.
I am now fixing this.

Sorry, accidentally committed to master branch.
Outstanding action point:

[ ] Update changelog


Fix #149 UI weather extension

put all the background pics in the folder

@harshit0571 kindly add the ss and video of the enhancement!!

@harshit0571 ^

@harshit0571 good work
But you have not added a video implementation kindly do that also

Ok I will add the video today

https://user-images.githubusercontent.com/62325935/159894770-d7a9acb3-5d10-4597-9813-051dbfd6a59c.mp4

Added the vid

@harshit0571 what we meant was to add it in readme
Rest all is good 👍

@harshit0571 ??


errSecInternalComponent Command CodeSign failed with a nonzero exit code

fastlane 2.212.2
macOS: Ventura 13.3.1 (a) (Jenkins's Mac)
We have one React Native repo for several white levels (companies). We use Jenkins for CI and deploy on prod using fastlane.
There is only one WL that smoothly goes on prod. All the other WLs have this error.
CodeSign /Users/admin/Library/Developer/Xcode/DerivedData/App-app/Build/Intermediates.noindex/ArchiveIntermediates/App/InstallationBuildProductsLocation/Applications/MyAPP.app (in target 'App' from project 'MyAPP')
    cd /var/lib/jenkins/workspace/MyProj/iOS/ios

    Signing Identity:     "iPhone Distribution: MY WL (some code)"
    Provisioning Profile: "MY WL prod app store profile 2023"
                          (some code)

    /usr/bin/codesign --force --sign some-code --entitlements /Users/admin/Library/Developer/Xcode/DerivedData/App-some-code/Build/Intermediates.noindex/ArchiveIntermediates/App/IntermediateBuildFilesPath/App.build/Release-iphoneos/App.build/App.app.xcent --generate-entitlement-der /Users/admin/Library/Developer/Xcode/DerivedData/App-some-code/Build/Intermediates.noindex/ArchiveIntermediates/App/InstallationBuildProductsLocation/Applications/MyAPP.app
/Users/admin/Library/Developer/Xcode/DerivedData/App-some-code/Build/Intermediates.noindex/ArchiveIntermediates/App/InstallationBuildProductsLocation/Applications/MyAPP.app: errSecInternalComponent
Command CodeSign failed with a nonzero exit code.

Do you know what can lead to this problem?

@UraFIZ That saved my day, thank you a lot 🙌


adding logging to ensembl.io.genomio.fasta.process

to replace outdated and closed  https://github.com/Ensembl/ensembl-genomio/pull/206

I was not 100% but now pylint as confirmed by fear:

************* Module genomio.fasta.process
src/python/ensembl/io/genomio/fasta/process.py:59:0: W0613: Unused argument 'kwargs' (unused-argument)


Cloudmin Complex Backup Schedule

I'm unable to create a complex back up schedule. I click on the radio dial for it and select it from the popup but when saving, I get an error "Failed to save backup : No complex schedule was selected" When I edit a complex schedule, the popup does not have the previous selections set.

Steffan, hi! :slightly_smiling_face:
I just was fixing this bug yesterday. Could you pull the latest theme version and try again? It must work by now!

Worked that time. Yay!

:bowing_man:


ConvergenceWarning: Liblinear failed to converge

When I use the code in your example about graphCL, and then without modification will appear ConvergenceWarning: Liblinear failed to converge, increase the number of iterations. Increasing the number of iterations did not help, may I ask why?

Hi! thanking for bring this issue to our attention. Could you post the code of the example that produces this warning?

When I use the code in your example about graphCL, and then without modification will appear ConvergenceWarning: Liblinear failed to converge, increase the number of iterations. Increasing the number of iterations did not help, may I ask why?

Try increasing the number of epochs


Add missing pieces for 'driver' support on desktop

Description

Adds desktop projects to ApplicationPackageStore
Plumbs target overrides through the desktop builds

Related Issues
None
Tests
I added the following tests: None
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

[x] I read the Contributor Guide and followed the process outlined there for submitting PRs.
[x] I signed the CLA.
[x] I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
[x] I updated/added relevant documentation (doc comments with ///).
[x] All existing and new tests are passing.
[x] The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
[x] I am willing to follow-up on review comments in a timely manner.

Breaking Change
Does your PR require Flutter developers to manually update their apps to accommodate your change?

[ ] Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
[x] No, this is not a breaking change.

I've verified that this is enough to make flutter-driver work for macOS. I haven't tested Windows or Linux yet, but the corresponding pieces were obviously missing there as well so I added them at the same time.

I ended up having to touch more files; lib/main.dart was hard-coded in a few places in the tooling rather than using path.join which made things unhappy on Windows.

In the interest of unblocking the macOS support, so that people can start using it on at least one platform, I've narrowed the scope of this to just macOS and removed the path.join change. I'll do a follow-up with Linux and Windows.