Confusion: Two packages with the same name

What's the difference between this and https://github.com/thebuilder/react-intersection-observer
Both are almost identical in many ways, and actively maintained. Which one should I choose?
Thanks!

Hi, you're right that they're both actively maintained. Both packages have solid APIs and are durable. Pick what works best for your case by having a look at the docs and examples.
This library used to have the advantage that it reused instances based on the prop serialization automatically. Both things are also now available in the other one (although you need to use the prop rootId and keep track of that manually.
Another subtle difference is that we handle refs internally for you, so you don't have to specify the "mount" node (we will find it for you).
Ultimately, we also do not have a triggerOnce prop, we found that it ambiguous and removed it in favour of a callback argument on onChange.
In the end, both libraries allow you to do the same and are performant and small in size at this point in time.
Overtime, some projects grow apart and others they grow closer in behavior. We developed this library internally at ResearchGate and use it in production very extensively, so back then we decided to open source.
I hope that clarifies things a bit more. The decision is yours!

Thank you for the excellent answer! I will definitely have to think about this, both look so great! 👍


Microsoft's ApiPort.exe reports FSharp.Core.dll to be only 95.78% compatible with .NET 4.6.2

I ran Microsoft's ApiPort.exe report to two dlls, FSharp.Core.dll and FSharp.Data.SQLProvider (which has no dependencies but FSharp.Core) and even though they are created with .NET 4.5.1 the Microsoft compatibility checker claims they are not compatible.
Also running on .NET 4.6.2 gave same errors.
Here is the results: http://thorium.kapsi.fi/copy.html
Microsoft/dotnet-apiport#304

@Thorium
Based on reply from @terrajobst on the your dotnet-apiport issue 304 this is an issue of ApiPort, not FSharp.Core,
We should isolate this as ApiPort issue based on the reply from the dotnet team, not FSharp.Core issue. I suggest we close this issue.
cc @cartermp @KevinRansom @dsyme


Commands hang with circular variable

Very small issue -
When an output is used as a variable to the stack that creates the output stacker hangs rather than errors.
E.g.
 -name: main-vpc
    variables:
        TestVar: ${main-vpc::TestVar}
This is an invalid variable, but it should detect that rather than hang indefinitely.

@syphon7 thanks for noticing this, will try to get it cleaned up asap.


Add support for @internal

Per #34 you can manually exclude files/folders from analysis - this is time-consuming, impractical for existing projects, and places meta-information about the API and source-code in a tool-specific configuration file.
#8 proposes to add support for the @api annotation - this is once again time-consuming and impractical if most of your API is public. It's also inconsistent with PHP itself, where every source member is public by default - adding a single @api annotation would mean that the tool needs to make the opposite assumption: that everything is internal by default. (Adding a even a single @api annotation would effectively need to mark your entire codebase as internal.)
I propose to add support for @internal instead, providing a means of excluding classes, interfaces, traits and methods/functions from affecting the version number.
Explicitly marking specific members of your codebase as internal makes it easier to progressively flag portions of your API as internal. With everything being public by default, it's more in tune with how PHP works, and more consistent with how doc-blocks work in general - narrowing types for static analysis, adding tigher constraints than is possible with PHP; similarly, this will narrow the scope of the public API.
To support the @api annotation, you would need to turn the visibility rules upside-down, effectively rendering the @internal annotation useless - since the presence of a single @api annotation would implicitly flag the entire codebase as internal.
I was very involved in the development of PSR-5 and was strongly opposed to the definition of the @api annotation for these reasons - a single annotation-type should not be able to nullify another annotation-type entirely.
I plan on taking this up with the new working group as soon as possible.
In the mean time, I'd encourage you to stick to established PHP and doc-block paradigms - starting with support for @internal as opposed to @api addresses the need to control public/internal visibility just fine, and in a more explicit and predictable manner.
I wouldn't put my money on @api until PSR-5 is officially approved, and I will do my best to make sure it's definition is changed before that.

Cross-linking https://github.com/Roave/BackwardCompatibilityCheck/issues/51
Generally ACK on @internal, while @api is an outlier only used within the Symfony packages: we have public for that for a reason :-)

we have public for that for a reason

Not sure what you mean?
The public keyword doesn't work on classes, interfaces, etc.
From my understanding, that's the main reason the idea of something being "internal" even exists?

I'm just saying that @api makes little sense - easy to forget to add it, too late to do it after a release anyway.
I'll likely work on supporting both on the other package, although only @internal support will be enabled by default.

Gotcha :-)
I've started a thread on the FIG board proposing to change the definition of @api in the annotation-types PSR which will likely split from PSR-5.


[BUG] Display logs when IO drivers failed to read from OSS or HDFS

Describe the bug
as titled. for easier debugging.

See also https://github.com/v6d-io/v6d/pull/1035


Proxy POC

Small experiment mainly for fun and digging a little deeper into Proxy

Codecov Report

:exclamation: No coverage uploaded for pull request base (v2@feaa59d). Click here to learn what that means.
The diff coverage is 25%.

@@          Coverage Diff          @@
##             v2       #9   +/-   ##
=====================================
  Coverage      ?   55.38%
=====================================
  Files         ?        5
  Lines         ?       65
  Branches      ?       11
=====================================
  Hits          ?       36
  Misses        ?       23
  Partials      ?        6

Impacted Files
Coverage Δ

src/useSynapse.js
66.66% <ø> (ø)

src/Store.js
40% <25%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update feaa59d...5439108. Read the comment docs.


[FEATURE] - Reuse embeddings

Is your feature request related to a problem? Please describe.
It would be really nice to be able to re-use embeddings across application instance restarts, especially in the inner loop cycle. For example, if my application computes embeddings on startup I may only want to do that once while I am working on a feature. Sometimes the computation can be time consuming. The only current solution is to switch to an InMemoryEmbeddingStore, which already supports this feature.
But what if I want this feature when using some other embedding store? Currently its not possible. And maybe it won't be possible for all store implementations, in which case thats fine. But each store should be allowed the option to provide that functionality.
Describe the solution you'd like

Currently the InMemoryEmbeddingStore implements some methods that solve this problem.  There are several serializeTo... methods that write out the contents of the embedding store.
I'd like to move these methods "up" to the EmbeddingStore interface. I would make default implementations of them which throw some unsupported exception, so it would preserve backwards-compatibility. With this particular change, only the InMemoryEmbeddingStore would continue to implement the functionality.
But future enhancements/PRs could implement the functionality for other embedding stores.
One challenge I see though is that from... methods which populate an embedding store from some other source are declared static in InMemoryEmbeddingStore. We'd have to potentially deprecate those and introduce instance-level ones, or introduce some kind of factory that knew how to instantiate the correct implementation type.
Again, though, everything should be done in a backwards-compatible manner and no other embedding store providers would be touched as part of this change.
Additional context

If we all agree I'm happy to take this on and work on it. Just wanted to propose it before spending time on it to gather feedback.

Thank you @edeandrea for your suggestion! Embeddings are indeed calculation-heavy and typically calculated only once in the application lifecycle, and then updated when the source documents change.
Do I understand correctly that you would like to have a way to persist EmbeddingStores over instance restarts? I believe all EmbeddingStores except the InMemoryEmbeddingStore are persisted automatically and behave mostly like a normal database.
The main advantage I see in adding serializeTo... and from... methods also for the other types of EmbeddingStores, is to have a common intermediary format to mirgate Embeddings from one EmbeddingStore implementation to another. Is that what you are after?

Thanks for the note @LizeRaes !
That's not exactly what I was looking for but is a nice thought!
I agree, that in production this feature would most likely not be used, as a "real" embedding store would maintain the embeddings between application restarts.
The use case I'm solving for is the inner loop development cycle. Perhaps the user uses testcontainers/docker compose/etc to stand up a "real" embedding store while they are doing dev. Each time testcontainers/docker compose shuts down, the computer embeddings are gone. This feature would allow the embeddings to be written to the filesystem so that they don't need to be re-computed.
I am being somewhat selfish too, because my main purpose for this feature is with the quarkus LangChain4j extension, which would use this feature in its dev mode/live coding.
Currently if I'm using a real embedding store, each time I make a code change it needs to recompute the embeddings and re-store them.
I've already implemented this feature for the in-memory embedding store, because that store already exposed the capability.
See https://docs.quarkiverse.io/quarkus-langchain4j/dev/easy-rag.html#_reusing_embeddings
Does that make sense? Again, probably not a feature that will be widely used in production, but definitely a time-saver in inner-loop development.

each time I make a code change it needs to recompute the embeddings and re-store them

This sounds strange, why? There are only 2 reasons where you need to recompute embeddings:

You chose a different embedding model (embeddings generated from different models are incompatible).
You change the chunking algorithm.

Each time testcontainers/docker compose shuts down, the computed embeddings are gone.

Sorry, I'm not an expert in Docker, but I see N ways to solve this:

You should use a real vector database.
Then, you look up how the data is persisted on disk.
And when Docker container is shutdown, before that do a backup.

For example, there are pgvector extension for PostgreSQL and sqlite-vss extension for SQLite. And you can very easy backup the results in an .sql file dump.
You can also not use a Docker container, but start it locally on your computer.
However, the easiest method is to find an *embedded vector database (just like SQLite is an embedded database). That would be like a library and store everything in files. But unfortunately, every vector database requires a dedicated server

each time I make a code change it needs to recompute the embeddings and re-store them

This sounds strange, why? There are only 2 reasons where you need to recompute embeddings:

You chose a different embedding model (embeddings generated from different models are incompatible).
You change the chunking algorithm.

I agree 100% that in production this is how things will work. As I stated, this feature is more meant for local development/inner loop.

Each time testcontainers/docker compose shuts down, the computed embeddings are gone.

Sorry, I'm not an expert in Docker, but I see N ways to solve this:

You should use a real vector database.
Then, you look up how the data is persisted on disk.
And when Docker container is shutdown, before that do a backup.

This is just not how the real world works. When a docker container shuts down, data is gone, especially when using ephemeral filesystems. Application frameworks like Testcontainers make using "real" things (vector databases, relational databases, message brokers, etc) trivial during development time. The part that makes it trivial is that the containers are ephemeral.
Think about a relational database for example (Postgres/MySQL/Oracle/etc). During development, if I start up a database container, my application will need to create a scheme and potentially pre-load some data. Frameworks like Hibernate support this - the data I want to pre-load is available on the filesystem and things just work. In production, the "real" database will already be running somewhere, the schema would have already been created, and data would already exist. What I'm trying to do here is the same thing, conceptually. I'm trying to solve a time-consuming use case when doing development.

For example, there are pgvector extension for PostgreSQL and sqlite-vss extension for SQLite. And you can very easy backup the results in an .sql file dump.

Yes thats true, but its not a common way that developers work today. It would be nice if I could just run Docker Compose or something (or use the Testcontainers library), so that when my application starts it also starts a "real" vector database (millvus/chroma/pgvector/etc), populates it with some data, and then runs. When my application stops, the vector database container is torn down. This is a very common development lifecycle.

You can also not use a Docker container, but start it locally on your computer.
However, the easiest method is to find an embedded vector database (just like SQLite is an embedded database). That would be like a library and store everything in files. But unfortunately, every vector database requires a dedicated server

Using a container and a framework like Testcontainers is pretty common nowadays, so starting a vector database locally on my computer isn't something I should need to do. Many developers don't have permissions on their local computers to install things.
Java Frameworks like Quarkus and Spring, for example, support this development model right out of the box. Thats what I'm trying to solve with this enhancement.

Hi @edeandrea, I am not really sure you need to alter EmbeddingStore interface in order to implement this feature in Quarkus extension.
All the embeddings can be exported by calling embeddingStore.search(EmbeddingSearchRequest.builder().queryEmbedding(dummy).maxResults(Integer.MAX_VALUE).build())
And then imported using EmbeddingStore.add() or addAll() methods.

Thank you @langchain4j for the info! I wasn't aware that was there. Let me experiment with it a bit. I'm going to be out on PTO for a couple of weeks, so it may be a bit before I report back.
If you'd prefer to close this issue for now I can reopen it if I have further questions. Or you can leave it open. Up to you!

@edeandrea ok, no rush! I will close the issue (as we will probably forget about it), but feel free to reopen if needed. Enjoy your PTO! :)

@edeandrea sorry for the late reply! I hope the embeddingstore.search()method solves your problem, and thanks a lot for your efforts to include 'hot loading' of embedding store changes into Quarkus' awesome dev mode!

Thanks @LizeRaes ! Maybe I'll have something by the time of our workshop at Devoxx Belgium!


I want to add hover effect on social media icon in sign in page..please assign me this.

There is no hover effect on social media icons,while hovering . It will look much better ,if will add that..please ASSIGN ME THIS.

I could add a glassbox effect for the sign in and connect us page, please assign me this.


batchPut() does not respect default value

Summary:
When running Model.batchPut() on a schema with default value being generated with i.e. UUID, the batch has the same UUID assigned to each item.
Code sample:
User model
const uuid = require('uuid/v4')
const modelSchema = {
  email: {
    type: String,
    hashKey: true,
    required: true,
    lowercase: true,
  },
  id: {
    type: String,
    index: {
      global: true,
      project: true,
    },
    required: true,
    default: uuid(),
  },
}

Let's say I want to seed the DB with an array of users with fake names, no ID generated yet in the seed source:
Seed
const users = []
let i = 10
while (i--) {
  const user = {
    email: i === 0<EMAIL_ADDRESS>: faker.internet.email(),
  }
  users.push(user)
}
User.batchPut(users, (err, data) => {
  console.log(err ? JSON.stringify(err, null, 2) : '🌱 users table seeded.')
})

Current output and behavior:
And I end up with 10 users with the same ID.
Environment:
Operating System: macOS
Operating System Version: Mojave
Node.js version (node -v): 10.15.3
NPM version: (npm -v): 6.4.1
Dynamoose version: 1.10.0
Dynamoose Plugins: none
Dynamoose Plugins:

[ ] Yes, I believe that one or multiple 3rd party Dynamoose plugins are effecting this issue
[ ] No, I believe this issue is independent of any 3rd party Dynamoose plugins I'm using
[ ] Unknown, I'm unsure if Dynamoose plugins are effecting this issue
[X] I am not using any Dynamoose plugins

Other information (if applicable):
Type (select 1):

[X] Bug report
[ ] Feature suggestion
[ ] Question
[ ] Other suggestion
[ ] Something not listed here

Other:

[X] I have read through the Dynamoose documentation before posting this issue
[X] I have searched through the GitHub issues (including closed issues) and pull requests to ensure this issue has not already been raised before
[X] I have searched the internet and Stack Overflow to ensure this issue hasn't been raised or answered before
[X] I have tested the code provided and am confident it doesn't work as intended
[X] I have ensured that all of my plugins that I'm using with Dynamoose are listed above
[X] I have filled out all fields above
[X] I am running the latest version of Dynamoose

@rkrayovskyy That code won't work and is not a bug in Dynamoose.
Currently you are setting default to uuid() which is a string. Therefore default is a static string that will be the same every single time.
The default setting in Dynamoose also excepts a function that will be called every time it's used.
Changing your code to:
default: () => uuid()

OR
default: uuid

should work.
Basically that will pass in the function instead of the value itself.


Allow core-lib declarations to be ignored

At the moment I cannot find a way to ignore the core-lib declarations at startup.
It would be nice if we could provide our own declarations. This would allow us to fix problems with the core declarations that are out of sync with the spec.
See for example: https://github.com/facebook/flow/pull/113 or https://github.com/facebook/flow/pull/108

You can use --no-flowlib to ignore the builtin libs.


Update CHANGELOG.md

Modify linux-raspberrypi_%.bbappend: Use filesystem labels for the root cmdline kernel parameter [TheOnlyZby]
Modify 99-rpi-bootloader hostapp hook to work with Partition Labels instead of physical mount point [TheOnlyZby]

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

Can one of the admins verify this patch?

@theonlyzby this needs to be include in the same branch as https://github.com/resin-os/resin-raspberrypi/pull/166 . Make no sense to have two PRs for it.

Wait. You have 3 PRs as I see. Can we merge them all in the same branch and push only one?

... Yes, we can group, my fault for sure as I am not yet fully accommodated with GitHub ... my bad, but I try to learn and at least, I try ;-)

Don't worry about it. You'll get use to it after 1-2 PRs.

OK, thx for being so indulgent towards noobs like me :-) ...I was so enthusiastic to be part of this small step towards an even better resin on the Raspberry that I published my first mod and then thought it is not enough, we need the switching script ... and today declared both mods into changelog.
Will try to do it better next time 8-]

I know you will. I'll close this PR for now and wait for you to push to one of the already existing ones.


Issues on exporting skinning data

Hey! First of all, amazing work with the "Edit Mode" of the Museum! It's amazing that you made this work directly from the website, I wasn't expecting that!

So far, I only managed to replace Maria's mirror model, which shows up at the beginning of Born from a Wish. I couldn't for the life of me manage to figure out where Maria's actual player model is stored. Which actually leads me to a question from me: Is there some sort of file list somewhere, which helps localize which character .mdl files are used, and for which "situation"? That would really help a lot.
Now, the actual issue is that it seems like the tool won't accept skinning data from the given .gltf, resulting in the model just standing up with no animations.
If I can provide any resource to help with this just let me know, thank you in advance!

hey Raq1! thanks for trying out the editor :)
i'm sorry that the tool is not super easy to use right now! i'd really like to document everything, unfortunately i have limited time/bandwidth on this project so it is a somewhat slow process.

Which actually leads me to a question from me: Is there some sort of file list somewhere, which helps localize which character .mdl files are used, and for which "situation"? That would really help a lot.

there isn't a list (although that would be SO useful), but i highly recommend using microsoft's process monitor as it tells you exactly what files a process is reading and writing. it's what i've been using, here are my settings (only the first three aren't default):

Now, the actual issue is that it seems like the tool won't accept skinning data from the given .gltf, resulting in the model just standing up with no animations.

if you haven't already, could you try setting bonemap to "by name" and then clicking "reset model"? then playing with the bone controls to make sure it worked. if that doesn't work, you might have luck with bonemap "auto", or can adjust it with "manual".
i hope to write up all about this soon and/or change the language so it's more easier; if you have suggestions on how to do that feel free to let me know!

I also use Firefox. It sounds like your page is erroring, I'm guessing you don't see an error in the custom console -- could you try opening the actual JS console on Firefox (ctrl+shift+j) and see if it gives you an error?
Also, for "by name", you'll have the best chance of success if you're replacing the same model you exported as GLTF.

Ok it seems like it might've just been something that was happening in that moment for whatever reason, I tried again and it's working fine. Thanks again!

great! I'll leave this issue up for visibility while instructions are still lacking 😅
feel free to let me know if you have more questions!
btw, if you haven't already, check out the trailer i made! https://dev.silenthillmuseum.org/posts/trailer/
looking forward to seeing what you all come up with :)

Haha that trailer is so cool! It's really nice to see how many things are possible with this!
Before venturing into trying to replace Maria's model and figuring out which is her player model, I thought I'd try replacing Angela since she only has a single mdl file. Here's a test where she's replaced by Lara Croft from Tomb Raider: The Angel of Darkness

The only problem is that it seems like there's issues with the normal vectors, they seem to be a little corrupted, the side of her arm is brighter than the rest of the model. But that could also be due to some GLTF export settings from Blender, I haven't experimented with that too much.
Also facial animations are a limited since there's no blendshape support (Lara is only able to open her mouth thanks to the jaw bone, but she can't blink or make mouth shapes); but it's still so cool to see custom models in action in this game!

thanks for trying it out @Raq1 !
heads up that i am aware of an issue with slight error in the normal vectors. as far as i can tell, the error is so small that it might be an accumulation of floating point error, but i am not sure atm
and yep about facial animations, i do have those documented, just no official support in the museum yet

hi @Raq1, i've just merged a change that should improve the accuracy of the normal vectors; feel free to check it out if you get the chance
https://dev.silenthillmuseum.org/posts/winter-2024/


obi clean should also clean the bin/ directory

(or the bin/ directory should not exist)

cmake offers a make clean, I believe, so a pre-clean-cmd which calls that would work (if pre-clean-cmd is a thing)

Turns out the make clean target that CMake generates doesn't clear anything out from the bin/ directory. Rats.

Let's stop moving our build artifacts outside of the build directory. This change impacts the obi templates and requires no code change in obi. Closing.


Introduce top-level container

Should we think about introducing a top-level container (e.g. turning article node into a container node). That way the the body, back, etc. elements become accessible as an isolated node. E.g. select body node and review/change attributes.

Just activated caption editing. However the clicking-through seems to be broken for inline isolated nodes.  The focus gets lost immediately. @oliver---- can you check?

I don't think that this is necessary.


Enhancement - GlideX support

Hi Daniel,
I use FFimageloading extensively in my XF Android app. Thank you.  Recently stumbled upon GlideX for XF Android.
As Glide is recommended even by google for images in Android the performance gains is huge especially in memory consumption as can be seen on their GitHub page.
https://github.com/jonathanpeppers/glidex
please consider as an option glidex compatibility in future enhancements of FFimageloading as I think it will make this lib super performant on Android.

It's a nice idea, but to allow things like cross platform transformations and shared configuration it won't be easy to integrate. I would prefer to replicate the same mechanisms as glidex uses for image caching. I have already started working on this, but don't have much free time lately.

BTW: new prerelease nuget should be a lot more performant, especially on Android.

Currently, FFImageLoading's memory cache cache works the same as Glide's memory cache (LRU bitmap cache + reusable bitmap drawables cache). What we should concentrate is:

optimize code and limit .NET objects creation to prevent a lot of GC calls.
Tune default settings as DecodingMaxParallelTasks, SchedulerMaxParallelTasks, default cache size, etc

BTW: You can now easily use FFImageLoading with standard views like Xamarin.Forms.Image. Just call this after Xamarin.Forms.Init call:

CachedImageRenderer.InitImageViewHandler() on Android
CachedImageRenderer.InitImageSourceHandler() on iOS / Mac and others

Thanks @daniel-luberda , enjoy the coffee ;)
I assume we can then replace CachedImageRenderer.Init() with CachedImageRenderer.InitImageViewHandler()  to do both existing functionality + Xamarin.Forms.Image  ?

Thanks! Yes, both are needed :)


Error in documentation

Step 10 of this readme is not correct. This is a copy paste issue from the TypeScript documentation:
https://github.com/aws/aws-rfdk/blob/mainline/examples/deadline/All-In-AWS-Infrastructure-Basic/python/README.md

Thanks for reaching out. I agree that it looks weird to see a command for a Node.js tool in the middle of a README for a Python application, but that's actually not an error.  You'll see the same in our developer guide here: https://docs.aws.amazon.com/rfdk/latest/guide/first-rfdk-app.html#stage-docker-recipes
The reason for the strangeness is that our stage-deadline command-line tool is currently only available in the Node.js package for the RFDK, so you have to use npx to run that command from the Node.js package. We are working on bringing that command-line tool into the Python package for RFDK, but we're not there yet.

I think @koenverwimp might be referring to the references to modifying package.json. Those shouldn't be there.

Yes, it does look strange to me that i have to configure the deadline version in the package.json and as an environment variable? Even if it so, it's not clear.  The first RFDK app doesn't mention anything about package.json, and seems to work without it.

I think the "bin/config.py" should as well be "package/config.py".

I think the "bin/config.py" should as well be "package/config.py".

Ah, right you are! Thanks for pointing that out.

According to the documentation I have to add my UsageBasedLicenses
"5. Choose your UBL limits and change the value of the ubl_licenses variable in bin/config.py accordingly:
self.ubl_licenses: List[UsageBasedLicense] = [ (e.g. UsageBasedLicense.forMaya(10))] "
When I try to do this, i get an error. For some reason it cant find the static method.
Any advice?
self.ubl_licenses: List[UsageBasedLicense] = [ UsageBasedLicense.forMaya(10) ]
AttributeError: type object 'UsageBasedLicense' has no attribute 'forMaya'
Subprocess exited with error 1

PS: i am using aws-rfdk==0.17.0 ... in your example this is still pointing to 0.16.0

Thanks for pointing this out and helping fix this for those that follow in your footsteps. I'll put together a follow-up PR for these new findings.

It would also be great if there was any explanation how to connect with Deadline Monitor to the RCS fleet. Or did i miss something in the documentation? I guess i need to create a PFX file from certificates that i can find in AWS secret manager? But i didnt get it to work so far.

It would also be great if there was any explanation how to connect with Deadline Monitor to the RCS fleet.

Agreed - this is important documentation that is missing. I've created a separate issue (#110) to track this.

Re-opening this. #106 auto-closed this after merge, but UBL issue was not addressed


Exposed credentials

Describe the bug
According to my Gitguardian (gitguardian.com), an API key has been exposed in the example/lib/main.dart file.
Expected behaviour
For example, the user should provide its API key
Screenshots
If applicable, add screenshots to help explain your problem.

Hi @NemesisX1
Thanks! We will remove it.


drop csvs, we'll start publishing on S3

Pull Request Test Coverage Report for Build 786

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

Totals

Change from base Build 766:
0.0%

Covered Lines:
931

Relevant Lines:
1496

💛  - Coveralls


fixes #1858: added a save command

Description & motivation
Added an additional step to save the file in the documentation.

Prerelease docs

[ ] I've added versioning components, as described in "Versioning Docs"
[ ] I've added a note to the prerelease version's Migration Guide

I'm not sure whether I've to update Versioning docs for these changes. If needed, please let me know.


Cleanup make output in run-cbmc-proofs.py

This pull request adds strip_make_output to run-cbmc-proofs.py to clean up the standard output of make when invoked by subprocess.  The progress information being deleted was observed when trying to write another script using subprocess to invoke run-cbmc-proofs.py itself.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

I just had a cursory glance at cbmc-viewer #57 and it definitely seems like you could use --no-standalone to great advantage there.
I might call you tomorrow to pick your brains about exactly what you're doing, but: it seems like you're running Litani, and then doing a 'post-processing' phase using the finished run.json. What I suggest instead is to use Litani itself to run the tests. That way you don't have to wait for every single HTTP proof to finish before commencing the viewer test run: instead, each viewer test will start as soon as that one proof finishes.
The idea is that the report job of each proof should specify that it emits the 'viewer.json(and other files) as outputs, using the--outputflag to Litani. Then you add some additional Litani jobs, which take those JSON files as inputs: those are your test suite. Then you run the whole lot. This is one of the many cases that the--no-standalone` flag was intended for, to extend your proof run with arbitrary additional jobs that Litani can run for you.


403 when trying to download image

Getting
error: unable to download 'https://swcdn.apple.com/content/downloads/46/31/052-96247-A_MLN9N00Y8W/dmml3up52hrsb01krjtczmdhexiruv1b5m/InstallAssistant.pkg': HTTP error 403
Has anyone else seen this?

Yeah, Apple deletes the image from time to time, so we have to get the latest, or find the old one somewhere archived on the internet where we can fetch it.

Actually, looks like this isn't the case this time. If you're experiencing a 403, that means Apple is forbidding you personally based on some criteria. Perhaps due to your network.

Done! You have to trigger Hercules somehow?

@aciceri the HCI build is triggered be me pulling and pushing your branch like this:

git fetch origin pull/36/head:pr-36-ci
git push origin pr-36-ci

The build is ongoing here https://hercules-ci.com/github/MatthewCroughan/NixThePlanet/jobs/487


Update index.py

Fix for issue #75

Fix is tested and works as expected

I have added this to my build since the original does not seem updated anymore
docker pull maddemonoide/syncarr:2d916874faede59e777e1bc3289170d604885684
https://hub.docker.com/r/maddemonoide/syncarr
https://github.com/markschrik/syncarr


socrata integration

I think the extractor should send data to Socrata rather than having the comport app do it. I'll move this issue there.


Create canister type definitions for all system canisters

System canister definitions I think should be included in Azle

Duplicate: https://github.com/demergent-labs/azle/issues/241


update dependencies

Initially did this PR to update ember-simple-auth dependency.
This was forcing apps to use a previous version which introduce some deprecations on the consuming app.
Also updated the project's dependencies and got rid of some deprecations:

stop using Ember.merge
stop using Ember.Logger
stop using new with EmberObject subclasses

Also bumped other dependencies.

@XaserAcheron any news on this?

Sorry, I haven't had the time. I can't hit the "merge" button on this because Snyk is complaining at something, and I'm not sure what the correct path forward is just yet.

Whew, all good now -- sorry this sat in limbo for so long, @miguelcobain, and thanks so much for the help!


Add podman client

@taowen19 Can you clean your changes a bit. I see there's a lot of commented section, that I'm not sure if they are to be removed or just commented out for testing.

@taowen19 For testing, I would suggest trying to run it in something like a Fedora VM with podman installed.
We can worry about deploying it to Openshift/ROSA after, since it probably require some extra permissions from the cluster.


Virtual Init method for NodeGraphEditor

Currently there is no any method that's called for initializing your gui stuff, since it doesn't inherit from ScriptableObject nor, Behaviour.

Might wanna put this on here instead https://github.com/Siccity/xNode/issues


[BUG] latest S2I version is now v1.3.6

Various parts of this Action reference S2I v1.3.1 (and it's short hash a5a77147). The current latest versions of S2I is v1.3.6 (short hash cd7d7ce9). Please consider updating the action.

Latest version of s2i has been updated to v1.3.9

You can find the latest version in the release v2 and v2.4


kustomize: Add operate-first overlay

Add an overlay for operate-first (copy the dev one and change hostname overrides)
This should include a production dex config.
Related to https://github.com/operate-first/support/issues/1154
Since we'd require the use of externalsecrets to securely store credentials used for GitHub authentication.

@dave-tucker I think this is complete. Is there anything else you want to track with this?


Make all our flag names consistent with dashes instead of underscores

Update all command line flags defined in this repo to be consistent, using dashes instead of underscores. For example, --install_cluster_controller should be --install-cluster-controller.
Make sure to update all references to changed flags, including e.g. demo scripts and e2e code.

@kcp-dev/kcp-prototypers do you think we should do this?

This is probably a perfect candidate for help-wanted and good-first-issue labels, if someone is looking for their first commit.  👍

👋 I would like to give a try to this one if it's ok.

/assign


chore: connfigure ruff etc

@NagariaHussain could you help with this pure maintenance PR? Goal is to allow to work with more updated tooling in downstream forks without major diff problems when time to upstream is ripe.


Access shares with owner's URL, not virtual path

Current OCIS, as tested in https://ocis.owncloud.com works in the following way when accessing shares.
Workflow: Katherine shares my folder with Einstein.
Logged in as Katherine
https://ocis.owncloud.com/files/spaces/personal/katherine/myfolder?fileId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%24534bb038-6f9d-4093-946f-133be61fa4e7!33ca5587-29fd-48f3-abba-8305f57ad2b5&items-per-page=100
Logged in as Einstein
https://ocis.owncloud.com/files/spaces/share/myfolder?shareId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%3A534bb038-6f9d-4093-946f-133be61fa4e7%3Ab52d90fa-80ec-4b6b-a306-edcbd918dbbd&fileId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%24534bb038-6f9d-4093-946f-133be61fa4e7!33ca5587-29fd-48f3-abba-8305f57ad2b5&sort-by=name&sort-dir=asc&items-per-page=100
Each recipient has its own share URL, relative to the user (in this case shareID=166...), that means if you send it to another person that person (even he has access), won't be able to access it.
CERNBox
CERNBox use-case is that the recipient will be able to access the share by using the owner's URL:
https://ocis.owncloud.com/files/spaces/personal/katherine/myfolder?fileId=166d1210-cdb9-50ab-9f1e-ecb9ef12a304%24534bb038-6f9d-4093-946f-133be61fa4e7!33ca5587-29fd-48f3-abba-8305f57ad2b5&items-per-page=100
CERNBox url looks like this. They need to be the same in OCIS edge.
Personal
https://cernbox.cern.ch/files/spaces/eos/user/g/guse...
Workspaces:
https://cernbox.cern.ch/files/spaces/eos/project/a/aproject/...
Personal spaces and Work spaces
They already behave with a full path (relative to space root). Sharing is the one that differs from this model.
@dragotin @aduffeck

related: https://github.com/owncloud/ocis/issues/5355

Related draft pull request for Reva: https://github.com/cs3org/reva/pull/3836/files

In order to work on this in web, ocis needs some changes first...
use case 1: share the browser URL, with fileIds being disabled
description
einstein shares a personal folder Photos/2019/Norway with marie, then points her to the folder by giving her the browser URL:
https://owncloud.test/files/spaces/personal/einstein/Photos/2019/Norway
resolve URL in web
Because of the URL path segment /files/spaces/, web knows that this is a space URL. It will try to resolve a driveAlias + relativePath from the rest of the URL, namely personal/einstein/Photos/2019/Norway. That happens via comparison of the string to all known drive aliases (try with full string, if no matching drive alias is found cut off the last segment and repeat).
missing information from ocis

There is no API for finding einstein's personal space by drive alias when being logged in as marie. drives.listAllDrives only lists spaces marie is a member of (including her personal space). Spaces don't appear in the response when marie has a share to the space. I.e. having a share to a folder in einsteins personal space doesn't expose the space to marie. As a result:
a) web doesn't have a chance to find the matching drive alias for personal/einstein/Photos/2019/Norway
b) let me be clear: since web couldn't identify a space, it can't make webdav calls. From here on everything's broken. 💔
If (1) would be possible, it would be desirable to call drives.listAllDrives with a drive alias filter. Otherwise we would need to preload space meta data in memory in web. If a user has access to thousands of spaces that's rather inefficient.

use case 2: share the browser URL, with fileIds being enabled
description
Similar to use case 1, einstein shares a personal folder Photos/2019/Norway with marie, then points her to the folder by giving her the browser URL:
https://owncloud.test/files/spaces/personal/einstein/Photos/2019/Norway&fileId=1284d238-aa92-42ce-bdc4-0b0000009157%244c510ada-c86b-4815-8820-42cdf82c3d51!4c510ada-c86b-4815-8820-42cdf82c3d51
resolve URL in web
Because of the URL path segment /files/spaces/, web knows that this is a space URL. Since a fileId is present in the URL, web looks up the fileId in the preloaded list of marie's spaces and doesn't find it. This can easily be extended in web to call drives.getDrive with the fileId as param.
missing information from ocis

Calling drives.getDrive with a fileId that belongs to a space where marie is not a member will result in a 404 Not Found. Web needs at least the drive alias (for url path correction if needed) and ideally also the webdav url of the space (because for web we want to move away from concatenation of server url and relative webdav path and use the webdav url from the space instead, in order to make federation possible).

use case 3: navigate into share via Shared with me page
description
Similar to use case 1, einstein shares a personal folder Photos/2019/Norway with marie. Then marie logs in and visits her Shared with me page, accepts the share and then clicks on it.
construct URL in web
Web currently builds URLs for shares in the form of https://owncloud.test/files/spaces/share/norway?shareId=xyz&fileId=abc. We want to construct a URL like presented in use cases 1 and 2. Thus we need the drive alias in OCS shares responses.
missing information from ocis

Calling /ocs/v1.php/apps/files_sharing/api/v1/shares?shared_with_me=true should return drive aliases as they are from the share owners perspective in the response.

more ideas

The behaviour described above should not only work for accepted shares but also for pending and declined shares. Think of the end to end UX: marie would see some kind of "not found" page if she didn't accepted the share before entering the URL into the browser. Technically webdav access to pending and declined shares is already possible - as long as the grants exist the share state shouldn't matter.

@micbar how can we make this actionable? 🙈

We do not need to get the drives via graph. I have a reva pull request opened which exposes the space root alias and the space root is on a share. That was designed to mitigate the issues you describe here because i was not expecting that we can get a full drives listing for all drives where the shares are originating. We also do not need all that drive information.
I could provide an ocis branch where you could work against.

But why would we want that information on OCS if we want to move sharing to graph and not use it in OCS anymore?

We also do not need all that drive information.

Of course not. So far I can only tell that we want drive alias and webdav url to be exposed. What speaks against exposing that information via graph?

I could provide an ocis branch where you could work against.

@mbarz thank you for https://github.com/owncloud/ocis/pull/6300 - that seems to work and I would love to see it merged soonish. As a result I can already have share URLs identical for the share owner and all share receivers. Probably still has rough edges, but I'm getting there.
The next two prios for unblocking web would be (in that order):

provide the driveAlias and the fileId of the share owners space via OCS /shares response. Reason: For building the shared with me page with URLs like described above (with the drive alias and path from the share owner).

provide mountpoints in the /me/drives graph response not only for accepted shares, but also for pending and declined shares. Reason: if a share owner copies their browser URL and gives it to the share receiver (e.g. via chat) to point to the resource, the share receiver now needs to accept the share first before they can use the URL.

(1) is particularly important. (2) will be needed for a good UX.

Your welcome 😊
But I think you meant to thank @micbar

Your welcome 😊
But I think you meant to thank @micbar

Nono, just pinging you for fun from time to time. 😂🙈

realtes to: https://github.com/owncloud/web/pull/9159/commits/49e125f81c023e1c71d772d72b346a1cc0ac3f35


Why not support CocoaPods？

Why not support CocoaPods？
Unable to find a specification for PKHUD

How beautiful HUD like PKHUD, but why not support CocoaPods? good things need to shared conventience.

Use like so:
pod 'PKHUD', :git => 'https://github.com/pkluz/PKHUD.git', :tag => '1.0.0'

Currently no a public spec (only available via direct access) as CocoaPods 0.36b is required, which is not yet a final version.

thank you, I realized that ios8 has a new way to use framework, and I known your reason now.


Question on【multi-speakers】【self-datasets】 training

Hi, @kan-bayashi , ur jobs is great!

I countered some simple problem during training on myself multi-speaker datasets, which have the same files tree structure as u described in Read.me, with 80k wav utterances. However, when i followed there suggestions , and set num_dev = 100, num_eval = 100, set db_root  to the right path. Then i countered a traceback: num_first + num_second must be the same # utts in src .(200 vs 1)

I tried look into shell script, the 200 ==  num_dev + num_eval, and vs 1position original point to num_src_utts=$(wc -l < "${src_segments}")  ,where src_segments=${src_dir}/segments , and src_scp=${src_dir}/wav.scp, then i get really puzzled, why it turns out to be only1 ? There must be some details i missed, could u please help to point it out?

Then, to solve this problem, due to my usage of training pgan vocoder is to apply in Voice Conversion project, and i tried to use template_single_spk scripts, and set the num_dev = 100, num_eval = 100 again, while the file structures the same as multi-speaker task, the train process going on well.

However i noticed that, in the dump files, both dev & eval files contains only 100 wavs in .scp files, which separated into four .scp files. But, in the voc1/data/train_nodev file, the wav.scp can contain all available wavs in all speakers. **What i confused just: ** Does my setting on this way at this kind of file structure, can train on all the speakers' wavs well? And does it common to observe the dev/eval only contains num_dev = 100, num_eval = 100 files, despite there are 80k wavs in all speakers' files? Can other wavs apart of these 200 wavs be used for training PGAN vocoder ?
Sorry for my poor coding ability, hoping to get any useful suggestion on how to solve these two problems!
All the best,
Luke Huang

There must be some details i missed, could u please help to point it out?

In the multi-speaker template, we split train, dev, and eval for each speaker.
And then concatenate the train dir of all speakers (dev and eval as well).
Therefore, we assume that at least the number of each speaker utterances > num_dev + num_eval.

However i noticed that, in the dump files, both dev & eval files contains only 100 wavs in .scp files

This is because you set num_dev and num_eval to 100.

However i noticed that, in the dump files, both dev & eval files contains only 100 wavs in .scp files

This is because you set num_dev and num_eval to 100.
You will get three directories in dump:

train_nodev: training data without development data
dev: development data
eval: evaluation data

Thank u for ur reply!
And even when i set num_first = 1 and num_second = 1  , there still have traceback: num_first + num_second must be the same # utts in src .(2 vs 1), which i confirmed that every folder has .wav files > 100 files.

Please check here the found spks are valid.
https://github.com/kan-bayashi/ParallelWaveGAN/blob/53d14969089b3d3229fe6bfce221234f25a9d836/egs/template_multi_spk/voc1/run.sh#L69

There must be some details i missed, could u please help to point it out?

In the multi-speaker template, we split train, dev, and eval for each speaker.
And then concatenate the train dir of all speakers (dev and eval as well).
Therefore, we assume that at least the number of each speaker utterances > num_dev + num_eval.

Thank you sooooooo much! @kan-bayashi  !
I solved this problem that by print the number of .wav files that each files contains using for dir in CurDir/*;do ls $dir|wc -l;done . And surprised to find that one special folder has only  1 files. sorry to disturb u. U r sooooo nice, thank u again!

Above problem all caused by myself, and anyone else counter the same problem can check self dataset~

All the best!
Luke Huang


dev-cmd/audit: allow checksums to change when switching to/from a PyPI url

[x] Have you followed the guidelines in our Contributing document?
[x] Have you checked to ensure there aren't other open Pull Requests for the same change?
[x] Have you added an explanation of what your changes do and why you'd like us to include them?
[x] Have you written new tests for your changes? Here's an example.

[x] Have you successfully run brew tests with your changes locally?
[x] Have you successfully run brew man locally and committed any changes?

When possible for Python packages, it's preferable to use the PyPI url vs GitHub/other urls to allow for automatic resource bumps. However, in general, the checksum of the GitHub archive will not match the checksum of the PyPI source package. This means that the audit will complain that the sha256 changed without changing the version if a PR is created which only switches the URL to/from PyPI.
Supports https://github.com/Homebrew/homebrew-core/pull/64243

I think this PR is misguided. The goal of the checksum mismatch audit is purely informative: it tells the maintainer that something may be wrong, and that we have to check it and make a decision. As such, it is expected that it may be overridden from time to time, in justified cases. Therefore, suppressing the audit is not necessary.
I would also argue that suppressing the audit is a bad step: as a maintainer, I want to have this information. If a URL is changed, whether it's on PyPI or not, I'd rather be informed so I can check whether the content is actually the same. Imagine someone switches a PyPI URL to malicious content they host on github (or the other way around): I would rather be alerted of the issue, and check myself if there is a problem.
There are regularly packages that are updated without changing version number, and although I'd prefer it never happened, we have to live with that. Will we have to add an allow list, or adjust the logic of the code in brew every time? It does not seem desirable.

I agree that this is more of an informative audit vs a failure, but there isn't an option for a "non-failing warning" in the CI. PyPI URLs are a broad class where they could either be hosted on PyPI or GitHub, so an exception for it may make sense. Suppressing the fact that the domain changed isn't ideal, but neither is needing to merge a red PR.
If this could be done as a GitHub action label vs a CI check, that might be better, but I'm not sure how feasible that would be. It could even be more broad to cover domain changes in general, regardless of if the version changed.
@MikeMcQuaid indicated a preference for adjusting the audit logic here vs ignoring the audit failure, so I'll let him chime in with any additional perspective.

If we want to never merge "red" CI, then this is one of the audits that need to be removed (or find a way to silence it manually). But that does not seem desirable at all to me…

Another possibility is to have CI pass a flag to the audit command when a manual "version checksum mismatch allowed" label is applied. It could then skip this check alone which would both give a green CI as well as flag it for reviewers to verify that the URL change makes sense.

@dtrodrigues I am fine with that, but I think in the longer term there could be other “informative” audits of interest. We probably need to figure out a way to implement a two-level audit (errors and warnings)

If a URL is changed, whether it's on PyPI or not, I'd rather be informed so I can check whether the content is actually the same.

My take: if the URL changes, the checksum can change too. If the URL changes: the checksum doesn't need to change. If the checksum changes: the URL should (usually) change.

Another possibility is to have CI pass a flag to the audit command when a manual "version checksum mismatch allowed" label is applied. It could then skip this check alone which would both give a green CI as well as flag it for reviewers to verify that the URL change makes sense.

Something like this makes a lot of sense as it's something that:

can only be done by maintainers
provides information logged on the PR about it happening and who did it

@dtrodrigues I am fine with that, but I think in the longer term there could be other “informative” audits of interest. We probably need to figure out a way to implement a two-level audit (errors and warnings)

The only thing I can see that would be like a warning is have CI be green but have @BrewTestBot post a comment to the relevant pull request. Even then, though, I think I prefer the idea of an audit that's overridden with a specific label (rather than just "ignore audits").

audit that's overridden with a specific label

That sounds like a good solution

I haven't really looked at the rest of the code but this doesn't seem to be anything specific to PyPI. If the URL changes: the checksum can change, too.

Would it make sense for the audit instead only to trigger if the URL is identical but the checksum changes?

Closed in favor of #9111


[6.0][Android] Enable more code and tests (#871)

Explanation: This gets the remaining tests passing natively on Android while disabling setting extended file attributes and modifying a test that creates a hard link, features not normally allowed on Android. I also removed an incorrect WASI check I found.
Scope: Only affects Android, no other platforms' code is touched.
Issue: None
Original PRs: #871
Risk: None
Testing: Passed all CI on trunk and my testing locally.
Reviewer: @jmschonfeld
This is useful for me and others who distribute Android SDKs or a toolchain, and won't break anything for other platforms.

@jmschonfeld, need a CI run here, I just added this to my Android CI to build 6.0.

@swift-ci please test

Passed CI, @parkera, ready for review.

We'll have to double check which 6.0 release this eventually gets into. I think it'll be post-6.0.2 now unless there is one more cherry pick.

6.0.3 is fine, as long as I can retire it from my downstream patches eventually.


fix: typo in helm keys

typo in helm keys was resulting in broken CI testing

Codecov Report

Merging #443 (26f281d) into main (5647b24) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #443   +/-   ##
=======================================
  Coverage   13.29%   13.29%
=======================================
  Files          12       12
  Lines        1301     1301
=======================================
  Hits          173      173
  Misses       1110     1110
  Partials       18       18

Flag
Coverage Δ

unittests
13.29% <ø> (ø)

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

Impacted Files
Coverage Δ

test/e2e/util/utils.go
7.63% <ø> (ø)

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


IE-11 memory issue

I am running into memory issue on IE-11 with following messages in console..
"Unable to access cssText property {somne property name}"
code print out this message several time untill it run into memory issue.

I'm having the same issue. Only in IE. Even when following the suggestions in the FAQ, IE still runs out of storage space. Also have the cssText issue popping up and then it crashed out.


invalid node type

nvim -v
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1692716794

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/share/nvim"

After using the go.nvim plugin with LazyVim, I encountered an error when executing 'checkhealth'. The error message is as follows:
The following errors have been detected: ~
- ERROR go(locals): ...im-macos/share/nvim/runtime/lua/vim/treesitter/query.lua:259: query: invalid node type at position 2003 for language go
  go(locals) is concatenated from the following files:
  |    [OK]:"/Users/stong/.local/share/nvim/lazy/nvim-treesitter/queries/go/locals.scm"
  | [ERROR]:"/Users/stong/.local/share/nvim/lazy/go.nvim/after/queries/go/locals.scm", failed to load: ...im-macos/share/nvim/runtime/lua/vim/treesitter/query.lua:259: query: invalid node type at position 109 for language go

I have no idea about this error, any help would be appreciated!
There is my config
And the full 'checkhealth' content is:
==============================================================================
conform: require("conform.health").check()

conform.nvim report ~
- Log file: /Users/stong/.local/state/nvim/conform.log
- WARNING fish_indent unavailable: Command not found
- OK gofumpt ready (go)
- OK goimports ready (go)
- OK prettier ready (typescript, handlebars, graphql, markdown.mdx, less, scss, css, vue, javascriptreact, markdown, html, javascript, jsonc, typescriptreact, yaml, json)
- OK shfmt ready (sh)
- OK stylua ready (lua)

==============================================================================
crates: require("crates.health").check()

Checking plugins ~
- OK null-ls.nvim installed

Checking external dependencies ~
- OK curl installed
- OK open installed

==============================================================================
go: require("go.health").check()

Binaries ~
- go installed.
- Tool installed: guru
- Tool installed: callgraph
- Tool installed: gotestsum
- Tool installed: dlv
- Tool installed: gorename
- Tool installed: iferr
- Tool installed: golines
- Tool installed: fillstruct
- Tool installed: gonew
- Tool installed: golangci-lint
- Tool installed: gopls
- Tool installed: goimports
- Tool installed: gofumpt
- Tool installed: json-to-struct
- Tool installed: impl
- Tool installed: gomodifytags
- Tool installed: richgo
- Tool installed: ginkgo
- Tool installed: govulncheck
- Tool installed: fillswitch
- Tool installed: gomvp
- Tool installed: gotests
- Tool installed: go-enum
- Tool installed: mockgen
- sed installed.
- curl installed.
- OK All binaries installed

Go Plugin Check ~
- OK lspconfig: plugin is installed
- OK nvim-treesitter: plugin is installed
- OK guihua: plugin is installed
- OK nvim-dap-virtual-text: plugin is installed
- OK telescope: plugin is installed
- OK nvim-treesitter-go is installed
- OK nvim-dap: plugin is installed
- OK nvim-dap-ui: plugin is installed
- OK All plugin installed
- OK GOROOT is set
- OK GOBIN is set
- OK All environment variables set
- OK GOBIN is in PATH

==============================================================================
lazy: require("lazy.health").check()

lazy.nvim ~
- OK Git installed
- OK no existing packages found by other package managers
- OK packer_compiled.lua not found
- WARNING {alpha-nvim}: overriding <enabled>
- WARNING {nvim-treesitter-textobjects}: overriding <config>

==============================================================================
lazyvim: require("lazyvim.health").check()

LazyVim ~
- OK Using Neovim >= 0.9.0
- OK `git` is installed
- OK `rg` is installed
- OK `fd` is installed
- OK `lazygit` is installed

==============================================================================
luasnip: require("luasnip.health").check()

luasnip ~
- WARNING             For Variable/Placeholder-transformations, luasnip requires
  the jsregexp library. See `:help |luasnip-lsp-snippets-transformations`| for advice

==============================================================================
mason: require("mason.health").check()

mason.nvim ~
- OK mason.nvim version v1.10.0
- OK PATH: prepend
- OK Providers:
  mason.providers.registry-api
  mason.providers.client
- OK neovim version >= 0.7.0

mason.nvim [Registries] ~
- OK Registry `github.com/mason-org/mason-registry version: 2024-04-11-robust-lounge` is installed.

mason.nvim [Core utils] ~
- OK unzip: `UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send`
- OK wget: `GNU Wget 1.21.3 built on darwin20.0.0.`
- OK curl: `curl 7.84.0 (arm64-apple-darwin20.0.0) libcurl/7.84.0 OpenSSL/1.1.1q zlib/1.2.12 libssh2/1.10.0 nghttp2/1.46.0`
- OK gzip: `Apple gzip 428`
- OK gtar: `tar (GNU tar) 1.34`
- OK bash: `GNU bash，版本 5.2.15(1)-release (aarch64-apple-darwin22.1.0)`
- OK sh: `Ok`

mason.nvim [Languages] ~
- OK Go: `go version go1.21.3 darwin/arm64`
- WARNING Composer: not available
  - ADVICE:
    - spawn: composer failed with exit code - and signal -. composer is not executable
- WARNING PHP: not available
  - ADVICE:
    - spawn: php failed with exit code - and signal -. php is not executable
- OK Ruby: `ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin22]`
- OK node: `v18.20.1`
- OK cargo: `cargo 1.76.0 (c84b36747 2024-01-18)`
- OK luarocks: `/opt/homebrew/bin/luarocks 3.9.2`
- WARNING julia: not available
  - ADVICE:
    - spawn: julia failed with exit code - and signal -. julia is not executable
- OK java: `openjdk version "19" 2022-09-20`
- OK RubyGem: `3.2.3`
- OK python: `Python 3.9.18`
- OK npm: `10.5.1`
- OK javac: `javac 19`
- OK pip: `pip 23.3.1 from /Users/stong/.local/lib/python3.9/site-packages/pip (python 3.9)`
- OK python venv: `Ok`

mason.nvim [GitHub] ~
- OK GitHub API rate limit. Used: 1. Remaining: 59. Limit: 60. Reset: 五  4/12 02:32:58 2024.
  Install and authenticate via gh-cli to increase rate limit.

==============================================================================
neoconf: require("neoconf.health").check()

neoconf.nvim ~
- OK **treesitter-nvim** is installed
- OK **TreeSitter jsonc** parser is installed
- OK **neodev.nvim** is installed
- OK **lspconfig** is installed
- OK **lspconfig jsonls** is installed
- OK **lspconfig lua_ls** is installed

==============================================================================
noice: require("noice.health").check()

noice.nvim ~
- OK **Neovim** >= 0.8.0
- OK You're using a GUI that should work ok
- OK **vim.go.lazyredraw** is not enabled
- OK **nvim-notify** is installed
- OK **TreeSitter vim** parser is installed
- OK **TreeSitter regex** parser is installed
- OK **TreeSitter lua** parser is installed
- OK **TreeSitter bash** parser is installed
- OK **TreeSitter markdown** parser is installed
- OK **TreeSitter markdown_inline** parser is installed
- OK `vim.notify` is set to **Noice**
- OK `vim.lsp.handlers["textDocument/hover"]` is set to **Noice**
- OK `vim.lsp.handlers["textDocument/signatureHelp"]` is set to **Noice**
- OK `vim.lsp.handlers["window/showMessage"]` is set to **Noice**
- OK `vim.lsp.util.convert_input_to_markdown_lines` is set to **Noice**
- OK `vim.lsp.util.stylize_markdown` is set to **Noice**
- OK `cmp.entry.get_documentation` is set to **Noice**

==============================================================================
null-ls: require("null-ls.health").check()

- OK gomodifytags: the source "gomodifytags" can be ran.
- OK impl: the source "impl" can be ran.
- OK goimports: the command "goimports" is executable.
- OK gofumpt: the command "gofumpt" is executable.
- OK markdownlint: the command "markdownlint" is executable.
- OK prettier: the command "prettier" is executable.
- ERROR fish_indent: the command "fish_indent" is not executable.
- ERROR fish: the command "fish" is not executable.
- OK stylua: the command "stylua" is executable.
- OK shfmt: the command "shfmt" is executable.

==============================================================================
nvim: require("nvim.health").check()

Configuration ~
- OK no issues found

Runtime ~
- OK $VIMRUNTIME: /Users/stong/sdk/nvim-macos/share/nvim/runtime

Performance ~
- OK Build type: Release

Remote Plugins ~
- OK Up to date

terminal ~
- key_backspace (kbs) terminfo entry: `key_backspace=^H`
- key_dc (kdch1) terminfo entry: `key_dc=\E[3~`
- $TERM_PROGRAM="iTerm.app"
- $COLORTERM="truecolor"

==============================================================================
nvim-treesitter: require("nvim-treesitter.health").check()

Installation ~
- OK `tree-sitter` found 0.20.8 (parser generator, only needed for :TSInstallFromGrammar)
- OK `node` found v18.20.1 (only needed for :TSInstallFromGrammar)
- OK `git` executable found.
- OK `cc` executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
  Version: Apple clang version 15.0.0 (clang-15<IP_ADDRESS>.5)
- OK Neovim was compiled with tree-sitter runtime ABI version 14 (required >=13). Parsers must be compatible with runtime ABI.

OS Info:
{
  machine = "arm64",
  release = "23.1.0",
  sysname = "Darwin",
  version = "Darwin Kernel Version 23.1.0: Mon Oct  9 21:28:31 PDT 2023; root:xnu-10002.41.9~6/RELEASE_ARM64_T8112"
} ~

Parser/Features         H L F I J
  - bash                ✓ ✓ ✓ . ✓
  - c                   ✓ ✓ ✓ ✓ ✓
  - diff                ✓ . . . .
  - go                  ✓ x ✓ ✓ ✓
  - html                ✓ ✓ ✓ ✓ ✓
  - javascript          ✓ ✓ ✓ ✓ ✓
  - jsdoc               ✓ . . . .
  - json                ✓ ✓ ✓ ✓ .
  - jsonc               ✓ ✓ ✓ ✓ ✓
  - lua                 ✓ ✓ ✓ ✓ ✓
  - luadoc              ✓ . . . .
  - luap                ✓ . . . .
  - markdown            ✓ . ✓ ✓ ✓
  - markdown_inline     ✓ . . . ✓
  - python              ✓ ✓ ✓ ✓ ✓
  - query               ✓ ✓ ✓ ✓ ✓
  - regex               ✓ . . . .
  - toml                ✓ ✓ ✓ ✓ ✓
  - tsx                 ✓ ✓ ✓ ✓ ✓
  - typescript          ✓ ✓ ✓ ✓ ✓
  - vim                 ✓ ✓ ✓ . ✓
  - vimdoc              ✓ . . . ✓
  - xml                 ✓ ✓ ✓ ✓ ✓
  - yaml                ✓ ✓ ✓ ✓ ✓

  Legend: H[ighlight], L[ocals], F[olds], I[ndents], In[j]ections
         +) multiple parsers found, only one will be used
         x) errors found in the query, try to run :TSUpdate {lang} ~

The following errors have been detected: ~
- ERROR go(locals): ...im-macos/share/nvim/runtime/lua/vim/treesitter/query.lua:259: query: invalid node type at position 2003 for language go
  go(locals) is concatenated from the following files:
  |    [OK]:"/Users/stong/.local/share/nvim/lazy/nvim-treesitter/queries/go/locals.scm"
  | [ERROR]:"/Users/stong/.local/share/nvim/lazy/go.nvim/after/queries/go/locals.scm", failed to load: ...im-macos/share/nvim/runtime/lua/vim/treesitter/query.lua:259: query: invalid node type at position 109 for language go

==============================================================================
provider: health#provider#check

Clipboard (optional) ~
- OK Clipboard tool found: pbcopy

Python 3 provider (optional) ~
- pyenv: Path: /opt/homebrew/Cellar/pyenv/2.3.25/libexec/pyenv
- pyenv: Root: /Users/stong/.pyenv
- WARNING No Python executable found that can `import neovim`. Using the first available executable for diagnostics.
- WARNING Could not load Python 3:
  /Users/stong/.pyenv/shims/python3 does not have the "neovim" module.
  python3.12 not found in search path or not executable.
  /opt/homebrew/bin/python3.11 does not have the "neovim" module.
  python3.10 not found in search path or not executable.
  /Users/stong/.pyenv/shims/python3.9 does not have the "neovim" module.
  python3.8 not found in search path or not executable.
  python3.7 not found in search path or not executable.
  /Users/stong/.pyenv/shims/python does not have the "neovim" module.
  - ADVICE:
    - See :help |provider-python| for more information.
    - You may disable this provider (and warning) by adding `let g:loaded_python3_provider = 0` to your init.vim
- Executable: Not found

Python virtualenv ~
- OK no $VIRTUAL_ENV

Ruby provider (optional) ~
- Ruby: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin22]
- WARNING `neovim-ruby-host` not found.
  - ADVICE:
    - Run `gem install neovim` to ensure the neovim RubyGem is installed.
    - Run `gem environment` to ensure the gem bin directory is in $PATH.
    - If you are using rvm/rbenv/chruby, try "rehashing".
    - See :help |g:ruby_host_prog| for non-standard gem installations.
    - You may disable this provider (and warning) by adding `let g:loaded_ruby_provider = 0` to your init.vim

Node.js provider (optional) ~
- Node.js: v18.20.1
- WARNING Missing "neovim" npm (or yarn, pnpm) package.
  - ADVICE:
    - Run in shell: npm install -g neovim
    - Run in shell (if you use yarn): yarn global add neovim
    - Run in shell (if you use pnpm): pnpm install -g neovim
    - You may disable this provider (and warning) by adding `let g:loaded_node_provider = 0` to your init.vim

Perl provider (optional) ~
- WARNING "Neovim::Ext" cpan module is not installed
  - ADVICE:
    - See :help |provider-perl| for more information.
    - You may disable this provider (and warning) by adding `let g:loaded_perl_provider = 0` to your init.vim

==============================================================================
telescope: require("telescope.health").check()

Checking for required plugins ~
- OK plenary installed.
- OK nvim-treesitter installed.

Checking external dependencies ~
- OK rg: found ripgrep 13.0.0
- OK fd: found fd 8.7.0

===== Installed extensions ===== ~

Telescope Extension: `fzf` ~
- OK lib working as expected
- OK file_sorter correctly configured
- OK generic_sorter correctly configured

Telescope Extension: `notify` ~
- No healthcheck provided

==============================================================================
vim.lsp: require("vim.lsp.health").check()

- LSP log level : WARN
- Log path: /Users/stong/.local/state/nvim/lsp.log
- Log size: 56 KB

vim.lsp: Active Clients ~
- jsonls (id=1, root_dir=/Users/stong/.config/nvim)
- null-ls (id=2, root_dir=/Users/stong/.config/nvim)

==============================================================================
vim.treesitter: require("vim.treesitter.health").check()

- Nvim runtime ABI version: 14
- OK Parser: bash       ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/bash.so
- OK Parser: c          ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/c.so
- OK Parser: diff       ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/diff.so
- OK Parser: go         ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/go.so
- OK Parser: html       ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/html.so
- OK Parser: javascript ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/javascript.so
- OK Parser: jsdoc      ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/jsdoc.so
- OK Parser: json       ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/json.so
- OK Parser: jsonc      ABI: 13, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/jsonc.so
- OK Parser: lua        ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/lua.so
- OK Parser: luadoc     ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/luadoc.so
- OK Parser: luap       ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/luap.so
- OK Parser: markdown   ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/markdown.so
- OK Parser: markdown_inline ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/markdown_inline.so
- OK Parser: python     ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/python.so
- OK Parser: query      ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/query.so
- OK Parser: regex      ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/regex.so
- OK Parser: toml       ABI: 13, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/toml.so
- OK Parser: tsx        ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/tsx.so
- OK Parser: typescript ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/typescript.so
- OK Parser: vim        ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/vim.so
- OK Parser: vimdoc     ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/vimdoc.so
- OK Parser: xml        ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/xml.so
- OK Parser: yaml       ABI: 14, path: /Users/stong/.local/share/nvim/lazy/nvim-treesitter/parser/yaml.so
- OK Parser: c          ABI: 14, path: /Users/stong/sdk/nvim-macos/lib/nvim/parser/c.so
- OK Parser: lua        ABI: 14, path: /Users/stong/sdk/nvim-macos/lib/nvim/parser/lua.so
- OK Parser: query      ABI: 14, path: /Users/stong/sdk/nvim-macos/lib/nvim/parser/query.so
- OK Parser: vim        ABI: 14, path: /Users/stong/sdk/nvim-macos/lib/nvim/parser/vim.so
- OK Parser: vimdoc     ABI: 14, path: /Users/stong/sdk/nvim-macos/lib/nvim/parser/vimdoc.so

==============================================================================
which-key: require("which-key.health").check()

WhichKey: checking conflicting keymaps ~
- WARNING conflicting keymap exists for mode **"n"**, lhs: **"gc"**
- rhs: ` `

Looks like the cause is a recent update in nvim-treesitter.

Looks like the cause is a recent update in nvim-treesitter.

Thank you for sharing the commit. As a newcomer to the project, I'm still getting familiar with everything, so I couldn't fully understand the details mentioned in the commit message. I'll make sure to keep track of this issue as I continue to learn. Thanks once again for your help!"

The commit of nvim-treesitter is a breaking change. It does affect a few plugins.
If you do not want to revert nvim-treesitter to an earlier version. You can update go treesitter parser. But I would suggest you stay in an old version for a few days.

Pushed a fix. Would you check if it works for you, please run TSUpdate go as well.

Pushed a fix. Would you check if it works for you, please run TSUpdate go as well.

It works, good job!


Added env setting for OMS to listen to log via fluentd

Please review this and get back.
@rgardler

Closing as it looks like this is an incomplete implementation and there has been no response from the author


Unexpected import behaviour in "non-ssr" routes

Describe the bug
The Bug (or maybe a documentation issue?):
I've exported ssr=false in my root +layout.
If I import (via statement/top-level) in any sub-route's +page.js/.ts a dependency that uses at the top level a browser API (more precise: any none-node API),
the build failing "evaluating SSR" with an error:
ReferenceError [Error]: (the unknown API) is not defined

I expected, that SSR should be turned off for the page.js/.ts in that case :thinking:
Reproduction
Here you can find a prepared example for this miss-behaviour:
https://github.com/SourceR85/pwa-load
At the end, it's pretty easy to replicate:

create a project with npm create svelte@latest xxx
add export const ssr=false; to a +layout.js/.ts
write some code, that depends (at the module scope) on non-node API's
Import that code in a "SPA" +page.js/.ts route, somewhere within the +layout path

Logs
❯ npm run build

><EMAIL_ADDRESS>build
> vite build

vite v4.5.1 building SSR bundle for production...
✓ 75 modules transformed.

node:internal/event_target:1083
  process.nextTick(() => { throw err; });
                           ^
ReferenceError [Error]: localStorage is not defined
    at file:///home/sourcer/dev/playground/pwa-load/.svelte-kit/output/server/entries/pages/_page.ts.js:4:24
    at ModuleJob.run (node:internal/modules/esm/module_job:217:25)
    at async ModuleLoader.import (node:internal/modules/esm/loader:316:24)
    at async analyse (file:///home/sourcer/dev/playground/pwa-load/node_modules/@sveltejs/kit/src/core/postbuild/analyse.js:60:16)
    at async MessagePort.<anonymous> (file:///home/sourcer/dev/playground/pwa-load/node_modules/@sveltejs/kit/src/utils/fork.js:22:16)
Emitted 'error' event on Worker instance at:
    at [kOnErrorMessage] (node:internal/worker:326:10)
    at [kOnMessage] (node:internal/worker:337:37)
    at MessagePort.<anonymous> (node:internal/worker:232:57)
    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:807:20)
    at exports.emitMessage (node:internal/per_context/messageport:23:28)

Node.js v20.9.0

System Info
System:
  OS: Linux 6.6 Fedora Linux 39 (KDE Plasma)
  CPU: (16) x64 AMD Ryzen 7 6800HS Creator Edition
  Memory: 3.05 GB / 13.34 GB
  Container: Yes
  Shell: 5.9 - /usr/bin/zsh
Binaries:
  Node: 20.9.0 - ~/.fnm/node-versions/v20.9.0/installation/bin/node
  Yarn: 1.22.21 - ~/.fnm/node-versions/v20.9.0/installation/bin/yarn
  npm: 10.1.0 - ~/.fnm/node-versions/v20.9.0/installation/bin/npm
  pnpm: 8.12.1 - ~/.fnm/node-versions/v20.9.0/installation/bin/pnpm
  bun: 1.0.1 - ~/.bun/bin/bun
npmPackages:
  @sveltejs/adapter-auto: 2.1.1 => 2.1.1
  @sveltejs/kit: 1.30.3 => 1.30.3
  svelte: 4.2.8 => 4.2.8
  vite: 4.5.1 => 4.5.1

Severity
serious, but I can work around it
Additional Information
No response

This is expected. Pages can override layout options, which means we can't know whether the page should be server-rendered or not without loading the +page.ts. Put the $lib/webStorage import in your +page.svelte (which will not be imported on the server, if ssr = false) instead

Put the $lib/webStorage import in your +page.svelte (which will not be imported on the server, if ssr = false) instead

Thank you for your advise, but this repo was only meant as a very abstract demo of the problem I stepped over.
In my production project, I import PouchDB to get some synchronized data in offline-cases, which then controls the behaviour of my load function. (PouchDB depends on localStorage and IndexedDB)
Setting up some similar Project for this demo may be to much as a demonstration.
As a work around: using a dynamic import for the dependency works for me (line 15 in +page.ts).
Maybe, this "bug" can should be degraded to "annoyance" with high complexity?
On the other hand: the documentation didn't tell you, that ssr is required for +page.js/ts's (in that case, it's a documentation bug)

I'm labeling this as a documentation issue. There's not really a way for this to work without trying to evaluate +page.js files on the server, which necessarily also tried to evaluate any import ... from '...'s in them. We could maybe make it clearer which files will get evaluated on the server during build and thus need to not use any browser APIs in their top-level code (not import any code that uses browser APIs at the top level).

As far as i know by now:
The only information, that decides if a +page.js/ts needs to be ssr'd is an export of ssr, right?
If so, here my thoughts:
After evaluating a +layout, with that ssr=false hint, I can slam a regex somewhere to extract that hint from child pages and layouts.
Will it be enough to avoid running that file(s) in build?

That's called static analysis and it's one of those things that seems like a good idea until you try it. Let's say you try the regex approach — what do you do here?
// export const ssr = false;

Next you could try parsing the code and analysing the AST, but then what do you do here?
export const ssr = EXPERIMENTS_USE_SSR;

Maybe you could special-case environment variables like that, but what happens when you have something like this?
export { ssr, prerender } from '$lib/config';

And so on. It's tempting to say 'we could try static analysis first and then fall back to runtime analysis', but then the system becomes very hard to reason about — a seemingly unrelated change could cause the sort of failures you encountered, and it would be far from obvious how to solve them. It's much better if the rules are simple and well-understood, and in this case there are two solutions (in order of preference, but also decreasing order of ease):

send a PR to PouchDB so that it handles the 'oh, look, I'm running in Node' case gracefully
the dynamic import(...) approach you already landed on

I ran into a similar issue (and looking through the issues a couple of people did). I understand the rational why this can not be easily circumvented, but both "workarounds" (modify the library used, use dynamic imports everywhere), seem unsatisfying.
From my limited understanding of the internals and rational behind the design, it feels like the issue stems from having +page.ts and +layout.ts as files that mix both logic and config, which is create, if the config depends on the logic (e.g. dynamically switching ssr), but not great if the logic depends on the config (e.g. when you want to use browser only libraries with import side-effects.
A "simple" (based on my naive understanding) workaround would be to introduce a additional optional file (e.g. +config.ts) that is read first. As this config file is not the place where you are expected to put any core logic, it is easier to get rid of any problematic imports there.
An issue arises when you want to support cases, where configuration of a child route placed in +layout/+page.ts should overwrite config from a +config.ts in a parent route. As it might not be clear what to do then, but there might a couple of ways to work around that too.
The other (less granular) option, feels like to really have a global "SPA" switch. I guess most people running into this issue (myself included), were trying to build "just a simple SPA", but were surprised when suddenly code ran in a NodeJS env during dev.

I recently encountered this problem in my project as well. Before 1.0.0-next.405, I set the global ssr to false directly in the handle function of hooks.js and it works well. But after I update sveltekit to 1.0.0-next.405, this problem arose because the render_page function of /src/runtime/server/page/index.js will try to get nodes and load +page.js files.
I understand this problem may not be easy to circumvent and I think the dynamic imports should work for me. But it's a bit strange to me that I already set  global ssr to false to build "just a simple SPA" (according to AKuederle) but browser APIs is still run when build the project.


Fix restart

Description
I modified 'restart' command to run on Windows.

Thanks for the fix, the only thing I don't like is how the test code exactly duplicates the implementation. What if we always added ruby in front of the command?

On Windows, Kernel.exec('foo.rb') is not running. We have to change this to Kernel.exec('ruby foo.rb'). Accordingly, the expected output of restart is changed on Windows.

I fix execute method in restart.rb and test methods in restart_test.rb, always add Ruby interpreter path. How about this?

Yes, definitely! The reason I asked for this is that this problem is not specific to Windows. If you run ruby myscript.rb where myscript.rb has no shebang or is not executable, restart will fail in Linux too. So I think it makes more sense to just always add ruby before the command when restarting.
Can we add a separate test with the assertion that we want the ruby executable before the command? (def test_restart_adds_ruby_before_the_command or something like that). Due to the bad shape of the current restart tests (not really restarting but just mocking the exec call and doing assertions on it), it won't be a regression test since it currently passes, but at least it might help to document that prepending ruby is necessary (until we can improve the tests).
What do you think?

Sorry, It seems that the purpose of the correction was not conveyed.

If you run ruby myscript.rb where myscript.rb has no shebang or is not executable, restart will fail in Linux too. So I think it makes more sense to just always add ruby before the command when restarting.

I understood that. Therefore, I fix execute methodo always add ruby before the command when restarting.
Please check the latest commit.

Yes, I checked the last fix and I like it. I just wanted an extra test to serve as documentation for the fix, but I guess we can live without it.
Just two more things before merge:

Can you change the commit that touches $ARGV to instead require 'English' on top of the file. I use $ARGV everywhere else and, although it doesn't help with readability in this case, I prefer to use it consistently.

Can you squash all commits down to two (one for the $ARGV fix and one for the ruby fix) and include a change log entry with each of them?

Just two more things before merge:

Can you change the commit that touches $ARGV to instead require 'English' on top of the file. I use $ARGV everywhere else and, although it doesn't help with readability in this case, I prefer to use it consistently.

Can you squash all commits down to two (one for the $ARGV fix and one for the ruby fix) and include a change log entry with each of them?

OK, I fixed it as you suggested.

Looks great! Just missing a rebase and a changelog entry with each commit in the "Fixed" section of the changelog.

Should I add the following sentences to CHANGELOG.md ?
Fix_restart (Unreleased)
Fixed

Require English in restart.rb for use $ARGV.
Modified restart that Kernel.exec always call ruby.

For the ARGV bug you can say:

restart command crashing in certain cases because of a missing require 'English' (#321, @akaneko3).

For the other one:

restart command crashing when debugged script is not executable or has no shebang (#321, @akaneko3).

Thanks! May I write it to CHANGELOG.md and commit it?

Of course. If you can add each sentence to each commit (keeping the PR with two commits), that's preferred. Also, don't forget to rebase :wink:

HI, Deivit, I fixed CHANGELOG.md and rebased repository a few days ago.

Please merge PR, I don't mind if you merge in your free time.

Sorry, I forgot... Last comments, could you use single backquotes instead of triple backquotes like it's done in the other entries in the change log? Also, regarding the commit messages, the correct wording for the second commit would be "Modified 'restart' Kernel.exec to always call 'ruby'" instead of "Modified 'restart' Kernel.exec is always call 'ruby'".

OK, I fixed CHANGELOG.md and commit message.

Thank you so much!

Thank you for merge and advising me a lot!


Add dependencies in the zip

Add an option to specify a list of folders containing dependencies to add to the zip

I didn't see the pull request #35 wich seems to have a better solution for this problem....

After looking to the PR #35, it doesn't solve the same issue, which is avoiding to mix the source code with the dependencies.
From the exemple in PR #35 we have to install the dependencies in the same folder before deploying, wich I find messy at best, and problematic for certain use case. For exemple to use psycopg2 we need to override the folder to use the version compiled on the same AMI as the one running the lambda. This is very easy when you can specify folder of dependencies.
As Kalpit said in the PR #35, it begins to be difficult to know against which branch we should do the PR. I can also do a PR against python-refactor if needed.
Thanks,

The python-refactor branch is the right one to base changes on.  I apologize that it has been hanging out for so long and I will try to get it merged asap.  We use kappa (on the python-refactor branch) every day here but I just haven't been able to find the time to complete the docs and examples needed to complete the merge.

So, if I understand correctly, it would be helpful to you to have this merged into the develop branch, correct?  Is that the branch you are currently using?  Do you still need this merged into python-refactor or was that just for my benefit?

From now on I'll be using python-refactor.
So I would rather have python-refactor with my other PR merged and this one doesn't really need to be merged.
Thanks

ok, thanks.


resources/images: Adding webp support

This is based on the cwebp binary of the WebP utilities of Google.
If on the system the binary is installed methods like $image.Resize "600x webp" are available.
The reason why this is based on the binaries of WebP utilities of Google because there is currently no golang native WebP implementation available. On the other side using C-bindings to access libraries just make the whole build process of hugo too complicated. To execute binaries is not my favorite but seems under this conditions the best compromise.
Fixes #5924
Supports #4780

 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.

Thanks, but we need to determine if/how in #5924 before implementing this.
I don't think we have the bandwidth to implement this using C bindings.

@bep I understand your concerns, but I want to point out that this PR does not change syntax or whatever. It "just" adding the webp encoding support with all the commands which are there before. This needs to be done in any way, also if you want to change the whole domain language or whatever. When you want to add other functions to "change" file types or whatever, you can do it afterwards.


Add field for loaders to indicate what form of JSON parsing is used

This discussion started in https://github.com/KhronosGroup/glTF/issues/1699.
@lexaknyazev had a great idea to add a field to Project Explorer specifically for loaders, to indicate what form of JSON parsing they use for the manifest. Most JSON parsers use DOM parsing, but this begins to falter when you exceed a certain threshold (generally based on the computer's available memory) and streaming, SAX-style, JSON parsers often fill this space. Jackson is a good example of a streaming JSON parser that I am immediately aware of.
I've proposed two options so far:

A boolean flag indicating the loader supports parsing large manifests (threshold around ≥100MiB? higher?)
A field describing how the JSON parsing works? Is it using a DOM parser or a streaming parser?

And @lexaknyazev voiced interest in the more descriptive field that indicates explicitly using a DOM parser or a SAX/Streaming parser.
I'm currently more a fan of the field as well, but I would urge us to go with "streaming" over SAX as while many of the streaming JSON parsers are SAX-style, some very popular parsers are not. JSONStream comes to mind.

I don't have a very strong opinion here, but some doubts (I always have doubts): It is very specific, might be hard to find out for one loader or the other, and in the end, might not tell you anything about the actual capabilities of the loader.
That DOM imposes a hard limit is true, but I have no idea where this limit will be (i.e. what a "large" file is: 100MB or 1GB? And what should be contained in a 1GB file that is then supposed to be rendered?). But conversely, SAX does not mean that you can in fact load large files - what information should be presented if a loader uses SAX, but bails out with 10MB files?
(I'm not opposed to the idea, just wondering what the exact information is that is to be represented there, and how it should be gathered...)

I've mulled over this for the past day or so and I agree, I think that this is extremely specific and would be difficult to discover for every loader. In an ideal world, the person adding the loader to the file would be the individual behind the project, and would have the context to provide the needed information. Reality tends to act against the ideal in these sorts of cases.
I've spent a fair bit of time researching parser limits this evening and I've found that they tend to be reasonably documented in some languages and environments (C#, Java) and nearly impossible to find for the browsers and other languages. I think this is due to the fact that the IETF spec for JSON explicitly calls out that parsers can set limits on the size, depth, and nesting of the files it parses, but this action is completely optional. It makes some sense to me that from a browser perspective that you wouldn't set a hard limit and instead just try it and see; if you run out of memory you fail anyways.
I'm really on the fence about this now. On one hand I feel there isn't much harm to be had in adding a field to be filled with the information when the submitter is comfortable. On the other hand this opens the door to the potential of many little cases that may never be used, or may be misleading. I do think there is a problem to solve here, but I'm less confident on the initial idea of a field indicating DOM vs Streaming/SAX. Perhaps Memory-Bound vs a Hard Limit would be more useful?

In an ideal world, the person adding the loader to the file would be the individual behind the project, and would have the context to provide the needed information. Reality tends to act against the ideal in these sorts of cases.

Why so? Usually, the authors of glTF libraries open PRs with information about their projects. We can ask for specifics before merging.

nearly impossible to find for the browsers

Browsers' JSON implementations are open-source (see V8 for Chrome, SpiderMonkey for Firefox, JavaScriptCore for Safari, and Chakra for EdgeHTML). Following ECMAScript API, they provide only blocking interface (JSON.parse()) that returns single DOM object.

Why so? Usually, the authors of glTF libraries open PRs with information about their projects. We can ask for specifics before merging.

I could be working on a wrong assumption, but a lot of the entries in the late-breaking projects list seem to be added by Patrick. This gives the impression that we end up adding a lot of these entries, I agree it'd be better if we have developers of these projects open a PR to add or update their project's entry themselves.

Browsers' JSON implementations are open-source (see V8 for Chrome, SpiderMonkey for Firefox, JavaScriptCore for Safari, and Chakra for EdgeHTML). Following ECMAScript API, they provide only blocking interface (JSON.parse()) that returns single DOM object.

It's been a while since I've dived into the V8 codebase, but IIRC the DOM object doesn't have any set maximum size; basically if it can fit it in memory it does. That said, the blocking aspect is a great point that I overlooked; if you've got 2 gigs of JSON data you're parsing using JSON.parse() it's still likely going to block the event loop for quite some time, even if the host machine has more than sufficient memory.
I'm now currently favoring a field that's just "JSON Parsing Strategy" or some similar text, with guidance to indicate if it's memory-bound or blocking, and providing DOM and Streaming/SAX as two examples. Ultimately this is a rather complex piece of data to catch, but text such as "Non-blocking, streaming I/O" is useful. The downside is that this would be impossible to filter on outside of a substring search, but I think having this as a non-filterable field is acceptable.

if you've got 2 gigs of JSON data you're parsing using JSON.parse() it's still likely going to block the event loop for quite some time

FWIW, it's possible to parse JSON asynchronously with Fetch API:
fetch("url.gltf")
  .then(response => response.json())
  .then(data => {
    // consume parsed JSON object
  });


value should be returned for textarea

https://reactjs.org/docs/dom-elements.html#value

same for checked and defaultChecked

MDN docs were missing this element on the value attribute


Found some box074 mod zips

thanks to Wangha

Nosk God Windows provided by anikacy on discord

Cyclone Throws provided by dwarfwoot on discord

Cyclone Real Combat, Dead Cells Barrel Launcher, Nosk God <IP_ADDRESS> Linux, ShieldParry, Zote Killer & Dead Cells Time Keeper provided by nightmarecypher on discord


optimize: optimize some javadocs

Ⅰ. Describe what this PR did
optimize: optimize some javadocs

Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)?
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #3664 (4d314b2) into develop (5fac979) will decrease coverage by 0.09%.
The diff coverage is n/a.

:exclamation: Current head 4d314b2 differs from pull request most recent head 8884670. Consider uploading reports for the commit 8884670 to get more accurate results

@@              Coverage Diff              @@
##             develop    #3664      +/-   ##
=============================================
- Coverage      51.91%   51.81%   -0.10%
  Complexity      3500     3500
=============================================
  Files            639      639
  Lines          21181    21156      -25
  Branches        2634     2588      -46
=============================================
- Hits           10996    10962      -34
+ Misses          9091     9079      -12
- Partials        1094     1115      +21

Impacted Files
Coverage Δ
Complexity Δ

...c/main/java/io/seata/common/util/CompressUtil.java
96.00% <ø> (ø)
7.00 <0.00> (ø)

...seata/core/exception/AbstractExceptionHandler.java
0.00% <ø> (ø)
0.00 <0.00> (ø)

.../src/main/java/io/seata/core/protocol/Version.java
7.40% <ø> (ø)
2.00 <0.00> (ø)

.../main/java/io/seata/rm/datasource/ColumnUtils.java
86.59% <ø> (ø)
27.00 <0.00> (ø)

...n/java/io/seata/rm/datasource/ConnectionProxy.java
24.82% <ø> (+0.17%)
13.00 <0.00> (ø)

.../java/io/seata/rm/datasource/DataCompareUtils.java
74.11% <ø> (ø)
27.00 <0.00> (ø)

.../java/io/seata/rm/datasource/SqlGenerateUtils.java
95.12% <ø> (-0.12%)
18.00 <0.00> (ø)

...o/seata/rm/datasource/exec/BaseInsertExecutor.java
71.89% <ø> (ø)
83.00 <0.00> (ø)

.../rm/datasource/exec/BaseTransactionalExecutor.java
58.77% <ø> (ø)
27.00 <0.00> (ø)

.../rm/datasource/exec/mysql/MySQLInsertExecutor.java
69.41% <ø> (ø)
16.00 <0.00> (ø)

... and 53 more


ADD fips-assessments task inclusion for openshift-gitops

Included openshift-gitops tasks in fips-assessment.yml

Closing this PR as it is not needed anymore. Check #33 solves for integrating tests.


Made methods async, same as the most recent BasePersistence class

Newer version of BasePersistence has all methods async
Fixed import of utils
Updated constructor's params to match the base class
Added impl. of 2 new abstract methods from the base class

@all-contributors add @rhutkovich for code