Hello from fsspec!

I see that we have some goals in common. fsspec is a mature library in use by Dask, pandas, zarr and others. However, we don't have a good implementation of pathlib on our API. Would you like to join forces to implement pathlib-on-fsspec, using the code you have already developed?
xref: https://github.com/intake/filesystem_spec/issues/434
another attempt to do this, explicitly for fsspec: https://github.com/datarevenue-berlin/drfs

👋  @martindurant sounds cool!
There are probably a few level of integration that could work well. We intend to make it pretty easy to add custom clients/backends by implementing a relatively small surface area. We're adding more docs on this, but here's the boto3 one as an example. Implementing each of the functions there should make it simple to enable all of the pathlib API that we support:
https://github.com/drivendataorg/cloudpathlib/blob/8692c596d98292c4ca44fd2e654effb595db1427/cloudpathlib/s3/s3client.py
Option (1):
I could see a FsspecClient as part of cloudpathlib that if you pip install cloudpathlib[fsspec] then it uses the fsspec client for any of the schemes that fsspec supports. There's probably some details in the coupling between the specific kind of path object we return (e.g., S3Path) and the Client object that would need to be worked out, but that all seems pretty doable.

Other thoughts on interoperability? There's definitely a big chunk of cool things in fsspec that we don't want to duplicate (chunks/buffering, compressing cache, async, etc.).

I would say those two options sound pretty similar, except for where the code lives - which I am not too worried about at all. You are probably more likely to get to it, if you have time to experiment - but seeing that this was already requested at fsspec, maybe someone else in the community contributes some pathlib interface anyway.
Do you think there's an argument for S3FileSystem, GCSFileSystem and FTPFileSystem from fsspec-land to supplant the implementations you have or are developing? They may be more complete and reduce the amount of work you need to do.

@martindurant @pjbull
I took a quick stab at making an FsspecClient and FsspecPath classes that is backed by an fsspec FileSystem in #109.
from cloudpathlib.fsspec import FsspecClient, FsspecPath
from s3fs import S3FileSystem

FsspecClient(filesystem=S3FileSystem()).set_as_default_client()

cp = FsspecPath("s3://drivendata-public-assets/")
list(cp.iterdir())[0:3]
#> [FsspecPath('s3://drivendata-public-assets/CIP-from-brochure.jpg'), FsspecPath('s3://drivendata-public-assets/EPD-report.png'), FsspecPath('s3://drivendata-public-assets/Ending-Extreme-Poverty_A-Focus-on-Children.png')]

I think the tricky part that I don't have a great sense of is how to design the right interface to let users choose to use fsspec and to initialize the correct fsspec FileSystem class with minimal friction. In cloudpathlib currently, we already have a way of specifying dependencies with extras_require and with class dispatching based on the prefix/protocol in the bath. Choosing to use fsspec and dispatching to the right fsspec filesystem, and having dependencies specified is like two more layers of user choices.
The question of moving our backend logic entirely to fsspec is a pretty big one and would involve a lot of changes. This is my first time using fsspec, so I still don't have a great feel for the fsspec design or ecosystem.

Typical usage in fsspec allows access to the set of backend implementations using a protocol string and arguments, e.g., fsspec.filesystem("s3", anon=True), or by passing URLs including a prefix fsspec.open("s3://bucket/path/file", anon=True). (anon is just an example here, specific to s3)
Many packages that use fsspec, and some internal logic too, uses storage_options as a dict of kwargs to pass to the main entry functions, e.g.,
pd.read_csv("s3://bucket/path/file", storage_options={"anon": True}).
The current set of optional deps for fsspec are:
    extras_require={
        "abfs": ["adlfs"],
        "adl": ["adlfs"],
        "dask": ["dask", "distributed"],
        "dropbox": ["dropboxdrivefs", "requests", "dropbox"],
        "gcs": ["gcsfs"],
        "git": ["pygit2"],
        "github": ["requests"],
        "gs": ["gcsfs"],
        "hdfs": ["pyarrow"],
        "http": ["requests", "aiohttp"],
        "sftp": ["paramiko"],
        "s3": ["s3fs"],
        "smb": ["smbprotocol"],
        "ssh": ["paramiko"],
    },

but we don't depend on anything just to import the package, and some of the backends like file and memory. Sounds like we came up with a similar set of solutions!
Note that there are some implementations that are meant/able to be used with a further target filesystem, such as the local caches.
I'd be happy to talk about how fsspec works and describe our design/ecosystem.

Hello there !
I would like to point out that the support of fsspec would be incredibly useful for me, as for now I need to cache my pandas and geopandas files before trying to open them.
Thanks a lot :)

Arf sadly it is much more prosaic: my prime concern is to unify my code using agnostically files in the cloud or on disk and for now it is not possible :
path = AnyPath(path)

# Load vector in cache if needed (geopandas and cloudpathlib are not compatible for now)
if isinstance(path, CloudPath):
    path = AnyPath(path.fspath)

vect = geopandas.read_file(vect_path)

However I do not use files big enough  to see any slowdown caching files in my usecase (apart from rasterio rasters, but they do not use fsspec if I'm correct)

Ah, interesting. That looks to me like a geopandas feature request since they don't support os.PathLike. They do say they support filelike objects. You could try the following and see if it works. If they support filelike objects then I think it should be fine with CloudPath or Path objects:
path = AnyPath(path)

with path.open() as f:
    vect = geopandas.read_file(f)

Recent versions of pandas should work fine with CloudPath. For example:
In [1]: import pandas as pd

In [2]: from cloudpathlib import CloudPath

In [3]: df = pd.read_csv(CloudPath('s3://drivendata-public-assets/odsc-west-2019/california-tracts.csv'))

In [4]: df.head()
Out[4]:
        GEOID  year    name             parent-location  population  ...  eviction-rate  eviction-filing-rate  low-flag  imputed  subbed
0<PHONE_NUMBER>  2000  4001.0  Alameda County, California     2497.87  ...           0.00                  0.00         1        0       0
1<PHONE_NUMBER>  2001  4001.0  Alameda County, California     2497.87  ...           0.00                  0.86         1        0       0
2<PHONE_NUMBER>  2002  4001.0  Alameda County, California     2497.87  ...           0.80                  0.80         1        0       0
3<PHONE_NUMBER>  2003  4001.0  Alameda County, California     2497.87  ...           1.49                  1.49         1        0       0
4<PHONE_NUMBER>  2004  4001.0  Alameda County, California     2497.87  ...           0.00                  0.00         1        0       0

[5 rows x 27 columns]

I think the point of the discussion is that we could use cloudpath to have fsspec support generic pathlike objects without having to ask third-party libraries such as geopandas to do extra work.

Ah, interesting. That looks to me like a geopandas feature request since they don't support os.PathLike. They do say they support filelike objects. You could try the following and see if it works. If they support filelike objects then I think it should be fine with CloudPath or Path objects:
path = AnyPath(path)

with path.open() as f:
    vect = geopandas.read_file(f)

Recent versions of pandas should work fine with CloudPath. For example:
In [1]: import pandas as pd

In [2]: from cloudpathlib import CloudPath

In [3]: df = pd.read_csv(CloudPath('s3://drivendata-public-assets/odsc-west-2019/california-tracts.csv'))

In [4]: df.head()
Out[4]:
        GEOID  year    name             parent-location  population  ...  eviction-rate  eviction-filing-rate  low-flag  imputed  subbed
0<PHONE_NUMBER>  2000  4001.0  Alameda County, California     2497.87  ...           0.00                  0.00         1        0       0
1<PHONE_NUMBER>  2001  4001.0  Alameda County, California     2497.87  ...           0.00                  0.86         1        0       0
2<PHONE_NUMBER>  2002  4001.0  Alameda County, California     2497.87  ...           0.80                  0.80         1        0       0
3<PHONE_NUMBER>  2003  4001.0  Alameda County, California     2497.87  ...           1.49                  1.49         1        0       0
4<PHONE_NUMBER>  2004  4001.0  Alameda County, California     2497.87  ...           0.00                  0.00         1        0       0

[5 rows x 27 columns]

Sadly it is not the case, and I don't know why...
I haven't investigated though, my workaround is sufficient for now 😉

Thanks, @martindurant.  How would you use fsspec when opening a file with geopandas? I'm curious what fsspec implements that would make this work without having to explicitly download to a local file first and point to that local path.
(That said, I would encourage library maintainers to consider supporting os.PathLike since it is the official Python way to try to go from an object to a local file path.)

This is an exaggeration!
😆 certainly an exaggeration in terms of it actually getting implemented by libraries, but it is a PEP that was accepted for exactly this purpose! https://www.python.org/dev/peps/pep-0519/

fsspec can do this job implicitly; but yes, there are libraries which, typically because of some inner C code, can only work with real OS file handles on the local filesystem.

Ok, I'll do some digging to check out the mechanisms you use for this. When we visited this question, implementing os.PathLike seemed to us the "right" answer to make this seamless, but maybe there are other approaches worth considering.

implementing os.PathLike seemed to us the "right" answer

I'm sure both are useful! fsspec wants to provide full filesystem classes with all the functionality that implies, and several high-level features that you might find interesting, but not necessary for your core offering.  To have those and a nice pathlib interface would be awesome!
(( For instance (I happen to be working on this today), ReferenceFileSystem lets you view blocks of bytes at arbitrary offsets within arbitrary URLs as files, so that a library like zarr (which uses file naming conventions to locate blocks of array data) can  load data from third party HDF5, tiff and grib2 files whether or not the libraries made for those formats know how to handle remote files or not. ))
By the way, in my experience, most third party libraries work with file-like objects and paths. If a path-like is passed, they do str() at the earliest opportunity and end up treating it like a (local) path. Of course, I may well be biased in the set of packages I am exposed to - many of which know to defer opening paths to fsspec.

Hi there! I just wanted to mention that I would benefit from support for pathlib with fsspec: https://github.com/dask/dask/issues/8006 Many thanks for any help! :)

Hi! Ditto @asmith26 - I'd love to see more compatibility between fsspec and cloudpathlib's wonderful pathlib.Path interface.
My use case is when using pandas. I mention this in https://github.com/drivendataorg/cloudpathlib/issues/128.
Related issues:

this project

using pd.HDFStore(cloud_path) https://github.com/drivendataorg/cloudpathlib/issues/240
another issue when calling pd.DataFrame.to_csv(cloud_path) https://github.com/drivendataorg/cloudpathlib/issues/242

other projects

zarr, and support for pathlib.Path https://github.com/dask/dask/issues/8006

See also universal_pathlib, which I think is more recent than this discussion - although I am not in a position to compare the two projects.

universal_pathlib seems nice, but I didn't find any documentation and the project seems (too) young.
As per @grisaitis, I would also love those two approaches to mix!
Other well-known projects supporting fsspec are rasterio and xarray. With geopandas, those libs are pillars to the remote-sensing opensource community .

@remi-braun Are there specific issues that you're seeing? If there are bugs, it would be great to get them addressed. From an API perspective, both rasterio (as of this PR) and xarray seem to work with CloudPath objects already without going through fsspec.
from cloudpathlib import CloudPath

from matplotlib import pyplot as plt

import rasterio as rio
import rioxarray

cp = CloudPath("s3://drivendata-competition-biomassters-public-us/train_agbm/0003d2eb_agbm.tif")

# test rasterio directly
dataset = rio.open(cp)
plt.imshow(dataset.read(1), cmap='pink')
#> <matplotlib.image.AxesImage object at 0x1a2a333d0>
dataset.close()
#> None

# test rasterio + xarray
rds = rioxarray.open_rasterio(cp)
rds
#> <xarray.DataArray (band: 1, y: 256, x: 256)>
#> [65536 values with dtype=float32]
#> Coordinates:
#>   * band         (band) int64 1
#>   * x            (x) float64 0.5 1.5 2.5 3.5 4.5 ... 252.5 253.5 254.5 255.5
#>   * y            (y) float64 0.5 1.5 2.5 3.5 4.5 ... 252.5 253.5 254.5 255.5
#>     spatial_ref  int64 0
#> Attributes:
#>     scale_factor:  1.0
#>     add_offset:    0.0

I looked at the XArray docs, and there are a done of complex IO options. It looks like a number of the writing methods won't work since they don't support file-like objects. In this case, passing the str(CloudPath) off should hand it to their fsspec implementation. The method that does support file-like objects is engine="scipy" for netcdf. This has a bug in their implementation where close gets called multiple times, so we upload multiple times in quick succession. We have a small bug there to make our close idempotent. Are there other key scenarios in XArray to test/support?

That said, there still seems to be some confusion here about what we can implement within cloudpathlib. Unfortunately, the bulk of interoperability issues are outside of our control. I'll do my best to clear that up here and then close this issue.
First, cloudpathlib is already generally compatible with fsspec. Doing fs.open(str(cloudpath_object)) should work in most scenarios as long as the fsspec filesystem is configured properly. This lets you manipulate paths with cloudpathlib and read/write with fsspec. I wish you didn't have to call str for this, but to change that fsspec would need a simple shim to make the calling of str unncessary and do the dispatch/validation themselves.
Second, the general case for other libraries. cloudpathlib provides standard PathLike and file-like (through .open) objects for working with the contents of files.  Third party libraries that support fsspec have their own code that they wrote to special case being passed strings like s3://.... There is no way for cloudpathlib to know a library has these special cases, and even if we did there would be no way for us to pretend to be a normal string to trigger this code. If you want to trigger other libraries' special-case code like this either calling str on the CloudPath or CloudPath.as_uri() is the most likely way to make this work. Calling str on a Path object should also work for most libraries, so you can still write CloudPath/Path agnostic code that should work with these libraries and take advantage of how they work with fsspec.
Third, developers of other libraries shouldn't need any special case code for CloudPaths to "just work" (as long as they handle PathLike and file-like objects normally). The one caveat is that per this PEP fspath can only return a string. Because of this, in writing scenarios code that uses CloudPaths developers should use CloudPath.open and hand off the file-like object to other libraries. Unfortunately, there is no feasible way to effectively detect if libraries use the built-in open to operate on a CloudPath.
Another separate question is if we will develop and maintain an fsspec provider like the PoC in #109. We don't have any plans to do so. Doing so would not address any of the considerations above. It would just mean we do provider communication through fsspec, but not that any third party library would magically do the right thing with the file-like/PathLike interfaces we provide. You would still need the str/.as_uri calls to get that library to run their fsspec code which is almost always based on interpreting strings. In addition to not addressing these concerns, implementing that backend will add significant maintenance burden that doesn't seem worth it until there is sufficient user demand for providers/functionality that we don't have implemented with the official SDKs. Maybe the best option is for an enterprising developor to take #109 and create a seprate project that supports an fsspec client. We already support and easy way to make extesions by creating and registering custom CloudPath implementations, that is a relatively small codebase. It's not well documented, but looking at any of the existing implementations contains everything necessary to build an extension to support a new provider. More docs coming soon. Again, worth reiterating that doing so would not mean that libraries that know about fsspec would then magically know what to do.
So with all of that said, there's nothing we can implement in cloudpathlib to make substantive progress here. The only thing that we can do is encourage developers of other libraries where things are broken to support best practices, which allow them to support CloudPaths. These include:

Checking if objects passed to read/write functions are PathLike, and if so using what it gets from fspath to do the reading/writing.

Ensure that functions that do reading and writing support file-like objects, not just strings as paths.

The other best practice to ensure everything works well is for consumers of cloudpathlib to use CloudPath.open in write scenarios and pass the file-like object to other libraries.
One last word here: there many be real bugs on our side that prevent third party libraries from working with CloudPaths. All of this discussion is about the design and intent, and we're happy to fix bugs that are discovered.

Hello,
Just to answer, since this issue is closed.
The main problem is the libs based on opening files with fsspec won't work properly with CloudPaths.
They will call fspath to resolve it (instead of str()) and therefore the file called will be cached (this is not exaclty what we want, and this will be done silently)
For single files like tif this will be not optimal but will work (your example)
But for nested files likes VRT, this will crash as only the header is cached and not the relative files. This will break the paths inside the VRT.
Note that GDAL (and therefore rasterio) can read VRT stored on the cloud, and this is the expected behavior.
A little example:

vrt = AnyPath("https://s3.unistra.fr/merge_32-31.vrt")
rasterio.open(str(vrt)) # will work
rasterio.open(vrt) # will fail for the wrong reason, saying that the files linked inside the VRT don't exist


[SR-237][build-script] Determine CMake in Python

SR-237 calls for build-script and build-script-impl to be merged. This
commit takes another step towards that goal by moving the logic that finds
the path to the CMake executable up into build-script.
Users of build-script were previously able to specify which CMake
they wished to use via build-script-impl args, like so:
$ utils/build-script -- --cmake=/foo/bar/cmake

This commit preserves that behavior, while also allowing users to
specify that path via build-script args:
$ utils/build-script --cmake=/baz/cmake -- --other --flags

@modocache Thanks, apart from that environment variable issue, the PR LGTM, and passes my testing.

@gribozavr Good point! Updated as per your suggestions--the script no longer consults the environment.

Running tests again.

@modocache Sorry, the tests passed, but it seems like some other pull request that I just merged has caused conflicts, could you rebase?

@gribozavr Rebased! The conflict arose from a nearby line -- #789 added a curly brace around $DIST_CC in build-script-impl, which was only a few lines away to a change made to that file in this pull request.

@modocache Thank you, merging!


Revise template recommendation

Fixes #31572
Thanks @jez9999! 🚀
As @jez9999 implies, recommending the BWA template doesn't mirror any remarks elsewhere (Blazor Overview and Hosting Models docs in particular) that the choice between BWA or WASM has anything other than to do with the specification required by the organization for the app. There's no obvious cosmic reason to avoid WASM apps if they're a perfect fit for the spec.
Alternatively if there is some reason that I'm unaware of to favor BWAs outside of the benefits that we've already covered, I think we should state what that is, probably by also including it in the Blazor Overview and Hosting Models articles.

Internal previews

📄 File
🔗 Preview link

aspnetcore/blazor/tooling.md
Tooling for ASP.NET Core Blazor

I chatted with Dan offline about it. It's recommended for getting started in order to learn about server-side and client-side features. I'm calling that out explicitly. We'll leave the removal of "recommended" in the second spot, as it really isn't needed there.


Broke all of our buillds

Hey guys, I understand you wanted to change the name of your node module to docusign instead of docusign-node, but you cannot simply abuse npm and unpublish all your old versions and not even make them available.
According to https://github.com/docusign/docusign-node-client/issues/38 you've said you follow semver, which means that 7.0 is not compatible with 6.0. So I cannot even hardlink my services to the version I was using, and our entire organization has QA'd and tested.
Is there something I'm missing? Is there a reason why all versions < 7 are no longer available on npm?

Just pushed & published 19c0b44 on the 6.x branch. If an older version is needed let me know.
I'd also point you to read https://github.com/docusign/docusign-node-client/issues/44#issuecomment-187422877 to understand where DocuSign has decided to head with it's client libraries.
As a side note I am no longer the core maintainer of this repo but will still be around for a little bit to chime in on discussions & PRs until the transition to the new generated library is completed.

@distracteddev I apologize for broking your builds and I would like to know what is the SemVer that you use for our old package "docusign-node", in your package.json?
As mentioned, DocuSign is moving to a brand new package that supports fully our e-signature rest API. So I encourage you to consider exploring the new package an play with it.

It's not really a semver issue, it's a "we unpublished the module from npm" issue.
Unfortunately they're really not really following semver either.  Instead of hiding the beta version behind a beta tag and incrementing the major release version after being ready, they are instead putting the beta under a different npm package.  Plus it's up in the air if they'll notify or alter the original docusign package to notify new users they should be using docusign-esign instead.
There were comments that suggested that Docusign will have an announcement in their developer center, but let's be real.  No one will be checking that once they have their Docusign implementation feature complete.  I know personally if I monitored the announcements of all the different API's I've implemented at work, I'd get nothing done during the day.
Extra bonus points for having the Github tag and npm versions diverge (docusign-esign is on v2.0.0 and the latest docusign package is on v8.x.x).  Support requests will be confusing once you guys move forward with this, as you now can't correlate their installed npm version with a Github tag.
Overall I hope once the docusign-esign package gets past beta status, you guys merge the changes with a new major version release for docusign.

I am personally in favor of sticking with the docusign name and merging the new beta stuff in as v9.0 BUT the decision makers are real sticklers for keeping the package version the same as the API version.
However I find that unrealistic because our API does not strictly follow semver.
I'd love for you guys to chime in with your opinions since you are the vocal members of the DocuSign Node community and we value your input.

Personally I'm for keeping all future updates to docusign package.  If what's in the docusign-esign package is feature-compatible with what's able to be done with the 8.x version, then there's no real reason to hide it behind an alpha tag either.  The major version bump should mean that most people won't be hit with the different API out of nowhere (unless they are using something like docusign: * or similar).

@distracteddev Can you confirm that your build is working now, after we got the old package back?

Didn't hear back from the reporter for a long time. Please open a new issue if, by any chance, the issue comes back.


[typescript-language-features] Pass through all typescript.unstable.* settings

This allows users to pass settings to TS Server by specifying them in typescript.unstable config JSON. This primarily saves TS devs from having to build and run local edits to VS Code to test TS Server features that need to be enabled by an editor setting, but is also useful for letting users try out the same features in TS nightlies or even PR builds.

Thanks!


remove en-FJ from docs since it is now an existing locale

This PR removes "en-FJ" being used as an example of a fake or non existing locale.
It seems that when this doc file was created, en-FJ did not exist, but now it does so it doesn't make sense having it being used as an example of a fake locale being resolved into an existent one.
@jefgen suggested that using that using a "Private Use" ISO region code might be better, as it can't be used for a real locale, and makes the example more obvious that it is a constructed locale
I did a search on the repo using vs code and the GitHub search and it seems this is the only file that uses en-FJ as an example, but it wouldn't hurt to keep an eye on other files that might be having the same problem.

@erik0686 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Thanks @erik0686!

I did a search on the repo using vs code and the GitHub search and it seems this is the only file that uses en-FJ as an example,

Thanks for checking! 👍
Also tagging others as a FYI, since I can't add them to the PR, or edit the main PR description:
@ShawnSteele, @axelandrejs, @microsoft/target-dev

nit: I'd suggest re-wording the PR title to be something like this in order to be more clear as to the change:
"Change example locale from en-FJ to en-XA for ResolveLocaleName"

#sign-off


actions: add windows e2e

Fixes: Issue #3875

Is this a [WIP] or ready for review PR?

@adrianriobo Why did you add the hold label; perhaps it was WIP instead?

The Windows e2e action is not getting triggered, from the action yaml, it should get triggered once the Build Windows installer is finished running

It seems that I still need to display test results among the upstream PR checks (they run on the fork, but the workflow with windows-e2e runs on the default branch of the upstream repository). So one needs to take the results, when ready, and post them back on the PR that triggered the workflow which then triggered the windows-e2e workflow.


Port MiniTV ESP32 to CYD

Looks like a cool project! Not identical hardware to the CYD, but looks close enough that its possible.
https://github.com/galbraithmedia1/Mini-Tv-ESP32

@chunkysteveo , this showed up on my github feed because you starred it :)

@chunkysteveo , this showed up on my github feed because you starred it :)

haha - glad I could be of assistance!! It's a cool project, I loved the idea of his "Pocket Office", I could seriously have US Office on tap on my keychain!
This is similar to the Tiny Circuits Mini TV that Chris Greening just reviewed too. Similar LCD, AMP, Storage, MJPEG = TV idea.
Also this is starred by me - https://github.com/moononournation/MiniTV I use my Stars as a crude "bookmark to make" project drawer!!
(I still need to get on this CYD train 😢 )

https://github.com/modi12jin/SC01-Plus_MiniTV
https://m.youtube.com/watch?v=Y63FC2zGdZ8&t=67s
@witnessmenow  replaced it with lovyangfx and started DMA, adding gesture switching video.  it achieves 19fps


Support column rename

What changes were proposed in this pull request?
This PR introduces the DeltaColumnRenameSuite which tests the column renaming functionalities supported by the column mapping feature.
How was this patch tested?
This test should be automatically run.
Closes https://github.com/delta-io/delta/issues/958.
GitOrigin-RevId: a64ebcb847bfccd5d0af61ea7c997898507b62f9

@vkorukanti After triggering a rebuild it still has the same compilation error. It looks like the rebuild is not picking up new commits?

@jackierwzhang can you try merging master to your branch and push again?


⚠ Fortnite has degraded performance

In 6258f5a, Fortnite (https://fortnite.com) experienced degraded performance:

HTTP code: 200
Response time: 1484 ms

Resolved: Fortnite performance has improved in 611c5c3.


Automatic browser open when started

One little annoyance again. I have syncthing-macosx set to start on login which also starts browser every single time (with the webclient). I think this should be either turned off completely or there should be some setting to turn it off.
I guess its there for first time user but after that its annoying.

+1 ;)

Le 29 déc. 2016 à 18:49, krisis<EMAIL_ADDRESS>a écrit :
One little annoyance again. I have syncthing-macosx set to start on login which also starts browser every single time (with the webclient). I think this should be either turned off completely or there should be some setting to turn it off.
I guess its there for first time user but after that its annoying.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/xor-gate/syncthing-macosx/issues/22, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvt4WX3H1W6CWZ_DjJaSMVykd-N5yM1ks5rM_KbgaJpZM4LXvTE.

You are right about this, I have this not released this yet but is fixed.
See https://github.com/xor-gate/syncthing-macosx/blob/master/syncthing/XGSyncthing.m#L22

A new release will be made soon, thank you for your report. I'm closing this, feel free to comment.


Feature/add new vehicle

[X] When the user clicks the Add item link in the navigation panel they can see a form for adding a new item.

Hello @Abdelaziz-Mahdi

Please add the route in App.js for your component AddVehicle.jsx

should be something like this:
import Registration from './pages/AddVehicle';

function App() {
  return (
    <Provider store={store}>
      <BrowserRouter>
        <Routes>
          <Route path="/route_here" element={<AddVehicle/>} />
        </Routes>
      </BrowserRouter>
    </Provider>
  );
}

Please create the action controller for add new vehicle on the back-end (create method invehicles_controller.rb
)


fix(release): convert test utils to .ts

This fixes Issue #993 in the 'watson-developer-cloud/node-sdk' repository (https://github.com/watson-developer-cloud/node-sdk/issues/993)
Checklist

[x] npm test passes (tip: npm run lint-fix can correct most style issues)

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

:tada: This PR is included in version 2.0.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


The demo is down?

Describe the bug

System
Browser version: Chromium Version 79.0.3945.79 (Official Build) Built on Ubuntu
Operating system: running on Ubuntu 18.04 (64-bit)
Additional context
I have an account previously created

Hi, Demo database is being deleted and populated with demo data daily, hence you need to create new user if you want to access demo website.
If you are developing locally i recommend you to create your own mLab and Cloudinary user: https://github.com/dimimikadze/create-social-network#requirements-and-configuration

@fabiooshiro just delete your localstorage and everything will be back to normal.


SE-0441: Add language-mode option with alias to swift-version

As part of the implementation of SE-0441, this PR adds a compiler option language-mode' with an alias to the existing swift-version` option.

@swift-ci test

@dempseyatgithub could you please update a few tests to use new option so we can get some test coverage?

@swift-ci test

@dempseyatgithub could you please update a few tests to use new option so we can get some test coverage?

@xedin I've added a few tests and the checks pass. I believe I've added the tests correctly.

@dempseyatgithub could you please also open a PR to the swift-driver repo to update its options list according to:
https://github.com/swiftlang/swift-driver?tab=readme-ov-file#rebuilding-optionsswift

@dempseyatgithub could you please also open a PR to the swift-driver repo to update its options list according to: https://github.com/swiftlang/swift-driver?tab=readme-ov-file#rebuilding-optionsswift

I have opened a PR with this change: https://github.com/swiftlang/swift-driver/pull/1686.
Apologizes on having this taking so long, I seem to be a magnet for build issues.

The swift-driver PR has passed its checks and been approved:
https://github.com/swiftlang/swift-driver/pull/1686

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please build toolchain macOS

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please test

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please test source compatibility

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please build toolchain macOS

The Swift Build Toolchain macOS Platform error seems to be a linking error that is not related to this change.
@xedin Would the best approach be to rebase on top of main again and run the tests again?
Undefined symbols for architecture arm64:
  "___isPlatformVersionAtLeast", referenced from:
      _$s20swift_willThrowTypeds19UTF8ValidationError33_03D0F4A7CE17AC628CBA43FDBE73E23FLLV_Tg5 in Swift.o
      _$ss26_stdlib_isOSVersionAtLeastyBi1_Bw_BwBwtF in Swift.o
      _$ss11AnySequenceV3mapySayqd__Gqd__xKXEKlFTm in Swift.o
      _$ss20_adHocPrint_unlocked___07isDebugC0yx_s6MirrorVq_zSbts16TextOutputStreamR_r0_lF13printTypeNameL_yyypXpsAER_r0_lF in Swift.o
      _$ss12validateUTF8ys0B16ValidationResultOSRys5UInt8VGF in Swift.o
      _$ss10repairUTF8_21firstKnownBrokenRangeSSSRys5UInt8VG_SnySiGtF in Swift.o
      _$ss12validateUTF8ys0B16ValidationResultOSRys5UInt8VGF4failL_yys0bC5Error33_03D0F4A7CE17AC628CBA43FDBE73E23FLLVYKF in Swift.o
      ...
ld: symbol(s) not found for architecture arm64

@dempseyatgithub CI always rebases PRs on top of main so there is no need to do that. I'll try to figure out what is going on with toolchain.

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please clean build toolchain macOS

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please build toolchain macOS

https://github.com/swiftlang/swift-driver/pull/1686
@swift-ci please build toolchain macOS

Tried with toolchain and it looks like everything works as expected! Thanks you, @dempseyatgithub!

@swift-ci please smoke test

Going to re-run smoke test just in case.

Going to re-run smoke test just in case.
Tried with toolchain and it looks like everything works as expected! Thanks you, @dempseyatgithub!

You're welcome and thank you @xedin for all your help!


Adds support for short flags.

Uses https://github.com/simonleung8/flags library
Updated cf nozzle help description

LGTM


Add helper scripts for creating and deleting large numbers of tecplot files

I have a bunch of helper scripts that I use for processing the large number of f5 files that get output from my optimisations. This PR would add them to the repo so other people can use them too.
Summary of scripts:

f5convert_all: Runs f5totec in parallel on all .f5 files in the current folder for which there is not an existing tecplot file (or there is a tecplot file but it's older than the f5 file)
f5convert_subdirs: Finds all directories from the current directory down that contain .f5 files and runs f5convert_all in each one.
f5clean_all: Deletes all tecplot files in the current directory for which there is a corresponding f5 files (useful for freeing up disk space)
f5clean_subdirs: Finds all directories from the current directory down that contain .f5 files and runs f5clean_all in each one.

Thanks @A-CGray, I think these features would be a good addition.
Is there anyway we could implement them under f5totec as command line options?
We could also potentially add this to f5tovtk

Thanks @A-CGray, I think these features would be a good addition. Is there anyway we could implement them under f5totec as command line options? We could also potentially add this to f5tovtk

I'm not sure how easy it'd be to add these capabilities to the f5totec executable as that would require re-implementing all the filesystem operations in C.
However, it should be pretty easy to add a command line-option to the scripts to switch between using f5totec and f5tovtk. I could probably also make the subdirectory traversal a command-line option, so we'd just end up with two scripts f5convert and f5clean

Thanks @A-CGray, I think these features would be a good addition. Is there anyway we could implement them under f5totec as command line options? We could also potentially add this to f5tovtk

I'm not sure how easy it'd be to add these capabilities to the f5totec executable as that would require re-implementing all the filesystem operations in C.
However, it should be pretty easy to add a command line-option to the scripts to switch between using f5totec and f5tovtk. I could probably also make the subdirectory traversal a command-line option, so we'd just end up with two scripts f5convert and f5clean

Alright, that works for me


OpCodeChallenges Advanced Challenge logic

We currently need to have advanced challenges with multiple success states before passing the lesson.
The example provided is for advanced challenge 2
https://github.com/saving-satoshi/challenges/blob/master/chapter9/README.md#advanced-challenge-2
Steps

given a blank script and initial stack the block height should be pre-populated with 6930299
this part of the challenge should succeed with the basic script of OP_PUSH PUBKEY(VANDERPOOLE) OP_CHECKSIG the only initial stack required is SIG(VANDERPOOLE)
after filling in the script and initial stack there should be 3 ui changes

SuccessBar should show a state like in CH1GEN2 "looking good so far"

the initial stack should be cleared
The block height should increment by 1 to 6930300

the user may now input a new initial stack to pass the challenge completely

this success script will be OP_IF OP_PUSH PUBKEY(vanderpoole) OP_ELSE OP_PUSH 6930300 OP_CHECKLOCKTIMEVERIFY OP_DROP OP_PUSH PUBKEY(me) OP_ENDIF OP_CHECKSIG and the initial stack must equal SIG(ME) 0

On a failure of the second part, the user has two options, continue tweaking the initial stack until they get the correct answer or try again like in chapter 7. however, unlike chapter 7 this try again button in the successBar will reset the state back to step 1

additional tweak
we should add a optional param that can check the user's initial stack to make sure they are inputting the correct initial stack for a challenge

@pinheadmz we created a logic board for our advanced challenges that we would appreciate a quick read

Just brainstorming here... let the user switch between the two stacks and check their script against both?


Is it possible to expand/collapse Items from within the expandableItem class?

Greetings to the authors of my favorite android library!
I have an item that i want to expand by clicking on an icon, not via autoexpand. In the sample app, this seems to always be handled in the activity, by the following lines within a new ClickEventHook:
expandableExtension.expand(position);
expandableExtension.collapse(position);

I'd prefer to outsource the expand eventhook into the expandleItem class, but it seems like there is no function for that, only autoExpansion.
Is there a way to do this? Or is the activity/fragment the proper place to handle eventhook expansions?
Thanks a lot

Well you need the ExpandableExtension to do that.
Theoretically you can do this due to some nice facts :D.
So when binding the data to the view, the itemView gets the FastAdapter set as tag:
https://github.com/mikepenz/FastAdapter/blob/develop/library-core/src/main/java/com/mikepenz/fastadapter/listeners/OnBindViewHolderListenerImpl.java#L22-L36
So you can do this:
Object tag = holder.itemView.getTag(com.mikepenz.fastadapter.R.id.fastadapter_item_adapter);
if (tag instanceof FastAdapter) {
     ... get the extension from the fastAdapter, do you action
}

Hi Mike,
thank you very much for a fast response - now my fragment is neat and clean, and everything is handled in the item :-) I'll break it down in case someone needs more details.
The ExpandableItem needs a variable:
private static ExpandableExtension<IItem> expandableExtension;
which is set in the bindview method:
Object tag = viewHolder.itemView.getTag(R.id.fastadapter_item_adapter);
        if (tag instanceof FastAdapter) {
            FastAdapter fastAdapter = ((FastAdapter) tag);
            if (fastAdapter.getExtension(ExpandableExtension.class) != null)
            expandableExtension = (ExpandableExtension<IItem>) fastAdapter.getExtension(ExpandableExtension.class);
        }
In the item class, the eventhook is defined:
public static class MyExpandableEvent extends ClickEventHook<SimpleSubExpandableItem> {
        @Override
        public View onBind(@NonNull RecyclerView.ViewHolder viewHolder) {
            if (viewHolder instanceof SimpleSubExpandableItem.ViewHolder) {
                return ((ViewHolder) viewHolder).icon;
            }
            return null;
        }

        @Override
        public void onClick(View v, int position, FastAdapter<SimpleSubExpandableItem> fastAdapter, SimpleSubExpandableItem item) {

            if (item.getSubItems() != null) {
                if (!item.isExpanded()) {
                    ViewCompat.animate(v.findViewById(R.id.material_drawer_icon)).rotation(180).start();
                    expandableExtension.expand(position);
                } else {
                    ViewCompat.animate(v.findViewById(R.id.material_drawer_icon)).rotation(0).start();
                    expandableExtension.collapse(position);
                }
                //return mOnClickListener == null || mOnClickListener.onClick(v, fastAdapter, item, position);
            }
            //return mOnClickListener != null && mOnClickListener.onClick(v, fastAdapter, item, position);
            Toast.makeText(v.getContext(), "test pos = "+position, Toast.LENGTH_LONG).show();
        }
    }

The only line left in the fragment/activity is:
fastItemAdapter.withEventHook(new SimpleSubExpandableItem.MyExpandableEvent());


File browser

Is there any file browser available with this editor. I am developing a project based on Laravel. It would be great if i can use a markdown editor there with a image browser.

There is an image upload function that was just added last week, you can try it out with npm i easymde@next.

@Ionaru can there be an indicator like github's ![Uploading image.png…]() during the upload?


🐛 Firebase Auth too many refresh token request

Hi,
Using firebase auth for the web we detected that too many requests for refreshing token will be executed in Chrome for some devices using Windows 10. but there is no issue on other platforms, and the request keep executing until quota exceeded.
How to fix it?

flutter doctor -v
[✓] Flutter (Channel master, 1.22.0-10.0.pre.137, on Mac OS X 10.15.6 19G73, locale en-US)
• Flutter version 1.22.0-10.0.pre.137 at /Applications/flutter
• Framework revision 37e2013774 (6 days ago), 2020-09-11 04:05:02 -0400
• Engine revision bdaac368f8
• Dart version 2.10.0 (build 2.10.0-115.0.dev)
[!] Android toolchain - develop for Android devices (Android SDK version 30.0.0)
• Android SDK at /Users/cartwatech/Library/Android/sdk
• Platform android-30, build-tools 30.0.0
• Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
! Some Android licenses not accepted.  To resolve this, run: flutter doctor
--android-licenses
[✓] Xcode - develop for iOS and macOS (Xcode 11.7)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Xcode 11.7, Build version 11E801a
• CocoaPods version 1.10.0.beta.2
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 4.0)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin version 47.1.2
• Dart plugin version 193.7361
• Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6222593)
[✓] VS Code (version 1.48.1)
• VS Code at /Applications/Visual Studio Code.app/Contents
• Flutter extension version 3.13.2
[✓] Connected device (3 available)
• macOS (desktop)  • macos      • darwin-x64     • Mac OS X 10.15.6 19G73
• Web Server (web) • web-server • web-javascript • Flutter Tools
• Chrome (web)     • chrome     • web-javascript • Google Chrome 85.0.4183.102
! Doctor found issues in 1 category.

Hi @cartwa
Can you please provide your pubspec.yaml and a minimal complete reproducible code sample
Thank you

@TahaTesser
Sorry for late response.
here is pubspec.yaml
environment:
  sdk: ">=2.7.0 <3.0.0"

dependencies:
  flutter:
    sdk: flutter
  flutter_localizations:
    sdk: flutter

  firebase_core: ^0.5.0
  firebase_auth: ^0.18.0+1
  firebase_storage: ^4.0.0
  cloud_firestore: ^0.14.0+2
  firebase_messaging: ^6.0.12

I don't know if thats help because when we test it, it work on chrome on Windows but on another computer with same chrome version in Windwos not work!(sometime work, but after refreshing page logged out)
Here the code and app.
its same code I used for sign in using email and password.
If thats not helping, I can provide you the real app which has the issue
Thanks

Hi @cartwa
This doesn't reproduce your app or code repository on Google Chrome Version 85.0.4183.102 (Official Build) (64-bit)

I tested on this Windows now but it also has the same problem
Google Chrome is up to date
Version 85.0.4183.102 (Official Build) (64-bit)

This issue is usually caused by the device clock being out of sync, causing an endless loop of Firebase Auth trying to issue a new token using the existing refresh token, realizing that the time for the issued token is up, and then repeating the process.

@TahaTesser @rebaz94 @cartwa
I have the same issues in my test Windows machine, and I noticed it's related to incorrect time on the system. The time on the machine is in future in a few hours.

@TahaTesser @rebaz94 @cartwa
I have the same issues in my test Windows machine, and I noticed it's related to incorrect time on the system. The time on the machine is in future in a few hours.

Hey @podolskyi, thanks for the update. Is the fix set the time correctly?

This happens with the underlying Firebase SDKs if your host time is incorrect - not something FlutterFire has control over so I'm going to close this issue, thanks!


Update go version and deps

Bumps to a more recent version of go, one patch release higher than the version declared in stackrox/stackrox.
go mod edit -go 1.21.9
go get -u
go mod tidy

Testing:
go test -v ./resolver
go test -v ./yarn

go build && mv ossls ~/bin

Test the output of make ossls-notice on stackrox before and after the change:
$ make ossls-notice
$ diff -rq image/rhel/THIRD_PARTY_NOTICES image/rhel/THIRD_PARTY_NOTICES.pre-mod
Files image/rhel/THIRD_PARTY_NOTICES/manifest.csv and image/rhel/THIRD_PARTY_NOTICES.pre-mod/manifest.csv differ

Manual inspection of both manifest.csv files shows a slight change in the ordering, but otherwise contents is the same. The updated ossls seems to handle version numbers in ascending order now, e.g. with difft:
2340 wrap-ansi,7.0.0,./wrap-ansi7.0.0                       ....
2341 wrap-ansi,6.2.0,./wrap-ansi6.2.0                       2340 wrap-ansi,6.2.0,./wrap-ansi6.2.0
....                                                        2341 wrap-ansi,7.0.0,./wrap-ansi7.0.0

This seems unrelated to the other PR you have. I think this should just be based on the master/main branch and may be merged before that other PR


subclass reasoning/inference for UBERON

From the Relay, it appears RTX-KG2 is not doing subclass inference for UBERON

I opened a Cypher session on kg2canonicalized.rtx.ai, which contains KG2.7.5c, and ran the following Cypher query:
match (n)-[r:`biolink:subclass_of`]->(m) where n.id =~ 'UBERON:.*' and m.id =~ 'UBERON:.*' return count(*);

and it returned 24,639. So it appears that there are 24,639 UBERON-[subclass_of]->UBERON type edges in KG2.7.5c. Here is an example:
match (n)-[r:`biolink:subclass_of`]->(m) where n.id =~ 'UBERON:.*' and m.id =~ 'UBERON:.*' return n.id, r.predicate, r.knowledge_source, m.id limit 10;

returning:

n.id | r.predicate | r.knowledge_source | m.id
-- | -- | -- | --
"UBERON:0018355" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0008293" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0008292" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0008291" | "biolink:subclass_of" | ["infores:genepio", "infores:uberon"] | "UBERON:0000022"
"UBERON:0034930" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0014480" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0018688" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0018538" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0018539" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"
"UBERON:0018537" | "biolink:subclass_of" | ["infores:uberon"] | "UBERON:0000022"

So this seems to be not an issue with KG2c, but rather, perhaps an issue with the RTX-KG2 API or PloverDB perhaps?  I am tagging @amykglen in the hopes that she can weigh in.  If it is RTX-KG2 API or PloverDB, in that case I would vote to transfer this issue to the RTX repo issue tracker.

yes, this is something we need do with Plover/KG2c. when we implemented subclass of reasoning we only did it for the more common kinds of nodes (drugs, diseases), which seemed sufficient early on, but now we need to expand that. so I agree this issue can be transferred to the RTX repo.


forum.lido.fi does not resolve

currently the links for discussions-to lead to forum.lido.fi, which is not a subdomain but is listed as the CNAME in this repo.
so either:
A): its linking to this published repo's pages
or
B): is suppose to link to https://research.lido.fi/

Fixed 👌


MB-3079 Align Existing Components to the new file structure standard for front-end code

Description
This branch moves stories files to their respective components' folders, adjusts folder names and stories files to CamelCase, and adjusts import paths for stories files moved to new locations. This branch also gives each Header component it's own story file, as opposed to the larger combined file we had previously.
Setup
yarn install
yarn storybook

Code Review Verification Steps

[ ] There are no aXe warnings for UI.
[ ] This works in Supported Browsers and their phone views (Chrome, Firefox, IE, Edge).
[ ] Tested in the Experimental environment (for changes to containers, app startup, or connection to data stores)
[ ] User facing changes have been reviewed by design.
[ ] Request review from a member of a different team.
[ ] Have the Jira acceptance criteria been met for this change?

References

Jira story for this change
Use a consistent file structure for front-end code

Screenshots

Warnings

:warning:
This PR does not include changes to unit tests, even though it affects app code.

Messages

:book:
:link: MB-3079

  Generated by :no_entry_sign: dangerJS against a5d02392e8a237569fc062a4d79b06b994f32c39


UI - Breadcrumb containing hyperlinks doesn't have underline style

TO: @tombui99
CC: @adamcogan @bradystroud @AndreasLengkeek
As per our conversation, we wanted to make the breadcrumbs that contain hyperlinks to have the same underline style from rule contents

Change underline style for breadcrumb

Figure: Breadcrumb is still using old underline style

Figure: Underline style under rule contents
AB#59133

TO: @tombui99
CC: @adamcogan @bradystroud @AndreasLengkeek

Change underline style for breadcrumb

Done - https://www.ssw.com.au/rules/do-you-understand-the-value-of-consistency

Figure: Multiple categories with underline style - https://www.ssw.com.au/rules/files---do-you-know-where-to-keep-your-files

Figure: Single category with underline style - https://www.ssw.com.au/rules/do-you-understand-the-value-of-consistency

TO: @tombui99
CC: @adamcogan @bradystroud @AndreasLengkeek

Change underline style for breadcrumb

Done - https://www.ssw.com.au/rules/do-you-understand-the-value-of-consistency

Figure: Multiple categories with underline style - https://www.ssw.com.au/rules/files---do-you-know-where-to-keep-your-files

Figure: Single category with underline style - https://www.ssw.com.au/rules/do-you-understand-the-value-of-consistency


EditableInput with focus doesn't change value

Hey @casesandberg
I found a potential bug on EditableInput. When EditableInput is focused and you drag a Saturation or a Hue, the value doesn't change.
I create a small demo. You can edit it here: https://codesandbox.io/s/n53766998j
Just trying to debug the problem seems that if you change it by a normal input this "bug" disappear.
The problem may be that the EditableInput doesn't receive new props and doesn't trigger
componentWillReceiveProps: https://github.com/casesandberg/react-color/blob/master/src/components/common/EditableInput.js#L14.
and btw, thanks for react-color, it's anwesome lib!

Hello,
I don't want to say something wrong but this seems to be the normal behavior of <EditableInput/> (eg: here ) since value is updated only if the input is not focused. However i'm not sure why this was made that way.
Using this.props.value instead of this.state.value for the value prop should fix this https://github.com/casesandberg/react-color/blob/master/src/components/common/EditableInput.js#L140

Ops, that's true. I didn't read well the documentation.
But about changing state per props, seems that woudn't work. There's a componentWillReceiveProps that triggers this state change when the props and the state value are not equal. (I didn't tested).

It's strange though, because it doesn't seem to be a problem in the examples on the website.

The EdibleInput components only updates when you are not focused to prevent hex completion. For example, when you start to type in 333, the value that comes back is actually 333333, but we don't want to replace that in the field if you were meaning to type 333aaa.
I just looked at the demo you provided and see the issue you are talking about. I think the appropriate behaviour would be for the input to blur when you click or drag on anything outside of it. This would fix the issue you are talking about because the input would then be blurred which would then update with the appropriate value.

Exactly @casesandberg. Thanks for taking a look!

Was just about to post about this, I think the behaviour is kind of odd right now. Take the Chrome picker as an example. If you have it open up on click, EditableInput immediately gets focus. If you change the saturation, it still has focus and the input doesn't update with the correct hex, even though the hex is changing and in fact the correct prop IS being passed down.
I don't think EditableInput should get focus unless you've clicked or tabbed into it and if you have clicked out of it, it should lose focus.

I agree the inputs should only hold focus when you are actually focused on them. I believe this an accessibility problem of the sliders not taking focus. I am looking into this for v3.0.0


Empty gas report adding hardhat-ethers

It looks like by adding a call to ethers my gas report goes from being populated to completely empty.
Here is the deploy script disabling the gas reporting: if I comment out the lines I've marked gar report comes back.
import { HardhatRuntimeEnvironment } from "hardhat/types";
import { DeployFunction } from "hardhat-deploy/types";

const func: DeployFunction = async function (hre: HardhatRuntimeEnvironment) {
  const { upgrades } = hre;

  const factory = await hre.ethers.getContractFactory("ReceiversHolder"); // this is the culprit
  const instance = await upgrades.deployProxy(factory, [[]]); // this must be comment to avoid compilation errors
  await instance.deployed(); // this must be comment to avoid compilation errors
};
export default func;

My dev deps are:
    "devDependencies": {
        "@nomiclabs/hardhat-ethers": "^2.0.4",
        "@nomiclabs/hardhat-etherscan": "^2.1.8",
        "@nomiclabs/hardhat-waffle": "^2.0.1",
        "@openzeppelin/contracts": "^4.4.0",
        "@openzeppelin/contracts-upgradeable": "^4.4.0",
        "@openzeppelin/hardhat-upgrades": "^1.13.0",
        "@typechain/ethers-v5": "^7.2.0",
        "@typechain/hardhat": "^2.3.1",
        "@types/chai": "^4.3.0",
        "@types/data-urls": "^2.0.1",
        "@types/mocha": "^9.0.0",
        "@types/node": "^16.4.0",
        "@typescript-eslint/eslint-plugin": "^4.33.0",
        "@typescript-eslint/parser": "^4.33.0",
        "base64-sol": "^1.1.0",
        "chai": "^4.3.4",
        "chai-as-promised": "^7.1.1",
        "data-urls": "^3.0.0",
        "dotenv": "^10.0.0",
        "eslint": "^7.32.0",
        "eslint-config-prettier": "^8.3.0",
        "eslint-config-standard": "^16.0.3",
        "eslint-plugin-import": "^2.25.3",
        "eslint-plugin-node": "^11.1.0",
        "eslint-plugin-prettier": "^3.4.1",
        "eslint-plugin-promise": "^5.2.0",
        "ethereum-waffle": "^3.4.0",
        "ethers": "^5.5.3",
        "hardhat": "^2.7.1",
        "hardhat-deploy": "^0.9.14",
        "hardhat-deploy-ethers": "^0.3.0-beta.11",
        "hardhat-gas-reporter": "^1.0.6",
        "hardhat-packager": "^1.2.1",
        "npm-prepare-dist": "^0.3.3",
        "prettier": "^2.5.1",
        "prettier-plugin-solidity": "^1.0.0-beta.13",
        "recursive-copy": "^2.0.13",
        "solhint": "^3.3.6",
        "solidity-coverage": "^0.7.17",
        "ts-node": "^10.1.0",
        "typescript": "^4.3.5"
      }

@rlogiacco Do you have a repo or branch I could look at to reproduce this? I suspect the problem may be coming from upgradeability & proxying rather than ethers.

Sure I do: https://github.com/agileware-org/nft-collection branch upgradeable.
I would agree with you if only some invocations were missing, like those going through a proxy, but they all disappear, including cost of contract deployment...
Let me know if you need any help in understanding the repo

@rlogiacco I wasn't able to reproduce this problem (on the hardhat network).
After installing your repo, I commented out rinkeby, mainnet and default network settings in hardhat.config.ts (because I wasn't using a private key and it throws an error when loading)
Then I ran npx hardhat test, setting the REPORT_GAS env variable to true (because your reporter config says gas reporting is only enabled when that variable is set).
I saw:

Is something missing from this report?

have you switched to the upgradeable branch? I believe you are still on the main branch because I don't see the invocation of the proxy upgrade operation.

The entire command I'm using is REPORT_GAS=y npx hardhat test --network hardhat --deploy-fixture

@rlogiacco Sorry, you're right, I was on the wrong branch. On upgradeable without the --deploy-fixture flag I see a report which suggests the problem comes from the way you're using hardhat-deploy. Could you verify this is the case on your end?
The --deploy-fixture flag tells hardhat-deploy to execute the deployments before the tests launch and the mocha reporter has no record of those contracts. It begins tracking deployments and matching contract invocations to contract addresses when the tests start.
This should be fixable fwiw. There's special logic at eth-gas-reporter to handle a similar issue with Truffle migrations. We just need to inspect hardhat-deploy's artifacts and match contracts to their pre-deployed addresses.
In the interim, is it viable for you to run your tests without that flag enabled if you want a gas report? Both commands seem to work (although --deploy-fixture may speed things up a bit)
![Screen Shot 2022-01-23 at 9 35 52 AM](https://user-images.githubusercontent.com/7332026/150701229-a016e0c2-aed7-4d14-8e1d-82d763643be0.png)

Sure, but the report becomes empty only if I use the ethers library in any of those deployment fixtures, while it works perfectly if I don't use the ethers lib in there. To verify just open the file deploy/2.DroppableCollectionFactory.ts and comment line 11 (and anything related to that, obviously). Then the report will be there again even if you use the --deploy-fixture flag.
In other words, the use of the ethers library in any deploy fixture breaks the gas report. I'm about to create a new branch (I'll call it with-gas-report) with the same content but a few variations which do not require the use of the ethers library.
Thanks a million for taking the time to help me on this.

Here you go, and at this PR you can see the difference https://github.com/agileware-org/nft-collection/pull/1

@cgewecke have you had any chance to review the link I provided? I believe it makes more clear why I'm considering this an issue with the ethers library...

Apologies @rlogiacco
I'm unsure what's happening in the new branch but perhaps the get method executes the deployments if they're missing during the test. That would result in them being detected by the reporter.
get is part of hardhat-deploy.
Does it work with ethers and without the --deploy-fixutre flag?
If so the differences you're seeing are very likely due to how hardhat-deploy behaves.

Actually it does work and it reports gas correctly if I remove the --deploy-fixture flag!!!
That's pretty surprising!
So I guess the get method somewhat triggers something parallel to the what the --deploy-fiXture does!
Do you suggest I close this and open an issue on the hardhat-deploy project?

Do you suggest I close this and open an issue on the hardhat-deploy project?

@rlogiacco No, I think it's something we should fix here (e.g at eth-gas-reporter). Thanks for discovering it.
Am going to edit the title a bit to reflect the underlying issue.

Just to add more data points for testing - I have recently seen that in a NFT project called Bleeps. Here's how to reproduce it:
git clone https://github.com/wighawag/bleeps
cd bleeps/common-lib/
npm install
npm run build
cd ../contracts
sed -i 's|"bleeps-common": "workspace:\*",|"bleeps-common": "file:../common-lib/",|g' package.json
rm test/BleepsDAO.governor.test.ts
npm install npm-run-all
npm install
HARDHAT_DEPLOY_FIXTURE=true REPORT_GAS=true npx --no hardhat test

·--------------------------------------------------|---------------------------|----------------|-----------------------------·
|               Solc version: 0.8.9                ·  Optimizer enabled: true  ·  Runs: 999999  ·  Block limit: 50000000 gas  │
···················································|···························|················|······························
|  Methods                                                                                │
·····························|·····················|·············|·············|················|·············|················
|  Contract                  ·  Method             ·  Min        ·  Max        ·  Avg           ·  # calls    ·  usd (avg)    │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  delegateBySig      ·      76512  ·     156596  ·        118510  ·          3  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  mint               ·      93503  ·     127468  ·        119195  ·        152  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  permit             ·      40878  ·      57966  ·         49422  ·          2  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  permitForAll       ·      58066  ·      75174  ·         66620  ·          2  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  safeTransferFrom   ·     141843  ·     147854  ·        144011  ·         16  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  safeTransferFrom   ·     142445  ·     148745  ·        144566  ·         12  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  setApprovalForAll  ·      24279  ·      46203  ·         42825  ·         26  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  Bleeps                    ·  setMinter          ·      47171  ·      47183  ·         47181  ·        120  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  ERC20                     ·  approve            ·      28982  ·      51429  ·         49699  ·         26  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  ERC20                     ·  transferFrom       ·     107631  ·     147110  ·        138121  ·         53  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  MeloBleeps                ·  mint               ·          -  ·          -  ·        120110  ·          2  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  MeloBleeps                ·  reserve            ·          -  ·          -  ·        139861  ·          2  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  MeloBleeps                ·  setMinter          ·          -  ·          -  ·         30061  ·          2  ·            -  │
·····························|·····················|·············|·············|················|·············|················
|  OpenSeaProxyRegistryMock  ·  setProxy           ·          -  ·          -  ·         43895  ·          1  ·            -  │
·----------------------------|---------------------|-------------|-------------|----------------|-------------|---------------·

  81 passing (2m)

The author seems aware of the limitation because there's actually a separate npm run void:deploy command that executes hardhat deploy --report-gas. For me it would be very convenient if the deployment cost was included in the main report though.

One more thing that may or may not be related. I noticed that I do not get the report if I run tests with mocha. I only get them with hardhat test directly. You can see that if you replace hardhat test in the above repro with npm run test. Is that something I should report as a but or some known limitation?

@cameel Ah I've never tried that actually. 😅
If you run mocha --reporter eth-gas-reporter does anything happen?
I think it should find the purely mocha version of  the reporter (which this plugin wraps) in the dependencies and connect to a client on localhost:8545.  The options here are mostly mocha reporterOptions consumed by eth-gas-reporter.

Just tried adding this to the command from Bleeps (HARDHAT_DEPLOY_FIXTURE=true HARDHAT_COMPILE=true mocha --bail --recursive test) and looks like it invoked eth-gas-reporter but it had problems connecting:
ERROR: eth-gas-reporter was unable to resolve a client url from the provider available in your test context. Try setting the url as a mocha reporter option (ex: url='http://localhost:8545')

In any case I think this answers my question - mocha is just using its own reporter and has to be configured to use eth-gas-reporter - which is what Hardhat does by default. This unfortunately does not solve the problem I had with it - I was hoping I could somehow get an unmodified npm run test command to report gas - but it's also not like it's a huge problem. npm run test would just be a bit less likely to break in case a project changes the command to run tests in a different way. I just thought it might have been a bug but looks like it's not :)

I'm using hardhat-deploy and my deploy files don't use ethers, I use
import { DeployFunction } from 'hardhat-deploy/types';

const func: DeployFunction = async function (hre: HardhatRuntimeEnvironment) {
    const { deployments, getNamedAccounts } = hre;
    const { deploy } = deployments;
    const { deployer } = await getNamedAccounts();

    await deploy('Contract', {
        from: deployer,
        log: true,
    });
};

export default func;

func.tags = ['Contract'];```

But still doesn't work

We experienced similar problems with missing gas reports for functions in many different use cases.
I was trying to reproduce the problem with a minimal configuration and I came to a conclusion that any usage of ethers in the deployment script along with the --deploy-fixture flag causes the gas report to be broken.
Please find an example in the repository https://github.com/nkuba/hardhat-gas-reporter-playground.
After running the yarn test you will get a following report:
·-----------------------|----------------------------|-------------|-----------------------------·
|  Solc version: 0.8.9  ·  Optimizer enabled: false  ·  Runs: 200  ·  Block limit: 30000000 gas  │
························|····························|·············|······························
|  Methods                                                                                │
·············|··········|··············|·············|·············|·············|················
|  Contract  ·  Method  ·  Min         ·  Max        ·  Avg        ·  # calls    ·  eur (avg)    │
·------------|----------|--------------|-------------|-------------|-------------|---------------·

  1 passing (173ms)

It's enough to comment out the line referenced below to get a correct report.
ethers.utils.isAddress("0xFaKeAddrEss")
·-------------------------------|----------------------------|-------------|-----------------------------·
|      Solc version: 0.8.9      ·  Optimizer enabled: false  ·  Runs: 200  ·  Block limit: 30000000 gas  │
································|····························|·············|······························
|  Methods                                                                                │
·················|··············|··············|·············|·············|···············|··············
|  Contract      ·  Method      ·  Min         ·  Max        ·  Avg        ·  # calls      ·  eur (avg)  │
·················|··············|··············|·············|·············|···············|··············
|  TestContract  ·  initialize  ·           -  ·          -  ·      68609  ·            1  ·          -  │
·················|··············|··············|·············|·············|···············|··············
|  TestContract  ·  setValue    ·           -  ·          -  ·      30190  ·            1  ·          -  │
·················|··············|··············|·············|·············|···············|··············
|  Deployments                  ·                                          ·  % of limit   ·             │
································|··············|·············|·············|···············|··············
|  TestContract                 ·           -  ·          -  ·     341398  ·        1.1 %  ·          -  │
·-------------------------------|--------------|-------------|-------------|---------------|-------------·


Added Connect via SSH button to active page

Description
This PR enables the "Connect via SSH" button to show the correct ssh command to be copied in the terminal in order to directly connect to the remote VM through the ssh bastion

/deploy-staging

/deploy-staging

I'd say to change You have registered a SSH key, connect to your remote instance via the following command: with Run the following command from your computer:, adding below Note: your device must have a private key corresponding one of the public keys associated on your account.
@giorio94 do you have any better suggestion?

I personally think that whoever knows what a SSH key is and has already added one to crownlabs would not need such an explanation

That's true, however you shouldn't even need to see that window at all (if not for the bastion jump)

I'd say to change You have registered a SSH key, connect to your remote instance via the following command: with Run the following command from your computer:, adding below Note: your device must have a private key corresponding one of the public keys associated on your account page. @giorio94 do you have any better suggestion?

Would personally keep that window simple, without too many information if not required.

/merge


Github shows latest release v0.9.39 but there is v0.9.40 available

Github shows latest release v0.9.39 but there is v0.9.40 available:

Thank you for your notification.
I created it.
https://github.com/treasure-data/digdag/releases/tag/v0.9.40

Thank you!


[ServiceBus] expose omitMessagesBody option under ./experimental subpath

playing with the idea of exposing features under the ./experimental subpath and add a dev-tool command to report error if we consume experimental Apis in a GA package.
[ServiceBus] Add the experimental diagnostic feature omitMessageBody
via an augmented PeekMessagesOptions interface under ./experimental subpath export.
After migrating to ESM, we no longer use rolled-up dts files thus lose the ability
to trim  @beta Apis from public type definition files. This PR explores an approach to
expose Apis from the ./experimental export.

Thanks to @deyaaeldeen's help. We could augment the options interface using declare module "../model.js"

API change check
APIView has identified API level changes in this PR and created following API reviews.
@azure/service-bus
@azure/service-bus

Looks good. Should we add a simple test and ditch the sample since it is not meant to be consumed by our broader customer base?

Yes, totally! One reason I included a sample is for easier reviewing of the usage.

/azp run js - service-bus - tests


Gevent updated, CI now not requires greenlet block

Pull Request Test Coverage Report for Build 105

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.07%) to 97.398%

Totals

Change from base Build 104:
-0.07%

Covered Lines:
262

Relevant Lines:
269

💛  - Coveralls

CI fixed -> force unlock


Patched DataFusion, Oct 15, 2024

This takes us up to Oct-15 SHA https://github.com/influxdata/arrow-datafusion/commit/399e8403d2fb5a058fb263bc2449dbc9d7529841.
It advances DF by adding these oct-7 to oct-15 commits: https://github.com/influxdata/arrow-datafusion/compare/577e4bba0f5838846862621e1f5318c949cff2cb...influxdata:arrow-datafusion:399e8403d2fb5a058fb263bc2449dbc9d7529841
Patches applied

We are still manually patching upstream commits, for these fixes:

oct-16 = commits from pr  https://github.com/apache/datafusion/pull/12951
Oct-20 = https://github.com/apache/datafusion/commit/8d4614d6c43104a13b42c062d957843f25ee32db
Oct-23 = commits from pr https://github.com/apache/datafusion/pull/12954
Nov-3 = https://github.com/apache/datafusion/commit/85f92ef6be1d7364857a2c13fbb026d9e45406ea
Nov-11 = commits from pr: https://github.com/apache/datafusion/pull/13305
clippy updates (presumably these are a bunch of separate upstream commits)

SanityCheckPlan

I'm not sure when we can stop skipping the SanityCheckPlan. I'm unclear how it relates to the additional sort pushdown fixes, including a recent fix done here: https://github.com/apache/datafusion/pull/13497

Patches still not fixed:

commit reverted due to CPU spinning bug (new)
This empty projection patch, since I only ever found these plans in iox-created influqxl LP.

patch: https://github.com/influxdata/arrow-datafusion/commit/001865dd8803e4a1a53f31e770cb6a88b043e89b
iox issue: https://github.com/influxdata/influxdb_iox/issues/12407

@alamb -- I had to add a single additional patch commit, due to an upstream commit from oct-8.
The test case correctly shows that bit_length(utf8view) statement should fail.
However, I'm not really sure how this statement was properly failing before (on datafusion main)?
Steps I took to debug:

without changes:

we get a utf8 view type for the column, post coercion
the statement bit_length(utf8view) was not failing on our DF upgrade branch.

I changed:

made the signature of bit_length only accept utf8 and large utf (not the views), since I think that oct-8 upstream commit made a wrong change. Note that the evoke does not handle view types.

but the tests still passed.

it looks like type coercion changed the utf8 view to large utf8.

So this branch now passes all DF tests, but I'm still unsure how DF main is ok with this test. 🤔

Patches applied

Thank you for this list

However, I'm not really sure how this statement was properly failing before (on datafusion main)?

I believe this was fixed in a newer version of arrow-rs that was released after that DataFusion commit

https://github.com/apache/arrow-rs/pull/6671

Since IOx is now running a newer arrow in my mind that explains the test difference

We are still manually patching upstream commits, for these fixes:

BTW I have added a discussion item for our next meeting about these patches (aka how should we be thinking about them upstream)


now downloading working

PR Fixes:
fixes #267
Resolves #[Issue Number if there]
Checklist before requesting a review

[x] I have performed a self-review of my code
[x] I assure there is no similar/duplicate pull request regarding same issue

using ngrok
https://github.com/code100x/daily-code/assets/123832227/af87c158-81cc-4a0f-914d-1d09221074dd

i remove window.close() because it closes the window simultaneously when the download option appear on the screen


Anything else we need to know?
Environment:

JuiceFS version (use juicefs --version) or Hadoop Java SDK version:
Cloud provider or hardware configuration running JuiceFS:
OS (e.g cat /etc/os-release):
Kernel (e.g. uname -a):
Object storage (cloud provider and region, or self maintained):
Metadata engine info (version, cloud provider managed or self maintained):
Network connectivity (JuiceFS to metadata engine, JuiceFS to object storage):
Others:

Note that once this is fixed it would still need a tagged release so that it can easily be picked up by https://github.com/Homebrew/homebrew-core/pull/157782 and others.


⚒[FEATURE] Playwright Integration

Describe the feature you'd like
Playwright Integration
Docs: https://js.langchain.com/docs/modules/indexes/document_loaders/examples/web_loaders/web_playwright
✅Tasks

[ ] Add Playwright Loader node

🎯Acceptance Criteria

[ ] Playwright Loader node should be able to scrape data from webpages

👨💻How to contribute
Follow this guide for step by step on how to fork, commit, and submit PR.
👨💻Reference code

Cheerio Loader

More info
Like to work on this issue? Let us know, and we will assign it to you 🚀
If you need any help or just want to hangout, reach out to us on our Discord server👾

I am interested! Please assign this issue to me

I am interested! Please assign this issue to me

heyyy maintainers Im sorry to say this but due heavy rain fall last night at my place. My internet will be down for 3-4 days . When its fix and this if this issue will remain open I will work on it! Thanks and sorry for inconvenience.

#327
Please check this PR. Hope can help.

closing as #327 merged


Correction for raw affiliation Fowler-Kennedy Sport Medicine Clinic, Western University

Correction needed for raw affiliation Fowler-Kennedy Sport Medicine Clinic, Western University
raw_affiliation_name: Fowler-Kennedy Sport Medicine Clinic, Western University
new_rors: 03hf41361;02grkyz14
previous_rors: 03hf41361
works_examples: W4387999649
contact: 10507ae344c0515c7352b26d3269ac1a:e58d678cee8f27d7 @ uwo.ca

This issue was accepted and ingested by the OpenAlex team on 2024-12-19. The new affiliations should be visible within the next 7 days.


using relative import to fix and issue with Python 3.4

This fixes an importing problem with Python 3.4 as detailed in issue #11
Tested on both Python 2.7 and Python 3.4

Any time frame on when this could get reviewed?

Hi Grant, we will have some review this asap and get it squared away. Thanks for your patience.


disconnect in basic example

Description
The basic example just hangs.  It was missing the disconnect.

Checklist

[ ] Does npm test pass with this change (including linting)?
[ ] Is the new or changed code fully tested?
[x] Is a documentation update included (if this change modifies existing APIs, or introduces new ones)?

I'm pretty sure that most of the node apps are REST APIs, and in that scenario you don't want to .disconnect()/.quit()
@simonprickett @guyroyse WDUT?

It's a "basic example" and listed as the first example in the README.  There are no instructions for how to run it.
"Obviously" you start a local server and copy-paste the example to a MJS file and run it with node.  Try it.  The process will just hang.
The documentation can include a note about when disconnect/quit are appropriate.

Maybe we should leave the example as is and add a note with a link to this section

If it is the case that "most of the node apps are REST APIs", then the "basic example" should be a simple REST server using raw Node HTTP server or ExpressJS.
The idea of a "basic example" IMHO is something you can run.  A person who is new to node-redis will see the snippet with an actual import statement etc. and just test it out, wondering why the process is stuck.

I like the idea of having it in there?


chore: update go-piper to latest (PR 9)

update go-piper to the latest to pick up https://github.com/mudler/go-piper/pull/9

@dave-gray101 it actually needs a pin into the Makefile.
See: https://github.com/mudler/LocalAI/pull/3949 (it seems to be red, so something looks off from the latest changes)

It looks like the bot eventually created an automatic PR to accomplish this -- this branch was made to allow me to start testing the middleware branch.
I'll check the other PR and assuming the bot did it correctly I'll just close this one - we don't need both


[#14] Add missing match_phrase query

Transferred from elastic/elasticsearch-ruby#1083, original PR by @nsiregar
Original Pull Request message
This PR will reorder match_phrase query based on the documentation https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html and add some new match_phrase query
will resolve #14

What is the timeline for getting this merged and released @picandocodigo ?


GDPR Add/delete/download custom user data

Fixes #6226
Internal preview URL

In the section: Add custom user data to Identity DB
The PersonalData attribute doesn't really affect the Delete, Delete is just calling UserManager.Delete


Feat/expose more config options

todo:

finish labels/annotations things

clicker (cron)job worker labels/annotations -- probably store this in env? so that the (cron)job pod can properly set this on the "worker" pod(s)
launcher labels/annotations -- probably should have a config crd and this lives there... sorta a big thing actually since we then need to have the controllers watch that crd and/or have some crd watcher that has a channel that sends updates to the controllers if the config changes. but... we need this anyway probably (for default request/limit things)

flag in topo CRs for launcher log level (this is still a maybe? do we need to be able to configure this per CR? yes? no? I dunno yet?) -- in progress, went down some weird rabbit holes but think have a good path forward that will make this pretty nice
requests/limits for (cron)job and workers (dont see also config thing above, this should be self contained to the clicker chart)
requests/limits for launcher (see also config thing above) -- for now will be just defaults (can easily add to the topo crds soon) and is in progress w/ the other stuff

going to merge this because its getting outa hand. will do the cr spec flag shortly and hopefully/maybe launcher limits too if I can get it sorted!


GORA-535 Add a data store for Apache Ignite

This PR adds the Apache Ignite data store to Gora.
Some issues with this PR:
-All DataStoreTestBase tests are passing.
-Documentation for the new backend is pending.
Code review welcome, thanks
Documentation: I created a Jira Issue (GORA-540) for documentation of the new Ignite backend. It contains a patch for the Gora website which adds a new section for this topic.

Overall PR looks great Carloz :+1: I will go through PR in detail.

Hi @lewismc @nishadi @alfonsonishikawa
Thanks for your feedback I will start working on the issues.

@carlosrmng This is excellent work Carlos. Thank you for all hard work you have put into this in summer. I hope you enjoyed your work. Please do address my comments, Let's get this thing merged. :)

@lewismc I will have a look Lewis. Sorry about the delays. If it all fine i will proceed merging to master.

np @djkevincr I just wanted to make sure we got it there as well :)
Excellent job on this one folks.. really.


Failed to update state of CFD: Failed to execute command on CFD: Condition failed: `!self.is_final()

This is the CFD of #1758 . It looks like we were not able to update the state
{
  "timestamp": "2022-04-04T00:09:20.647740964Z",
  "level": "WARN",
  "fields": {
    "message": "Failed to update state of CFD: Failed to execute command on CFD: Condition failed: `!self.is_final()`",
    "order_id": "1f232b96-28fc-430d-8f3a-c311e0194275"
  },
  "target": "daemon::monitor"
}

This project is unmaintained


Floodlights

WE HATE STRUCTURE YAML!!!
About the PR

Added tall, small, and LZ floodlights for more long-lasting and less eye-shredding sources of light.
MOTE:
Why / Balance

I'm going to make flares less harsh in a future pr, but floodlights at the LZ and floodlights around the FOB allow for better ways to light an area.
Both floodlights are destructible, repairable, but the small one will be destroyed and drop materials as apposed to the large one requiring upkeep.
Both give off infinite sources of light for the moment until power is implemented in a proper way.
Technical details

Media

[X] I have added screenshots/videos to this PR showcasing its changes ingame, or this PR does not require an ingame showcase

https://github.com/user-attachments/assets/cf5f14ba-1646-4c76-97dd-1e3f0e5868f5
To repair the larger lights, there's a note to inspect for any marine to see.

Breaking changes

Changelog

:cl:

add: Added floodlights to help be a light in the darkness.

YML formats are Parent ID Name Description
The rest seems ok but we'll check it just in case after

i think i got all of em'


High CPU usage "Looking for CSS classes" after update

VSCode Version: April 2018 (version 1.23)
OS Version: macOS 10.13.4

Steps to Reproduce:

Load a project or reload the workspace window

Does this issue occur when all extensions are disabled?: Confirmed it does not
After the 1.23 update I'm seeing excessive CPU usage for the first couple of minutes during "Looking for CSS classes in the workspace." Prior to the update this was not an issue. No additional extensions were added, so it seems something related to recent changes.

Does this issue occur when all extensions are disabled?: Some

Can you elaborate more on this? I would expect a yes or not answer to determine whether it's a VSCode issue or an extension one, thanks!

Okay, it looks like it is extensions related. I had the command line command to do so wrong. Now I guess it's narrowing it down. It is related to this extension: zignd/HTML-CSS-Class-Completion I will post issue there, but this problem did not occur until right after I installed the April update.


dx12: Stricter allocator reset

Adjust reset behavior for associated allocator for individual command lists.
quad example runs fine (as expected).
wgpu examples will crash due to resetting the allocator while concurrent recording.

I'm abit confused. If each command buffer comes with an allicator, why do we still suffer from the reset() in wgpu?

On Mar 3, 2019, at 10:53, msiglreith<EMAIL_ADDRESS>wrote:
@msiglreith requested your review on: #2667 dx12: Stricter allocator reset.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub, or mute the thread.

Ok, I think I see what's happening now. The allocator is still shared between command buffers, but since we didn't call Reset() on it before, it only resulted in a validation warning/error. Now we call Reset on it whenever any of the command buffers are reset, and this only works within the assumption that no 2 command buffers are recorded at the same time. Since this is not the case in wgpu-rs, we are crashing now.
The proper solution would be one (or both) of the two:

fix the dx12 backend to not require only a single command buffer being recorded
implement a path in wgpu-rs to not keep the old command buffer in the open state

bors r+

While this needs to be ported to hal-0.1 at some point, this is not going to improve the situation with wgpu-rs. So I think we need to fix wgpu-rs first, and then think about back-porting this.

Important note: what this is solving is resource leaks in case of simple applications. It's less forgiving for the others (turning warnings into crashes). We'll need a proper solution for DX12 backend regardless, at which point this PR will be reconsidered and/or reverted.

I'm a bit confused. If each command buffer comes with an allocator, why do we still suffer from the reset() in wgpu?

right, there are actually 2 different issues depending on what is used and I mixed those up :D

Path A: Shared/NoIndividualReset: No memory leaks, but no support for concurrent recording

Path B: Individual/Reset: Memory leaks (fixed with this one), supports concurrent recording, but doesn't implement state tracking for command buffer state

Command Buffer Lifecycles
CommandList::Reset in dx12 has a reset+begin semantic for commands buffers (-> Recording state), in Vulkan Reset means setting it back into Initial State and begin we can move from Initial to Recording, but Begin also can have a reset semantic when individual reset is allowed. Back to the issue, reset + begin in vulkan works fine (cur state -> Initial -> Recording), transferring this into dx12 would mean  (cur state -> recording -> recording!), which is not legal)

Thanks for clarifying! So we do have dedicated command allocators for the command buffers that are individually reset?

CommandList::Reset in dx12 has a reset+begin semantic for commands buffers

Sounds like we are missing just a few bits then (what you said to be the state tracking):

on reset() just reset the command allocator and close the command buffer is it's being recorded
on begin() actually call CommandList::Reset


Fixes typespecs for Spear.read_stream/3

Minor typespec correction, allowing to pass the :all atom to Spear.read_stream/3.
The functionnality is already supported, this just fixes the spec.

Pull Request Test Coverage Report for Build 2e6a7eedc6fe2bf922a61a236c708747e6604a42-PR-81

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 100.0%

Totals

Change from base Build 1e5439e5b3c2089d023eb6e3bdcdeb65a9497a21:
0.0%

Covered Lines:
697

Relevant Lines:
697

💛  - Coveralls

Ah good catch thanks. At some point it would be nice to add dialyzer to the CI too so maybe it could find things like this

Yes, that would be nice. I’ve found a couple more places where dialyzer gave me warnings (I guess at first the stream name couldn’t be :all). I’ll open a new PR for those, if it’s ok with you.
It’s not a big deal, but it’s always better not to have dialyzer warn against things that actually work.
(Unrelated side note, volley’s doc is great, thank you for that).


Add ServerErrorHandler to inject dependencies in annotations

Motivation:

It seems good to directly inject ServerErrorHandler via a bean.
https://github.com/line/armeria/issues/5440

Modifications:

Introduced Optional<List<ServerErrorHandler>> serverErrorHandlers in the armeriaServer method to enable the injection of ServerErrorHandler beans.
Updated the configureServerWithArmeriaSettings method to incorporate error handlers.

Result:

Users can now define custom ServerErrorHandler beans and utilize an Armeria server that has been pre-configured with these user-defined error handlers.
Closes https://github.com/line/armeria/issues/5443

 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.You have signed the CLA already but the status is still pending? Let us recheck it.

Would you add test cases to check if injected error handlers are correctly performed?

@ikhoon Thanks for your feedback. I added some commits!

Could you check the lint failure? Everything else looks good.

@ikhoon Thanks, I fixed code styles and also checked the lint!


NullReferenceException in comprehension expression

The following code raises a NullReferenceException:
x = [[[1]]]
[[tuple(str(d) for d in z) for z in y] for y in x]

SystemError: Object reference not set to an instance of an object.

The failure above is extracted from test_calendar (which we don't run during CI). I ran a git bisect and looks like the failure started occurring with https://github.com/IronLanguages/ironpython3/pull/1073.

@isaiah @BCSharp any ideas?


Merging of login and signup pages

I want to work on this issue under JWOC

I want to work on this issue under JWOC

Go on

I want to work for on this issue under jwoc , please assign me

I want to work for on this issue under jwoc , please assign me

Give it a try

@mrbhatt2348  you told me to go on and so I started my work
Shall I drop

I will work on this task
On Tue, 21 Feb 2023 at 12:00, Manasa Kaza @.***> wrote:

@mrbhatt2348 https://github.com/mrbhatt2348 you told me to go on and so
I started my work
Shall I drop
—
Reply to this email directly, view it on GitHub
https://github.com/mrbhatt2348/iBlog/issues/72#issuecomment-1437924732,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQEM2AXYVFYDTGWHPQTTPHDWYROIBANCNFSM6AAAAAAVAXOKOI
.
You are receiving this because you were assigned.Message ID:
@.***>

please close this issue i will complete this task under jwoc

I want to work on this issue under JWOC


Fixing a dependency convergence issue

Fixes #4175

@garrettjonesgoogle, thanks for your review, and all of the internal discussions.  We will not proceed with this PR.


No result when specifying created_at and/or updated_at columns

Version
1.18.0
What happened?
I get no results when using created_at or updated_at columns in SELECT statement. If i leave out the two columns then i get the expected results.
I've run the query including created_at and updated_at using DBeaver and it works correctly.
Relevant log output
No response
Database schema
CREATE TABLE jobs (
    id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    template_id BIGINT NOT NULL,
    status INT NOT NULL DEFAULT 1,
    report json,
    created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (template_id) REFERENCES job_templates(id)
);

SQL queries
-- name: ListJobs :many
SELECT
    j.id,
    j.status,
    j.created_at,
    j.updated_at,
    jt.external_ref,
    jt.url,
    jt.job_schema,
    p.common_name as provider_name
FROM
    jobs j
    INNER JOIN job_templates jt ON j.template_id = jt.id
    INNER JOIN providers p ON jt.provider_id = p.id
WHERE
    j.status = ?;

Configuration
version: "1"
packages:
- name: "mysql"
  path: "."
  queries: "./query/"
  schema: "../../db/migrations/"
  engine: "mysql"
  emit_json_tags: false
  emit_db_tags: false
  emit_prepared_queries: false
  emit_interface: false
  emit_exact_table_names: true
  emit_empty_slices: true

Playground URL
https://play.sqlc.dev/p/383409dd75455f035516b8b5a44074ba4c8c06d46ba1149402d1817921364b09
What operating system are you using?
Linux
What database engines are you using?
MySQL
What type of code are you generating?
Go

I'm not able to reproduce this behavior. I added your query to the playground and I'm seeing the created_at and updated_at values being scanned correctly.


:bigbrain:

I made some changes in toolchain. you can update to newest version :soyboy:

Big bet. Okay, I'll do that soon


cmd/5g: ICE regfree: reg R0 not allocated

go version go1.3beta2 +708e129e91a9 Wed May 21 16:01:54 2014 -0700 linux/amd64

The program is:

package p
var c0 []chan int
var s0 []int
var s1 []**int
var i = 0
var boom = cap(c0[s0[len(c0[**(s1)[s0[s0[**s1[s0[s0[s0[i]]+1]-1]]]]])]+1])

$ GOARCH=arm go build src.go
registers allocated at
0 409644
1 409bcf
2 409473
3 40a11c
4 40a11c
5 409bcf
6 409bcf
7 40a42d
8 40a7b4
9 0
10 0
src.go:6: out of fixed registers
src.go:6: internal compiler error: regfree: reg R0 not allocated

6g and 8g compile successfully.

 Also SSA will eliminate this entire class of bugs, so probably not worth fixing anyway.

Fixed with SSA backend.