Add kaniko+trivy strategy to samples

Changes
Adds a new ClusterBuildStrategy to samples/ (with accompanying Build and BuildRun) which adds a trivy scan step before pushing the image to the container registry. (I.e. the build intentionally fails if the image has a critical vulnerability).
Submitter Checklist

[ ] Includes tests if functionality changed/was added
[X] Includes docs if changes are user-facing
[ ] Set a kind label on this PR
[x] Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.
Release Notes
NONE

Hey Blair, thank you for the contribution! Out of curiosity, what does your usecase look like? :)

The Kubeflow platform that I work on at Statistics Canada had previously been deploying everything through Github Actions (the project is basically fully public), but for security reasons we're moving to a pull based model where the api server can only be accessed from our internal network, so we're migrating off of Github Actions and onto ArgoCD for deployment. At the moment though, we are still scanning and pushing our own images (i.e. trusted authors) to our container registry via actions.
My hope is to be able to consolidate this all into ArgoCD, so that our manifests include in a single spot "What we're deploying, what we need to build to deploy that, and whether or not the build is successful and secure". So hoping that it helps us get a nice clean overview of our resources. Might also make it easier to mirror our project elsewhere into new environments, as we'll be able to just change our destination container registry in the shipwright yamls, rather than plumbing all of our individual repos all over again. (You may see in the Slack group, I am also drafting up accompanying gatekeeper policies as I'm working on this PoC)

The use case makes sense and it is something I was personally planning to try out in the future! Thank you for sharing the use-case.
To be able to ensure this remains maintained, we'll need to add a test for this build strategy.
Example: https://github.com/shipwright-io/build/blob/0b75f99e2b5b91963b14becb46e0f53234de1b1a/test/e2e/e2e_test.go#L344
I am very keen on taking this in. We'll need to figure out how to organize the build strategies in the recent future :-)

@sbose78 Docs content is patched up, just working on the e2e tests now. Rejigging things a little so that there is a trivy-good and a trivy-bad build+buildrun, so that the e2e can test for true-positives as well as true-negatives

e2e tests seem to be passing! Thanks for the review (and for migrating the sample-scanning repo) @SaschaSchwarze0
https://github.com/blairdrummond/build/pull/1/checks?check_run_id=3257258491

/lgtm
@SaschaSchwarze0 over to you for your review.

@imjasonh @blairdrummond
👋
We should chat on figuring out what's the best way to manage the samples' catalog better as we grow, as part of a different conversation thread.

@imjasonh @blairdrummond
wave
We should chat on figuring out what's the best way to manage the samples' catalog better as we grow, as part of a different conversation thread.

@sbose78 please point me to whatever thread :-) I have another build strategy in-the-works that you might also find interesting

I have another build strategy in-the-works that you might also find interesting

@blairdrummond I'm excited to see this!

please point me to whatever thread :-)

We can chat here https://github.com/shipwright-io/build/issues/852. :)


Add Background Replacement image options in the react demo

Issue #:
https://app.asana.com/0/1207324935836040/1207880868572886
Description of changes:

Add new API changeBackgroundReplacementImage to the demo.
Add a background replacement dropdown on the video preview page.

Add Select Background Replacement Filter to the Filter selection dropdown, it contains a list of background replacement filters, users could switch the filter there.

Testing

How did you test these changes?
Test with the react demo app.
There is the demo video showing the new changes:

https://github.com/user-attachments/assets/bc96c491-8d16-4acd-8413-88c99d317d6f

Can these changes be tested using one of the demo application? If yes, which demo application can be used to test it?
Yes, apps/meeting
If applicable, have you run npm run build successfully locally to fix all warnings and errors?
Yes.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Do we want to show those options if there is no background replacement processor that is active?

Do we want to show those options if there is no background replacement processor that is active?

Yes, it allows users to select the replacement image before enabling the background replacement.


Python projects

Briefly explain the issue

There was no issues sir.
I was trying to bookmark it. I am a python learner.


added end

@akshaygande thanks for opening a PR! Wanted to better understand this change. Could you add more details?
Thanks!

Closing this issue as we aren't yet sure about the use case. Feel free to reopen if necessary. Thanks!


File cannot be written: WriteFileTool() throws validation error for WriteFileInput text

I am trying to improve BabyAGI with agents example from this repo to read a file, optimize it and write the file.
I added this to the tools as from the AutoGPT example next to search and todo:
    WriteFileTool(),     ReadFileTool(),
Prompt is to "Write the optimized code into a file".
ReadFileTool is working fine...
It looks like type is missing as a parameter even. Do I need to pass something to the tool or what am I doing wrong?
I get the following error:
Traceback (most recent call last):   File "baby_agi_with_agent.py", line 136, in <module>     baby_agi({"objective": OBJECTIVE})   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/chains/base.py", line 116, in __call__     raise e   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/chains/base.py", line 113, in __call__     outputs = self._call(inputs)   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/experimental/autonomous_agents/baby_agi/baby_agi.py", line 130, in _call     result = self.execute_task(objective, task["task_name"])   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/experimental/autonomous_agents/baby_agi/baby_agi.py", line 111, in execute_task     return self.execution_chain.run(   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/chains/base.py", line 216, in run     return self(kwargs)[self.output_keys[0]]   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/chains/base.py", line 116, in __call__     raise e   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/chains/base.py", line 113, in __call__     outputs = self._call(inputs)   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/agents/agent.py", line 792, in _call     next_step_output = self._take_next_step(   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/agents/agent.py", line 695, in _take_next_step     observation = tool.run(   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/tools/base.py", line 90, in run     self._parse_input(tool_input)   File "/home/dev/anaconda3/envs/langchain/lib/python3.8/site-packages/langchain/tools/base.py", line 58, in _parse_input     input_args.validate({key_: tool_input})   File "pydantic/main.py", line 711, in pydantic.main.BaseModel.validate   File "pydantic/main.py", line 341, in pydantic.main.BaseModel.__init__ pydantic.error_wrappers.ValidationError: 1 validation error for WriteFileInput text   field required (type=value_error.missing)

Or is it possible to use a lambda function to f.write()? But how to I pass the response from the llm and is that just the code?

Running into the same issue as well. I'm wondering if it's a true bug, or there is an undocumented expectation for how to use this tool. My error looks like yours except I'm using a fairly basic agent with those tools appended.

Looking into this, it turns out it has to do with how the WriteFileTool accepts the arguments. The class has this args_schema property defined which uses some pydantic Field type variables to define the file_path and text. The LLM (nor this human) knows how to properly pass in those arguments.
Since I don't know how it's expecting those to be passed in, I decided to just override the WriteFileTool like so:
from typing import Optional, Type
from pydantic import BaseModel
from langchain.tools.file_management.write import WriteFileTool
import json
class FixedWriteFileTool(WriteFileTool):
description = (
"Write file to disk."
 "Takes the file path and the text content as two string arguments."
"An example of this input: \"file_path\": \"test.txt\", \"text\": \"This is some test text.\""
"Replace the beginning and ending brackets in the input with curly braces."
)
args_schema: Optional[Type[BaseModel]] = None
def _run(self, file_path_and_text: str) -> str:
"{" + file_path_and_text_json + "}"
file_path_and_text_json = json.load(file_path_and_text)
return super().run(file_path_and_text_json["file_path"], file_path_and_text_json["text"])
Essentially, I override the description to give very specific instructions on how the LLM is supposed to input this.
Then, I override the arg_schema to the default from the BaseTool.
Finally, I create a _run function which changes the defined string to a json that can easily parse and use the values in the parent _run function.
This is a super hacky way of doing it, and I wish this just had better documentation to guide us on how to input this.

This seems to give a hint at the input it's expecting: https://github.com/hwchase17/langchain/blob/master/docs/modules/agents/tools/examples/filesystem.ipynb

I'm getting "Too many arguments to single-input tool Write Files to directory. Args: ['data/hello.txt', 'hello world']"


FutureProvider not working properly.

To Reproduce
I have futureProvider is
final currentProfileProvider = FutureProvider<Profile>((ref) async {
  final currentMSV = await SharedPrefs.instance.getCurrentMSV();

  return ref.read(profileRepositoryProvider).getUserByMSV(currentMSV);
});

usage:
            final currentProfile = context.read(currentProfileProvider);

            currentProfile.whenData((profile) {
              print(profile.toJson());
              print('data is ${profile.toJson()}');
              showAlertMessage(context, profile.Token);
            });

in the first click: nothing happens.
second click: dialog show with data.
third click: dialog show with data.

whenData does not wait for the future to resolve. It's a synchronous operation, and if the future isn't completed, nothing happens.
What you want is to await the future instead:
final profile = await context.read(currentProfileProvider.future);

print(profile.toJson());
print('data is ${profile.toJson()}');
showAlertMessage(context, profile.Token);

It worked. Thank you a lot!


Translate Lesson 01 into Turkish

.take , can I work on this issue?

@MuskanSaxena6 It is all yours now.

@rcallaby i;ve made the PR please review it #761


MatTable Paging issue and enhancement (v. 2.3)

When ShowPaging="false", the paging is enabled in any case, so you can see only the first 5 items.
You should be able to disable paging, so you can see all items, without the need to set PageSize.
It would be better that in any case (paging enable or not), you could set the visible numer of rows and scroll the others.

I agree, the behavior is pretty counter-intuitive.
My issue was that when I used the embedded paging with a DB data source (in Blazor Server), I did not get an event when the page size of the embedded paginator was changed, so it did not reload the data.
When I switched to the external paginator it worked, but I had to disable the table-internal paging and STILL hook up the pagesize attribute.
When paging is disabled on the table, it should show as many rows as the hooked up data contains.

With the new virtual table of Blazor presented here https://youtu.be/KRNd8JDRqRc we can replace paginator with infinite scroll.


u64 unsupported by sqlx-sqlite

Description
Using a u64 in the field of a database model yields the error u64 unsupported by sqlx-sqlite when used with the sqlite backend, even though the docs seems to suggest that u64's are supported.

Steps to Reproduce
Use a database model containing a u64 with a sqlite-based backend.

Expected Behavior
Either no error to occur - or more likely, the docs to reflect the fact that u64s aren't supported in sqlite (see: https://github.com/launchbadge/sqlx/issues/2284#issuecomment-1376840943)
Actual Behavior
panicked at 'u64 unsupported by sqlx-sqlite'
Reproduces How Often
Reproducible 100% of the time
Versions
├── sea-orm v0.10.6
│   ├── sea-orm-macros v0.10.6 (proc-macro)
│   ├── sea-query v0.27.2
│   │   ├── sea-query-derive v0.2.0 (proc-macro)
│   ├── sea-query-binder v0.2.2
│   │   ├── sea-query v0.27.2 (*)
│   ├── sea-strum v0.23.0
│   │   └── sea-strum_macros v0.23.0 (proc-macro)
│   ├── sea-orm v0.10.6 (*)
├── sea-orm v0.10.6 (*)

Additional Information

Possible workaround might be to store u64s as a BLOB in sqlite

I have the same case with sea-orm migration and mysql. big_unsigned and unsigned have the same size u32

We might want to backport https://github.com/SeaQL/sea-query/pull/556 to sea-query 0.28

SQLx's SQLite driver doesn't support u64. We have two options:

Update the docs and specify u64 isn't supported in SQLite

Encode & decode u64 as u32. Encoding side (similar to this but TryInto<u32>): https://github.com/SeaQL/sea-query/blob/7c4e4094252ead1b7db39cec64db7ed82d1e7fab/sea-query-binder/src/sqlx_sqlite.rs#L34-L36.

As a temporary "fix" before a consensus has been reached, I'm going to update the docs.

https://github.com/SeaQL/seaql.github.io/pull/88

Hi @billy1624, I would like to know give the second option a shot. But I am afraid that I may need some hand holding to properly fix it
I have a few questions:

Should changing the section you mentioned be enough?
Do I need to add any testing? If yes, should it be inside sea-query or sea-orm?

Hey @matdexir, sorry for the misinformation.

Encode & decode u64 as u32

This isn't ideal. A better option would be "encode & decode u64 as i64". Since the encoding part already handled by SeaQuery. No changes is necessary.

Should changing the section you mentioned be enough?

We only need to change the decoding logics in SeaORM. Which is located at:
https://github.com/SeaQL/sea-orm/blob/d8a2428f460a50ad851db01718976267364a4a3d/src/executor/query.rs#L331-L335
So, we want to get an Option<i64> from the query result then cast it into u64.
Similar to this code snippet:
https://github.com/SeaQL/sea-orm/blob/d8a2428f460a50ad851db01718976267364a4a3d/src/executor/query.rs#L455-L470

Do I need to add any testing? If yes, should it be inside sea-query or sea-orm?

A test case on SeaORM side would be perfect. Where we try saving and select a model with an u64 field.

This isn't ideal. A better option would be "encode & decode u64 as i64". Since the encoding part already handled by SeaQuery. No changes is necessary.

Basically what I was thinking as well, since the former solution would result in memory/value loss. I know that we also lose out almost on about half of the values present in u64 by using i64 but the use cases for such big numbers are quite rare.
Regarding the implementation, I was wondering, should I introduce a new block of with a structure similar for u32/f64
i,e:
https://github.com/SeaQL/sea-orm/blob/d8a2428f460a50ad851db01718976267364a4a3d/src/executor/query.rs#L486-L528
But instead more like this:
impl TryGetable for u64

However I think that this may be too overkill.
Or maybe something closer to this?
https://github.com/SeaQL/sea-orm/blob/d8a2428f460a50ad851db01718976267364a4a3d/src/executor/query.rs#L138-L146
Which would look like:
impl TryGetable for Option<i64>

What do you think?
Very Thankful for your assistance~~

u64 unsupported by sqlx-sqlite is a pretty inherit limitation that we are not able to work around.


fix: Add missing default styling of PhysicalComponents for natures

Does solve #167 but not ideally and dry.
Have a look at the capstyle default style dict. With this solution we needed to add many styleclasses with the same style-dict due to the part_factory. We dynamically add Node or Behavior to the .styleclass attribute of the object like we did in the Human and Actor  case. Indeed it seems like the is_human attribute (causing Human in the styleclass) doesn't change the styling in anyway. In the stylesheet generation it seems like we are matching the whole styleclass which limits us to also use the whole styleclass in the key in capstyle's default styledict. We have 2 ways to improve the situation:

Make the stylesheet generator compatible with wildcards/regex. This enables usage of styleclasses like e.g.: Physical*Actor, Physical*NodeComponent and Physical*BehaviorComponent and these 3 would be the only needed, differing style pairs.
Instead of having one styleclass add support of multiple classes, where the first one is the inferred/original one from the xtype (here PhysicalComponent). This would lead to styleclasses PhysicalComponent, Human, Actor, Node or Behavior. How would we determine which styling class is superior to the others? Take in mind this option does need more changes, especially in the file that declares diagram objects (Diagram, Box, Edge, etc.) and the svg submodule.

I'm looking forward to discuss moving forward.

Make the stylesheet generator compatible with wildcards/regex.

Bad idea, this would give up all the performance benefits of hashable keys, and AIRD diagram rendering is already slow enough.

Instead of having one styleclass add support of multiple classes, where the first one is the inferred/original one from the xtype (here PhysicalComponent).

That could work, but we'd still need to distinguish between different derived classes within one "original" class. For example, the PhysicalBehaviorActor and PhysicalBehaviorComponent introduced in this very PR both derive from PhysicalComponent. So just specifying the original class wouldn't be enough, we'd need to make up a separate "styling-only class" ... which would introduce a not-insignificant amount of complexity to this already very complex module.

Another option could be to have some kind of dynamism in the definition itself. Right now the definitions are static: they're looked up by a predefined name and that's it, if you want a different definition you need to change the name you look up. We could make it possible to define a function instead that takes a (semantic) model element to be styled, and returns the default styling for that element. Then we might not even need to modify the styleclass at all like we currently do.
But this would probably also have some ripple effects in the SVG part of the discussion (as it also defers to capstyle), and in general is a large enough change that I would postpone it to when we attack #107 - one more breaking change there wouldn't stand out ;)

Instead of having one styleclass add support of multiple classes, where the first one is the
inferred/original one from the xtype (here PhysicalComponent).

That could work, but we'd still need to distinguish between different derived classes within one "original" class. For example, the PhysicalBehaviorActor and PhysicalBehaviorComponent introduced in this very PR both derive from PhysicalComponent. So just specifying the original class wouldn't be enough, we'd need to make up a separate "styling-only class" ... which would introduce a not-insignificant amount of complexity to this already very complex module.

What I meant is that we'll always keep the original styleclass that is received from the xtype (e.g.: PhysicalComponent). This one has some style definitions in capstyle's style-dict. Now we add other, custom styleclasses (e.g.: Actor or Node) that come with their own default style-dicts, maintained in capstyle's style-dict. The problem then is which overlapping CSS-definitions from the custom default styles are superior and to be taken...
Also: Even without having the default styles registered in capstyle's style-dict, the correct colors and gradients (I suppose obj_styles but not text_styles!) are recognized in the rendering step. We may invest too much time into default style declaration that we never use... I'm not 100% sure about that.

always keep the original styleclass that is received from the xtype […]. Now we add other, custom styleclasses (e.g.: Actor or Node) that come with their own default style-dicts, maintained in capstyle's style-dict. The problem then is which overlapping CSS-definitions from the custom default styles are superior and to be taken...

That would be a problem that I don't really think we should have to deal with if we can avoid it. Although I guess dealing with it could also be as simple as making the ordering of those additional classes significant, and the last one wins. But still, IMHO having to deal with multiple style classes at all is already too much complexity.

Also: Even without having the default styles registered in capstyle's style-dict, the correct colors and gradients (I suppose obj_styles but not text_styles!) are recognized in the rendering step. We may invest too much time into default style declaration that we never use... I'm not 100% sure about that.

That happens because Capella often saves all style information explicitly in the AIRD, and the parser picks it up if it differs from its known defaults. But our use case also entails supporting other diagram sources like the context diagrams extension, which greatly benefits from having accurate defaults. So IMO this is time well spent.

We need to do this in a better way. With this approach we break existing decorations on PhysicalComponents. Thank god these are the only ones that have a nature attribute`.

I think we can close this stale PR which is still in draft. @Wuestengecko ?

Yeah, let's just close it. It has been rotting away for a while now, and at this point doing it from scratch would probably be easier than trying to rebase anyways.


Library design

I was looking into this library, trying to work on some issues, and while working with it I noticed that the design of the library doesn’t feel right.
The first thing that bothers me is SimpleCache class, and that it adds additional functionality from the beginning (keys and values normalization, key prefixes, etc., what if you don’t need normalization or you want to handle it yourself) and those methods setValue, getValue etc. that each backend needs to implement instead of implementing interface methods, this is confusing. I think that different backend classes should just implement PSR interface as minimal as possible without any additional functionality and all additional things can be added to decorator (one or several) like Cache class that currently extends functionality.
It will have several significant benefits:

When you are implementing new cache backend, you know exactly what to implement from the PSR interface
The functionality of the new cache backend will be as minimal as it’s required by the interface especially if you don’t need any extra functionality, the library will be more general-purpose and you will have the ability to use it with or without extra functionality
All extra functionality will be added via decorators (one common decorator or several more specific ones)

@samdark, so, what do you think of rewriting of the library a bit to this architecture? Is there any reason why we can’t do this or you don’t see any sense doing this? What if I try to implement it and we’ll see if it’s better than the current one?

2. The functionality of the new cache backend will be as minimal as it’s required by the interface especially if you don’t need any extra functionality, the library will be more general-purpose and you will have the ability to use it with or without extra functionality

Additional functionality seems to be the whole point of this library. If you want to pure PSR interface implementation, there are existing packages for that.

@rob006, all additional functionality that it provides currently will be saved, I suggest to redesign it a bit, so the internal structure will be simpler and more intuitive.
The only difference in usage will be:
$cache = new Memcached(); // pure PSR interface implementation
$cache = new Cache(new Memcached()); // cache with all additional functionality

If you want to pure PSR interface implementation, there are existing packages for that
If there is a good package with pure PSR interface implementations for all backends that are used in this library we could use it and write only additional functionality here, but I don't know what's better, pure PSR implementation is quite simple to maintain it ourselves. And the fact that we will have the ability to swap the PSR implementation classes supports my suggestion of redesign, the library will be more flexible and easier to maintain.

The only difference in usage will be:

AFAIK it already works in this way: Yiisoft\Cache\Cache is a decorator for PSR implementations (handler).
I'm not sure how introducing another layer will simplify anything. SimpleCache actually simplifies implementation (things like key normalization or serialization is a must for many backends). AFAIK SimpleCache is not a requirement, if you don't need any of its features you can create new class without extending SimpleCache.

I’m saying not about adding a layer but removing an extra layer.
Now it’s designed this way: SimpleCache provides some additional functionality and adds abstract methods, then different backend classes provides implementation for those abstract methods, and then Cache decorator provides more additional functionality, so it’s three layers.
What I suggest is backend specific classes implement PSR interface without any extra functionality and then all additional functionality is provided by the Cache decorator, that’s two layers and I think it’s better design.

@alexkart SimpleCache provides code that should be shared between different backends. The best example is key normalization - most of backends has length limit or does not allow some chars as key. If you remove SimpleCache, you need either repeat normalization part in each backend, or create really bad PSR implementation which will break if you provide too long key (so this implementation is quite useless without decorator).
And it is still unclear to me why do you think that implementing cache backend from scratch will be simpler than using SimpleCache as a base. SimpleCache requires to implement only 5 methods and it already handles some basic stuff like serialization or normalization.

Mainly I think that what is wrong with SimpleCache is that it transforms PSR interface into new very simillar interface and it's a bit weird for me.
I don't say that what I suggest will have a huge difference I just think that the structure of the library will be at least simpler and more readable.

that backend classes need to implement and it's a bit weird for me

There is no such requirement. This library does not rely on SimpleCache as a type, this is only a base to keep code more DRY and consistent.

Dropping SimpleCache or moving implementation to individual PSR implementations
If we'll drop SimpleCache we'll have to implement the following in each PSR implementation for cache backends:

key prefixing
default TTL
custom serialization support
key normalization
polyfills in case backend does not support batch operations

The code for points above isn't 100% straightforward so providing it out of the box pre-implemented and unit-tested is simpler than doing it from scratch all the time. So removing this code altogether or moving it to each individual PSR implementation we have is a bad idea.
Decision:  We should keep providing above feature points for cache backend implementers.
Moving implementation into decorator
As an option, all these could be moved to PSR-compatible decorator. We then should somehow to avoid repetitive key normalization but that's doable.
There are multiple issues with it though. First, configuration syntax would get more complicated:
$psrImplementation = new MyPSRCacheBackend();
$driverExtrasDecorator = new DriverExtrasDecorator($psrImplementation); // extra step
$cache = new Cache($driverExtrasDecorator);

In case of separation of key prefixing, customizable serialization etc. it could be even more bloated:
$psrImplementation = new MyPSRCacheBackend();

$decoratedPSRCache = new DefaultTTLDecorator(new CustomSeializationDecorator(new KeyPrefixDecorator($psrImplementation)));

$cache = new Cache($decoratedPSRCache);

That is, of course, very customizable. Decorators could be combined in any variant needed.

It can be done in such a way that from the usage point of view there will be no extra steps.
Here is what it will look like:
$psrCache = new Memcached(); // cache instance that implements PSR interface without any extra functionality
$cache = new Cache(new Memcached()); // cache instance with all additional functionality (key prefixes, normalization, serialization, dependencies, additional methods etc.)

// the features will be configurable

$cache->enableKeyNormalization(); // enabled by default
$cache->disableKeyNormalization();

$cache->setKeyPrefix('prefix'); // no prefix by default

$cache->setSerializer(new JsonSerializer()); // PhpSerializer() by default

In fact, I've already implemented almost all of this to see how it will look like and I can say for sure it looks better for me. While I was working on this I also fixed some issues that I've found, made some refactoring, added lots of tests for uncovered cases.
I've rewritten two backends ArrayCache and Memcached to the minimal PSR implementation, removed SimpleCache class and moved all additional functionality to the Cache decorator.
So, I think I'll create a PR tomorrow or in a few days so that you can look at the code and make a decision.

I guess that won't work well but, of course, I could be wrong.
It is typical for third party PSR implementations to have built-in key normalization, default TTL etc. It varies a lot from implementation to implementation so turning everything on by default will not work for non-Yii implementations while turning everything off will make configuration even worse than using multiple decorators for Yii-implementations.
Anyway, if it's done, please send a pull request and we'll check it.

Another issue with having it in the Cache is that you'll have to type-hint against Yii's cache interface instead of PSR one even if you don't use any extra functionality.

Another issue with having it in the Cache is that you'll have to type-hint against Yii's cache interface instead of PSR one even if you don't use any extra functionality.

Why? If you type-hint PSR cache, of course, you can't rely on methods for configuration (like setKeyPrefix, setSerializer) but you will be using the default configuration (like you use features that are currently in SimpleCache class). If serialization and normalization are enabled by default they will be used.
class Test
{
    public function providesCache()
    {
        $cache = new Cache(new Memcached());
        $this->usesPsrCache($cache);
    }

    public function usesPsrCache(\Psr\SimpleCache\CacheInterface $cache)
    {
        $cache->set('test', 1);
        $cache->get('test');
    }
}

Right. You are correct on this one. Our Cache interface extends from PSR one so could be type-hinted as PSR.

So the only possible issue left is configuration.
What do you mean by this? Currently, you also can't configure it in any way because PSR interface doesn't provide such interface you are using what is passed to you and preconfigured before it gets to a type-hinted method.
So, there is no difference between the current implementation in this one.

Meant this:

It is typical for third party PSR implementations to have built-in key normalization, default TTL etc. It varies a lot from implementation to implementation so turning everything on by default will not work for non-Yii implementations while turning everything off will make configuration even worse than using multiple decorators for Yii-implementations.

i.e. defaults won't work and configuration is becoming very explicit.

I don't get it we can set any defaults we need with new design, to match exactly current implementation or whatever we decide.

With your code we can set defaults for whole Cache i.e. for all implementations at once. With SimpleCache we can set defaults for Yii implementations only.

What is Yii implementation?

What is Yii implementation?
Do you mean the following in current implementation?
$nonYiiCache = new Memcached();
$yiiCache = new Cache(new Memcached());

And you say that they should have different defaults?
OK then, let's create YiiCache decorator which extends Cache and will have different defaults if we really need this, no big deal.
We will have:
$psrCache = new Memcached();
$nonYiiCache = new Cache(new Memcached());
$yiiCache = new YiiCache(new Memcached());

You can choose different defaults or configure everything you need. Quite flexible.

Yii implementation is https://github.com/yiisoft/cache/blob/master/src/ApcuCache.php. Non-Yii implementation is https://github.com/kodus/file-cache/blob/master/src/FileCache.php

Introducing extra decorator is complicating things. I'd prefer having only a single one.

I see your point, you mean if you want to use Cache decorator from this library with non-yii psr implementation. But why would you want to do this? I think it's a bit weird. If you need caching you get one package that satisfies your needs not several of them, I mean it's possible but yes, in this case, you may need to do more configuration then usual. If this library provides whole thing - psr implementations (either it's own or as a external dependency which fits well) and a decorator for them there is no need to adjust decorator for different implementations.
I'm sure that with the current design you can find an external psr implementation that won't fit the Cache decorator perfectly without much configuration.

But why would you want to do this?

Exotic cache backend that you don't want to implement yourself.

I'm sure that with the current design you can also find an external psr implementation that won't fit the Cache decorator perfectly without much configuration.

With the current design defaults are on PSR-16 implementation level so Yii implementations defaults (SimpleCache) do not conflict with whatever is default in external implementation. If you want to "just take a PSR-16 library and use it with Yii" you can do it. You don't have to read its code to find out if it has its own default TTL implementation and configure Yii to turn off its own implementation in this case.

OK, I've created PR. Let me know what you think.


Drop reverse migration dependency

Fix #349

Coverage remained the same at 96.443% when pulling ea931ad1eeb364e6e9bcff21e93f61170bd8dc5d on hotfix/migration_dependency into 7a4b73f1d1fc98645d19dc209ab81568c1bb64e4 on release/0.8.x.

Coverage remained the same at 96.443% when pulling ea931ad1eeb364e6e9bcff21e93f61170bd8dc5d on hotfix/migration_dependency into 7a4b73f1d1fc98645d19dc209ab81568c1bb64e4 on release/0.8.x.

Codecov Report

Merging #351 into release/0.8.x will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff               @@
##           release/0.8.x     #351   +/-   ##
==============================================
  Coverage          92.64%   92.64%
==============================================
  Files                 22       22
  Lines               1237     1237
  Branches             151      151
==============================================
  Hits                1146     1146
  Misses                45       45
  Partials              46       46

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 7a4b73f...2ebd8e2. Read the comment docs.

Coverage remained the same at 96.443% when pulling 2ebd8e2892576b9f68265c0d955264a83b53070c on hotfix/migration_dependency into 7a4b73f1d1fc98645d19dc209ab81568c1bb64e4 on release/0.8.x.


Doesn't work / not connecting

Just seems to get stuck in a loop
Connecting to **** via UDP...
2021-01-18 19:46:33,298 — protonvpn-cli — DEBUG — openvpn_connect:482 — OpenVPN process started
Connection timed out after 45 Seconds
2021-01-18 19:47:18,340 — protonvpn-cli — DEBUG — openvpn_connect:530 — Connection timed out after 45 Seconds
Device "proton0" does not exist.
Failed to bring up VPN :(

Issue confirmed. It's perhaps the most annoying thing about this container 😒.
Not having found the time to fix it, I've resorted to this workaround to recreate the container after a reboot: docker-compose down && docker-compose up -d && docker-compose logs -f. The last one is to verify that the proxy started successfully:
OSError: [Errno 16] Resource busy: '/etc/resolv.conf' -> '/etc/resolv.conf.bak'
2021-01-26 18:43:52.893 7feef4c65d48 Info: Privoxy version 3.0.28
2021-01-26 18:43:52.893 7feef4c65d48 Info: Program name: privoxy
2021-01-26 18:43:52.893 7feef4c65d48 Info: Listening on port 8080 on IP address <IP_ADDRESS>

(The /etc/resolv.conf error is expected, and something else I'd like to fix... eventually 😣.)
My working hypothesis is that the proton0 tunnel device can't survive a container restart (because Docker), and that causes this error. The quickest/easiest solution would be to setup protonvpn-cli from scratch on each container start (not just first one), so that the device is always created.

Issue confirmed. It's perhaps the most annoying thing about this container 😒.
Not having found the time to fix it, I've resorted to this workaround to recreate the container after a reboot: docker-compose down && docker-compose up -d && docker-compose logs -f. The last one is to verify that the proxy started successfully:
OSError: [Errno 16] Resource busy: '/etc/resolv.conf' -> '/etc/resolv.conf.bak'
2021-01-26 18:43:52.893 7feef4c65d48 Info: Privoxy version 3.0.28
2021-01-26 18:43:52.893 7feef4c65d48 Info: Program name: privoxy
2021-01-26 18:43:52.893 7feef4c65d48 Info: Listening on port 8080 on IP address <IP_ADDRESS>

(The /etc/resolv.conf error is expected, and something else I'd like to fix... eventually 😣.)
My working hypothesis is that the proton0 tunnel device can't survive a container restart (because Docker), and that causes this error. The quickest/easiest solution would be to setup protonvpn-cli from scratch on each container start (not just first one), so that the device is always created.

With the changes I was working on today, I got this error when I neglected to specify HOST_NETWORK=<IP_ADDRESS>/16 (my LAN network address). It's probably needed to allow the container to figure out how to route OpenVPN traffic. Try that.


API websockets example is out of date

The API Websockets example in https://github.com/hirosystems/docs/blob/main/docs/get-started/stacks-blockchain-api.md is out of date when compared to the API client docs. We should update it to reflect a more recent example.
Also, the example can be confusing because it's given in the context of Typescript when it's written in JavaScript. We should make clear it's in JS or rewrite it to compile in Typescript.

Relates to #78

Closing in favor of https://github.com/hirosystems/docs/issues/417


[BUG] - Output simulator

Describe the bug
A clear and concise description of what the bug is.
I was just checking the example notebook.
The new simulator does not give the same results as the old simulator. Please see the following file.

For SHFSG there is not Q signal existed.
I would assume if the oscillator modulation type is Hardware, the waveform is the envelop, if it is software, the waveform is the envelop together with oscillator frequency. Correct me if it is wrong.
Based on the assumption on 2, for measure line, it should be a constant envelop with frequency 1e8 Hz. However, the result shows a waveform with frequency 1e6 Hz.
All the devices in the descriptor has sample rate 2GHz, however all the results are showing points with sample rate 20MHz. This may also the cause of problem no.3

To Reproduce
Steps to reproduce the behavior:

Define pulse sequence...
Execute on hardware / in emulation ...
Do additional steps...
See error

run the following notebook
simulator_error.zip
Expected behavior
A clear and concise description of what you expected to happen.
Code & Screenshots
If possible, add example code or serialized LabOne Q data objects, like the Experiment and DeviceSetup, that allow us to reproduce the behavior.
If applicable, add screenshots to help explain your problem.
Versions used:

laboneq 1.4
zhinst-core 22.8
others

Context

[ ] Do you know a workaround for the issue? If yes, please provide a short description.
[ ] Does the issue block your experiments?

Hi @YuanG13, thanks for reporting this. There does seem to be an issue for the SG channels of the SHFSG and QC in the plotting of the simulator. The old simulator can still be used, however, with results = session.run(compiled_experiment,do_simulation=True) and plots the expected result.
As for the documentation, we are working on expanding it now. Your assumption is correct that the modulation HARDWARE should plot the envelope, whereas SOFTWARE modulation should display the waveform with the oscillator frequency. We are looking into why it isn't 1e8 in your case.

Hi @YuanG13, thanks for reporting this. There does seem to be an issue for the SG channels of the SHFSG and QC in the plotting of the simulator. The old simulator can still be used, however, with results = session.run(compiled_experiment,do_simulation=True) and plots the expected result.

I am not really understanding what you meant, I did the same thing in the example notebook. Moreover, the new simulator has zero waveform if the pulse is pi/2 phase, and that is the example notebook you provided. There are clearly something wrong about the output. And also there is no QC involved, it is your own descriptor descriptor_shfsg_shfqa_hdawg_pqsc

fixed in 1.5, closing this issue


Automate build / release process

Update dates on each mod if required (Sea Block, Sea Block Pack, Landfill Painting, Circuit Processing)
Commit to GitHub and create tags
Create GitHub releases
Create .zip for each mod
Upload each .zip to mod portal
Create mod pack .zip
Upload pack .zip to mega
Update Forum post, including breaking changes (if any)
Update Reddit post, including breaking changes (if any)
Update Sea Block wiki with breaking changes (if any)

Automation must work with Windows

part of this is possible using git-hub actions like

https://github.com/Roang-zero1/factorio-create-release-action (bash)
https://github.com/nicolas-lang/factorio-create-release-action (python)

Check https://github.com/nicolas-lang/Factorio.AdvancedAirPurification for a working example:

A Tagged push creates a release which is auto-uploaded to the mod portal.


Fixing async js test

cc @viddo

Frontend tests were OK :+1: (details)

retest this please

Frontend tests were OK :+1: (details)

retest this please

Frontend tests were OK :+1: (details)

@xavijam this seems to do the trick :+1:

merging?

:racehorse:


bup: 0.33.3 -> 0.33.4

Description of changes
Bugfix release
Things done

Built on platform(s)

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

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

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

6 packages failed to build:

git-annex-metadata-gui
git-annex-metadata-gui.dist
python311Packages.git-annex-adapter
python311Packages.git-annex-adapter.dist
python312Packages.git-annex-adapter
python312Packages.git-annex-adapter.dist

19 packages built:

bup
datalad (python312Packages.datalad)
datalad-gooey (python312Packages.datalad-gooey)
datalad-gooey.dist (python312Packages.datalad-gooey.dist)
datalad.dist (python312Packages.datalad.dist)
git-annex (haskellPackages.git-annex)
git-annex.doc (haskellPackages.git-annex.doc)
python311Packages.datalad
python311Packages.datalad-gooey
python311Packages.datalad-gooey.dist
python311Packages.datalad-next
python311Packages.datalad-next.dist
python311Packages.datalad.dist
python311Packages.heudiconv
python311Packages.heudiconv.dist
python312Packages.datalad-next
python312Packages.datalad-next.dist
python312Packages.heudiconv
python312Packages.heudiconv.dist

The failures seem unrelated.


Some roof normals seem incorrect

these sides of the roof should be in shadow, maybe the normals are being smoothed?
https://streets.gl/#51.47754,-0.06461,27.50,280.00,1015.51

the tiles normal map looks like it could be in worldspace or something, i'll try another and see if it fixes it

another case:

https://streets.gl/#51.47754,0.01439,14.50,295.75,175.26

Hmm, it's hard to say whether it's expected behaviour or not. Maybe the normal map is a bit too extreme.

Normal texture for roof tiles had a slight slope baked into it. It should be better now. But besides this normal maps work correctly.


fix: instant panic

ref https://github.com/rust-lang/rust/pull/89926
will publish after merge

panic comes from old library?

panic comes from old library?

maybe，it's std bug，will fix on next release


Improve Kotlinification of LatLng

This avoids breaking compatibility with existing Kotlin code because the setters are now accessible using =, by removing setLatitute / setLongitude and using normal kotlin setters.

@fynngodau Thank you for your contribution. The unit tests do not pass, can you have a look?

@louwers Thanks for your feedback, the tests now compile & pass!


Fixed spec.cljc NS declaration to require clojure.string

Eliminates warning from some build-tooling on use of undeclared var.
Specifically, I was getting this warning on every build/reload my shadow-cljs browser app during development.
------ WARNING #1 - :undeclared-var --------------------------------------------
 Resource: zprint/spec.cljc:381:14
 Use of undeclared Var clojure.string/ends-with?
--------------------------------------------------------------------------------

Please edit as desired & thanks for the library!

Thanks for this, I will fix this in the upcoming release!

I'm integrating this into the upcoming major release, and I am unable to reproduce this issue with my figwheel setup.  Of course, I'm using the older lein-figwheel, not figwheel-main, so maybe that is the difference.
Anyway, in looking more carefully at your proposed fix, I can't see any reason why the (require clojure.string ...) shouldn't be outside of the reader conditional.  That is to say, it seems to me like both Clojure and Clojurescript should have the require for clojure.string.  The code that I'm going with at this point looks like this:
(ns ^:no-doc zprint.spec
  #?@(:cljs [[:require-macros [zprint.smacros :refer [only-keys]]]])
  (:require clojure.string
            #?@(:clj [[zprint.smacros :refer [only-keys]]
                      [clojure.spec.alpha :as s]]
                :cljs [[cljs.spec.alpha :as s]])))

and l left the (clojure.string/ends-with? ...) call alone.
If you have the inclination to test this and see if it solves the problem that you encountered, that would be a huge help -- since I can't reproduce it.  I am going to try to release zprint toward the end of next week (i.e., maybe Oct 16 to Oct 18), so it would be best if you gave me feedback before then, but any feedback any time is always welcome.  I have plenty to do before I get the release out, as this will be a big one and there is a good chance the release will slip beyond Oct 18.
Thanks again!

@kkinnear I tried your changes on local they seem fine -- the warning is gone. Updated PR with the tested code -- looks good & appreciate the follow-through.
The tool I was getting the error from was ttheller's shadow-cljs on version 2.8.45, originally forked off the [re-frame template.[(https://github.com/Day8/re-frame-template) Looks like the compiler is more sensitive than other CLJS build tooling.

I fixed this in 0.5.0, unfortunately not by using your pull request because of the massive development I had backed up.  If you would like to issue a pull request to, say, the readme with a small change I'd be glad to accept it so that you get noted as a contributor.


Change the default value for the "--onnx-op-transform-threshold" from 3 to 10

Change the default value for the "--onnx-op-transform-threshold" option from 3 to 10 to fix the issue 1584 ( https://github.com/onnx/onnx-mlir/issues/1584 )
It should not be an big issue to change the default value from 3 to 10, because of the following reasons.
(1) At least 4 times repeat of the corresponding passes are necessary to fix this issue.
(2) If the target code is not changed by an iteration, further iterations are stopped at the iteration.
Confirmed that this issue is solved by the PR.
Signed-off-by: Yasushi Negishi<EMAIL_ADDRESS>

Confirmed that the issue 1584 is solved by theis PR.

I measured  time to execute "TEST_CASE_BY_USER=test_resnet50_cpu cmake --build . --target check-onnx-backend" by changing the default value from 4 to 10.
We cannot see any slowdown  according to the measurement results.
4: Ran 2026 tests in 156.981s
6: Ran 2026 tests in 157.096s
8: Ran 2026 tests in 156.717s
10: Ran 2026 tests in 157.068s

Fantastic, big thanks

Jenkins Linux amd64 Build #7204 [push] Change the default value... started at 09:25

Jenkins Linux ppc64le Build #6272 [push] Change the default value... started at 10:26

Jenkins Linux s390x Build #7220 [push] Change the default value... started at 10:25

Jenkins Linux amd64 Build #7204 [push] Change the default value... passed after 1 hr 24 min

Jenkins Linux ppc64le Build #6272 [push] Change the default value... passed after 1 hr 56 min

Jenkins Linux s390x Build #7220 [push] Change the default value... passed after 2 hr 5 min


[PF-1622] Remove --defer-login option

Essentially undoes https://github.com/DataBiosphere/terra-cli/pull/119

For posterity, some manual testing I did
~/terra-cli (mc/rm-defer-login): rm ~/.terra/StoredCredential ~/.terra/context.json
~/terra-cli (mc/rm-defer-login): terra auth login
16:46:45.135 [main] DEBUG bio.terra.cli.businessobject.Context - Context file not found. Re-initializing with default values
Please open the following address in your browser:
  https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force&client_id=436986732241-nvjfkarirkhmcq7m3r1uemdau518uvdo.apps.googleusercontent.com&redirect_uri=http://localhost:64268/Callback&response_type=code&scope=openid%20email%20profile
Attempting to open that address in the default browser now...
Login successful<EMAIL_ADDRESS>~/terra-cli (mc/rm-defer-login): cat ~/.terra/context.json
{
  "config" : {
    "browserLaunchOption" : "AUTO",
    "commandRunnerOption" : "DOCKER_CONTAINER",
    "dockerImageId" : "gcr.io/terra-cli-dev/terra-cli/0.176.0:stable",
    "resourcesCacheSize" : 1000,
    "fileLoggingLevel" : "INFO",
    "consoleLoggingLevel" : "OFF",
    "format" : "TEXT"
  },
  "server" : {
    "name" : "broad-dev-cli-testing",
    "description" : "Broad development environment for CLI testing. More stable and updated less frequently than the main development environment.",
    "samUri" : "https://sam.dsde-dev.broadinstitute.org",
    "samInviteRequiresAdmin" : false,
    "workspaceManagerUri" : "https://workspace.verilycli.integ.envs.broadinstitute.org",
    "wsmDefaultSpendProfile" : "wm-default-spend-profile",
    "dataRepoUri" : "https://jade.datarepo-dev.broadinstitute.org",
    "externalCredsUri" : "https://terra-devel-ecm.api.verily.com"
  },
  "user" : {
    "id" : "101088336157487693460",
    "email"<EMAIL_ADDRESS>    "proxyGroupEmail"<EMAIL_ADDRESS>    "petSAEmail" : null,
    "useApplicationDefaultCredentials" : "BROWSER"
  },
  "workspace" : null,
  "versionCheck" : {
    "lastVersionCheckTime" : "2022-05-06T16:46:48.776102-07:00"
  }
}~/terra-cli (mc/rm-defer-login): terra auth status
User email<EMAIL_ADDRESS>Proxy group email<EMAIL_ADDRESS>Service account email for current workspace: (undefined)
LOGGED IN
~/terra-cli (mc/rm-defer-login): terra server set --quiet --name=verily-devel && terra workspace list
Terra server is set to verily-devel (CHANGED).
Please open the following address in your browser:
  https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force&client_id=436986732241-nvjfkarirkhmcq7m3r1uemdau518uvdo.apps.googleusercontent.com&redirect_uri=http://localhost:64304/Callback&response_type=code&scope=openid%20email%20profile
Attempting to open that address in the default browser now...
   NAME                            GOOGLE PROJECT                  ID                                    DESCRIPTION
   (unset)                         terra-vdevel-perky-turnip-6765  f0f26599-7834-4919-89bb-80f406410624  (unset)
   I am the workspace for buoy...  terra-vdevel-buoyant-plum-9341  0152a77f-0f0c-430b-94ab-b4798fa5a990  (unset)
   strong pear                     terra-vdevel-strong-pear-2651   66f7628b-aa58-4372-946c-25e9a15a6853  (unset)
~/terra-cli (mc/rm-defer-login): terra workspace set --id=0152a77f-0f0c-430b-94ab-b4798fa5a990
Workspace successfully loaded.
Terra workspace id: 0152a77f-0f0c-430b-94ab-b4798fa5a990
Display name: I am the workspace for buoyant plum
Description:
Google project: terra-vdevel-buoyant-plum-9341
Cloud console: https://console.cloud.google.com/home/dashboard?project=terra-vdevel-buoyant-plum-9341
# Resources: 4
~/terra-cli (mc/rm-defer-login): terra workspace describe
Terra workspace id: 0152a77f-0f0c-430b-94ab-b4798fa5a990
Display name: I am the workspace for buoyant plum
Description:
Google project: terra-vdevel-buoyant-plum-9341
Cloud console: https://console.cloud.google.com/home/dashboard?project=terra-vdevel-buoyant-plum-9341
# Resources: 4
~/terra-cli (mc/rm-defer-login): terra auth revoke
Logout successful.
~/terra-cli (mc/rm-defer-login): terra workspace describe
Please open the following address in your browser:
  https://accounts.google.com/o/oauth2/auth?access_type=offline&approval_prompt=force&client_id=436986732241-nvjfkarirkhmcq7m3r1uemdau518uvdo.apps.googleusercontent.com&redirect_uri=http://localhost:64334/Callback&response_type=code&scope=openid%20email%20profile
Attempting to open that address in the default browser now...
Terra workspace id: 0152a77f-0f0c-430b-94ab-b4798fa5a990
Display name: I am the workspace for buoyant plum
Description:
Google project: terra-vdevel-buoyant-plum-9341
Cloud console: https://console.cloud.google.com/home/dashboard?project=terra-vdevel-buoyant-plum-9341
# Resources: 4
~/terra-cli (mc/rm-defer-login): terra auth revoke
Logout successful.
~/terra-cli (mc/rm-defer-login): terra auth status
NO USER LOGGED IN


No such file or directory

When the output folder does not exist, it throws an error. Is there a way to configure the plugin to create the folder tree if not existent?
Thank you

I figured this out.
You need to make sure the directory structure pre-exists
I solved this by
import fs from "node:fs";
const folderName = 'public/build/assets';

  try {
    if (!fs.existsSync(folderName)) {
      fs.mkdirSync(folderName, {recursive: true});
    }
  } catch (err) {
    console.error(err);
  }

This will create the folder structure if it doesn't exist


Period in the layer name caused truncated name for exported file

What went wrong?
I had a few layers with . in the layer name eg "Ms. Pac-Man". The export truncated the filename to "Ms.png"
If you can, tell us the steps to reproduce the problem.
Create a few layers with periods in the name; export
Configuration
Version of Export Layers:
4.0.2
Version of GIMP:
2.10.36
Operating system:
Windows 11
Procedures and constraints added in Export Layers (in the Export Layers dialog, choose Settings → Show More Settings to display them):

Also, I love this. Thanks for making it.

Try typing [layer name, %e] into the text field next to Save as: (if you don't see it, click on the Settings button -> Show More Settings). This should preserve the original layer name (instead of removing everything after the last '.').


Group theme imports in variations

For each variation in the page-secion folder, these imports should be grouped.
import { xxxLight } from '../../themes/xxx/xxx-light'
import { xxxDark } from '../../themes/xxx/xxx-dark'
import { elementStyles } from '../../themes/xxx/elements/element-styles'
import { sectionBlockStyle } from '../../themes/xxx/sections/section-block-style'
import { styledSystemConfig } from '../../themes/xxx/styled-system/styled-system-config'

Fixed by 771d19e


Unit-test wildcard selector equality in rule creation

Refactor the equality checks into functions, and unit-test those
functions with some basic wildcard selector equality checks.
These can be extended in future for more nuanced equality checks if necessary.

This change is

Minor refactor + only unit-test changes should not affect ginkgo run.

Coverage increased (+0.03%) to 45.39% when pulling 5f73304a9a5a689dcdb85bcc95a29952f5cfb53c on joestringer:submit/rule-equality-tests into e7bc8918daf8a3c8b599f1ec84a3ee7544249f62 on cilium:master.


Add env.d.ts changes to  V3 @astrojs/image migration

What kind of changes does this PR include?

New or updated content

Description

Adds an extra step for updating the env.d.ts file or the tsconfig.json file, which had special @astrojs/image types in them some of the time. You can see a reference to them in the old integration readme.

I was just upgrading an old project to Astro 3 and ran into this missing step, so I figured it should add it (hopefully this PR doesn't rot for months this time... 😅).
Also, I'm not entirely sure how the code block diff highlighting works, so please feel free to fix it if I did it wrong.

Looks good now! Thanks for adding, and sorry you had to find out the hard way!  :joy:


Mobile Support

Testing Mari0 in iOS 9 Safari (yes I know controls won't work) ends up erroring out when loading:
11950104 - Exception catching is disabled, this exception cannot be caught. Compile with -s DISABLE_EXCEPTION_CATCHING=0 or DISABLE_EXCEPTION_CATCHING=2 to catch.
  callMainlove.js:23:11938
  setStatusmari0:76
  (anonymous function)love.js:23:12543

Wondering if there has been consideration for mobile web support?

Pretty sure Mari0 has joystick enabled. Won't work in mobile or safari. #24 is important for solving this.

Not gonna re-open - but that exception is generated from the Joystick problem?

I think so. I've been through a lot of stuff since then but when I last tried stuff on Safari that looked like the problem.

Sounds good. I will then continue conversation/findings on #24
Cheers!


Fix coverage reporting

This may be blocked by #14, since a shpy container would make it easy to control and debug our kcov environment. Looks like kcov isn't behaving properly and is spewing output to stdout when it should be in PS4 or something, which causes builds to fail with no reporting data

Looks like an issue with any kcov container newer than v33, so I've reverted since v33 works for our purposes


Two tooltips appear on top of each other during code completion

See the following video — when you type the opening parenthesis after the .Add method, previously you'd just see the method arguments in the code completion tooltip as expected, but now another useless/irrelevant window appears on top of that and covers it, so you have to press Esc to get rid of it. This happens constantly and is extremely annoying.
https://github.com/dotnet/vscode-csharp/assets/26527405/76784d79-8304-4f25-8cfa-c4a88012a9d2
Environment data
VS Code version: 1.83.0 — e7e037083ff4455cf320e344325dacb480062c3c
C# Extension version: v2.5.30

Note - this is due to the location of the code and window size.  The signature help window is supposed to appear above the line, while the completion list appears below.  However if there is not enough space in the text editor window above, they will appear overlapped.
This behavior is defined by VSCode.  The most we could do on the extension side is have an option to disable completion in argument lists, which I'm not sure we want to do.

@dibarbet The argument list IS THE ONE THAT SHOULD BE SHOWN. Just don't show the other useless one that appears in these contexts. v1.x literally worked properly. Why can't you just do the same thing you used to?!

This is v1.26.0:
https://github.com/dotnet/vscode-csharp/assets/26527405/10af311a-ce83-4869-8f5c-cb08865a938d

This is what it looks like in v1.26.0:
https://github.com/dotnet/vscode-csharp/assets/26527405/b8bacd06-123e-434d-9575-1e7a351a746f

This is still happening. No matter of the code location and where they're rendered, unless completion you need is for AbandonedMutexException or something else that is at the start of the alphabet, the completion is rarely what I want. I press Esc to get rid of it 100% of the time, which is annoying.
And after getting rid of the completion, typing a character gives completion again, which is when I want the completion to happen so only opening the parenthesis is where completion should not be shown.
The signature help window is what I expect to see and if there are overloads, I expect to be able to cycle through them with up/down arrows. This works only after Esc(aping) the completion window.
Are we he minority here with @aradalvand and think this behavior is counterproductive? 😄 If so, is there a setting for this that I didn't find?

Option dotnet.completion.triggerCompletionInArgumentLists to disable completion in argument lists added in https://github.com/dotnet/vscode-csharp/pull/7446.
This is not released yet, but should be part of next weeks prerelease update.  Will post here once it is available.

This is available in 2.45.17 prerelease.  Unchecking dotnet.completion.triggerCompletionInArgumentLists will prevent the completion list from showing up in argument list contexts (you will only see signature help).


feat: adds glob support for dir and ignorePattern

adds support to work with glob patterns for dir and ignorePattern as alternative to the current implementation (which uses dir as relative path to cwd() and generates a regex from ignorePattern.
CLI requires to additionally set the flag --use-glob while the RunnerOptions for API have been extended with a useGlob boolean property.
When using glob, migration files are sorted by their absolute path (via String.localeCompare) while setting numeric: true in the Intl.Collator().
The original sorting has not changed (still attempts to extract Date from the filename (either utc or timestamp) and sorts by the date's numeric value if possible - localeCompare otherwise)
This also fixes the most parts (if not all) of #932 and thus makes #1226 obsolete
Seems to make #911 obsolete as well

looks like you were working from your old main branch 🙂
please update the branch and resolve the conflict

Set to draft for now, because some failing tests
Looks like you are already a trusted contributor, so the tests will run automatically 🙂
I gave a really simple first review, but I need to have a look into details, but assume I wont have time before upcoming Saturday, because I will be on a conference
But it looks really promising and potentially even like a better solution that the other strategy ❤

It may not matter so much in this case, but I recently had to implement some globbing behaviour and found fdir (https://www.npmjs.com/package/fdir) to be much more performant. Should be a simple swap.

It may not matter so much in this case, but I recently had to implement some globbing behaviour and found fdir (npmjs.com/package/fdir) to be much more performant. Should be a simple swap.

... Lets stay with glob for now, I plan anyways to use glob from node:fs when we are on Node v22 https://nodejs.org/api/fs.html#fsglobpattern-options-callback

It may not matter so much in this case, but I recently had to implement some globbing behaviour and found fdir (https://www.npmjs.com/package/fdir) to be much more performant. Should be a simple swap.

if you're going with pure js implementations, there is no faster lib that adheres the de-facto-spec as good as this one.
Also see Comparison to Other JavaScript Glob Implementations.
I don't think that performance is that much of the essence here either.

Might release next few days, I also currently await feedback of https://github.com/salsita/node-pg-migrate/discussions/1262


Unable to Fetch or Print API Data in Flutter

I am trying to fetch the data from themoviedb api. But I am not able to fetch the data and print in the console. Can you guys help and let me know, what I am doing wrong. Is it something to do with stateful and stateless widgets? I also tried calling other api's like Open Weather Data, even that is not working.
Thanks Here's the code:
import 'package:flutter/material.dart';
import 'package:flutter/rendering.dart';
import 'package:tmdb_api/tmdb_api.dart';
import 'constants.dart';
import 'dart:convert';
import 'package:http/http.dart' as http;

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData.dark(),
      home: Scaffold(
        appBar: AppBar(
          title: Text('~Movies~'),
        ),
        body: ComingUpStuff(),
      ),
    );
  }
}

class ComingUpStuff extends StatefulWidget {
  @override
  _ComingUpStuffState createState() => _ComingUpStuffState();
}

class _ComingUpStuffState extends State<ComingUpStuff> {
  @override
  void initState() {
    super.initState();
    movieDetails();
  }

  void movieDetails() async {
    http.Response response = await http.get(
        'https://api.themoviedb.org/3/movie/283995?api_key=1a50e9ef85b68886cd516972fe9e7508&language=en-US');
    print(response.body);
  }

  @override
  Widget build(BuildContext context) {
    return Row();

Hi @iamphoenix310
This platform is not meant for assistance on personal code.
I'd recommend to avoid calling async functions inside initState
you may want to use, for example,  a FutureBuilder
Please see https://flutter.dev/community for resources and asking questions like this,
you may also get some help if you post it on Stack Overflow.
Closing, as this isn't an issue with Flutter itself,
if you disagree please write in the comments and I will reopen it
Thank you


Added Update for Play services Base and Basement Library

Description:
Added Update for the Google Play services Base and Basement library from version 17.4.0 to its latest version 17.6.0 which was released on February 3rd, 2021. Also tested and verified on various scenarios while running the android application.

Library update was addressed in #166 . Closing this PR as per comment in #151 .


Refactor backend permissions

Did encounter a problem while preparing the dashboard development environment: Currently we rely for the authorization 100% on scopes for role assumptions. Firstly not all providers support this behaviour (e.g auth0 and keycloak do, zitadel doesnt currently) and we cant really handle this in our frontend as we do not know which scopes we actually need and we do not want to make 10000 redirects per operation
Therefore we should switch to a claim based process.

This refactor wont cover permission assignments to specific clients / groups for specific resources identified by an id. This will be a later feature

NVM the implementation for permissions on specific resources shouldn't be that hard with the current refactoring. We should be able to create this permissions with the config and on runtime (as many users probably won't use / need preset creation with predefined identifactors and won't restart with different config after they know the exact resource ids).
Allowing this modification via runtime means we have to store this information somehow in the database. We would probably need to create a new CRUD Sscheme for this specific permissions grants and own gRPC endpoints therefore. This will require quite some effort but should work and be quite performant utilizing the skytable caching for high-avability deployments


Upgrade Protobuf Dependency

Upgrades protobuf dependency to be compatible with the new v2 golang protobuf API.
Switches to go modules dependency tracking, drops vendoring
Updates WORKSPACE name
Drops support of gogo due to lack of support for the new API and https://github.com/gogo/protobuf/issues/691

Dropping GoGo support seems like it merits discussion. @kyessenov, you requested and added support for GoGo proto, what are your thoughts?

FWIW, go-control-plane no longer uses gogo protos as of https://github.com/envoyproxy/go-control-plane/pull/226

This seems to also be a lot of changes in one, which is concerning incase we run into problems with just one of the changes that we weren’t expecting, or for the ones that require more discussion like gogo support (I realize go-control-plane doesn’t use it anymore, but do others? Do they need it for a bit longer to migrate off?)
Is there any particular reason we can’t separate these to say:

one for upgrading to protov2
one for dropping gogo support
one for changing the local build to go mod?

sure, I can work on separating the changes, but they will probably need a specific order. I kind of worked backwards on this from my goal of adding proto v2 support.


A lot of the data in the landscape seems old

The commits, the twitter posts, a lot of the data for the cards seem to be out of date.

@AndreyKozlov1984 can you please look into this? thanks.


High level design documentation?

I'm currently reading the excellent documentation on rustc's query system, and wondered what your plan for Wild is regarding achieving incremental linking? Do you have some documentation or design drafts, or is this all still far out in the future?

I am getting closer to the point where I'll probably start looking at implementing incremental compilation soon. I haven't decided on a concrete plan as yet. I do have two possible ways that I'm considering.
One is to keep the linker in memory. Effectively have a cargo-watch style command, that runs cargo, wraps rustc, then watches for changes to any source files. When it sees a source file change, reruns the relevant rustc command directly (without invoking cargo), then takes the new outputs from rustc and integrates them into the existing in-memory link.
The other approach is to persist bits of state to disk, then when invoked, load that state, see what input files have changed and reprocess those. I wouldn't want to use any serialisation for persisting state, since that would be too slow. Rather I'd just make the on-disk format be the same as the in-memory format, so that the files can just be mmapped. That would require that the in-memory format not use any references. Most of Wild's in-memory structures already don't use any references. The biggest exception is the symbol name map, which borrows string slices from the original input files. So that would need to change. The tricky part is changing it in a way that doesn't kill performance. I suspect I should continue to reference the original input files, but just do so in a way that doesn't use references.

Interesting, thanks for the answer!
Just curious now, would there be any idea in merging the linker into a fork of rustc itself, probably with cranelift too, so that all the parts of the compiler can share the query system, and we can have "truly" incremental compilation? But that'd probably be too big of an undertaking.


Error: Cannot find module 'package.json'

It runs failed on GitLab runner.

related https://github.com/shashkovdanil/clean-publish/issues/110

I can reproduce it on Node REPL.

@antonk52 we have this issue in clean-publish

Thank you for the issue! I will be able to take a closer look later on tonight, in the meanwhile can you add reproducible steps to the issue description? @JounQin

I want to reproduce it too, but it only occurs on our GitLab CI runner sadly.
We're using node:lts-alpine.
It occurred when there is no config for clean-publish.

From a brief look from my phone it looks like an issue with cwd when running the clean publish. You should get the same result if you’d use cosmiconfig since they work identical in this regard.
the comment with nodejs repl is not really useful here since it should be run in the same dir as the clean publish being executed in order to pick up the config or find it in package.json file.
Once again sorry for a delayed reaction. Been off for a vacation.
I’m going to have a closer look after work. Would you mind creating a repo where the issue is reproducible or linking to your project if it’s openly available?

From a brief look from my phone it looks like an issue with cwd when running the clean publish. You should get the same result if you’d use cosmiconfig since they work identical in this regard.

We're using other packages depends on cosmiconfig, but it never happens before.

Would you mind creating a repo where the issue is reproducible or linking to your project if it’s openly available?

I will try to reproduce later, but it occurred on our private own GitLab service, so I have to figure out how to reproduce first. 😂

@JounQin looking at how clean-publish uses lilconfig
It would walk down the directories relative to where the command was executed, ie if you current working directory is /Users/Foo/path/to/project, it will try these paths in this order until it finds a config or returns null
paths:

/Users/Foo/path/to/project/package.json

/Users/Foo/path/to/project/.clean-publish

/Users/Foo/path/to/project/.clean-publish.js

/Users/Foo/path/to/package.json

/Users/Foo/path/to/.clean-publish

/Users/Foo/path/to/.clean-publish.js

/Users/Foo/path/package.json

/Users/Foo/path/.clean-publish

/Users/Foo/path/.clean-publish.js

/Users/Foo/package.json

/Users/Foo/.clean-publish

/Users/Foo/.clean-publish.js

From what I can see in the description the check for accessible file has passed and we try to require the file here.
The one thing that stands out for me is that the path in the logs provided is Error: cannot find module "package.json". If we print searchItems from the source code the paths are absolute(example /Users/Foo/path/package.json) instead of filenames only.
This is as far as I can say from all the information provided so far. For further debugging and a potential fix I would need a reproducible example and more information about the environment where this error occurs, ie os and node version.

It would be better to have a debug mode.
I'll try to use patch-package for debugging first.

as an alternative I could ask you to create a task in your CI (to run it once and share the log) with the code below. I've copied the code from how clean-publish uses lilconfig to see if it will throw an error if we call lilconfig explicitly. It also prints info about the current working directory and nodes version and OS that the script is being run on. This should provide enough info to narrow down what causes the error.
const {lilconfig} = require('lilconfig')

console.log('common info', {
  cwd: process.cwd(),
  version: process.version,
  arch: process.arch,
  platform: process.platform,
})

async main() {
  const result = await lilconfig('clean-publish', {searchPlaces: ['package.json', '.clean-publish', '.clean-publish.js']})
    .search()
    .catch(error => {
      console.log('search error:', error)
    })

  console.log({result})

  return result;
}

main().catch(error => {
  console.log('main error:', error)
  process.exit(1)
})

@antonk52 Sorry I was busy these days.
I've just tried your debug codes, and here is the logs:
common info {
  cwd: '/builds/frontend/custom-webpack',
  version: 'v12.18.4',
  arch: 'x64',
  platform: 'linux'
}
search error: Error: Cannot find module 'package.json'
Require stack:
- /builds/frontend/custom-webpack/node_modules/lilconfig/dist/index.js
- /builds/frontend/custom-webpack/test.js
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:965:15)
    at Function.Module._load (internal/modules/cjs/loader.js:841:27)
    at Module.require (internal/modules/cjs/loader.js:1025:19)
    at require (internal/modules/cjs/helpers.js:72:18)
    at Object.search (/builds/frontend/custom-webpack/node_modules/lilconfig/dist/index.js:108:33)
    at async main (/builds/frontend/custom-webpack/test.js:11:18) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/builds/frontend/custom-webpack/node_modules/lilconfig/dist/index.js',
    '/builds/frontend/custom-webpack/test.js'
  ]
}
{ result: undefined }

After using patch-package, I got searchPaths like the following:
searchPaths: [
  '/builds/frontend/custom-webpack',
  '/builds/frontend',
  '/builds',
  ''
]

Just a shot in the dark, but it looks like lilconfig uses require to load package.json:
https://github.com/antonk52/lilconfig/blob/4544c651f152fe96182650a78c8b763077265594/src/index.ts#L71
https://github.com/antonk52/lilconfig/blob/4544c651f152fe96182650a78c8b763077265594/src/index.ts#L205-L206
This is a risky thing to do these days, because sometimes people add a package exports field without allowing access to package.json (with and without the .json file extension) like this:
https://github.com/jaydenseric/graphql-upload/blob/bdb5f808e0d514c28c0f59c1abd71680aba29bae/package.json#L41-L42
Maybe this sort of problem relates to this issue? Regardless, it's a good idea to stop assuming that because a .js or .json file exists in a package that it can be read using require. Either:

Prevent an error in this situation in lilconfig, and the burden lies on package authors to publish correct packages.
Don't respect package exports, and use fs.readFile instead of require or import to access the contents of config files within packages.

Note that when this lilconfig migrates to pure ESM you won't be able to import .json files, and will be forced to use fs.readFile anyway.

@jaydenseric No, the key problem here is searchPaths with resolve '' if the cwd is not under os.homedir(), but it should be '/', because /package.json is an absolute path, but package.json is not.

@jaydenseric I've thought about loaders using require and don't think that's the case here. @JounQin already provided a fix in #19 which will be merged shortly. But I'd like to elaborate on the loaders for transparency.
Lilconfig tries to mimic cosmiconfig as much as possible. You can see the test cases to how it was tested to be as compatible with cosmiconfig at its best.
Cosmiconfig essentially uses the similar approaches to load js and json files

for json it uses parse-json module in order to provide a more human friendly error messages, though it would throw for an invalid json the same as require does but with a different message. Please see this test case for an example
for js files cosmiconfig uses import-fresh module to be able to require cached files as fresh ones. Internally it uses require also.

I would like to preserve the tight compatibility with cosmiconfig and avoid adding functionality that can diverge with cosmiconfig.

This should be fixed in the v2.0.3 release.
Feel free to reopen if the error occurs again.


Set up pre-commit hooks for client-side code

Set-Up pre-commit hooks for ES-Lint.

Note: It'd be good if all current ES-Lint issues are addressed prior to instituting pre-commit hooks.

Note: It'd be good if all current ES-Lint issues are addressed prior to instituting pre-commit hooks.

Only one issue is remaining to restore two of the major rules #910 .


Error in settings screen after upgrading to 4.2

I have uninstalled version 4.1 before installing version 4.2. When trying to access the settings screen, the app crashed and exits. I have had to clean the application data to avoid the error:
adb shell pm clear me.micrusa.amaztimer

I didn't have any problem uninstalling and installing, but there might be problems when installing it over 4.1 because I used the same key for age and weight after changing type of preference, so I added a note to the release. Thanks :)


Add FR spellcheck + Adjust site.baseurl

Add FR spellcheck
Enable spellcheck of Blog Posts (+ adjustment of content)
Changed content references of {{site.baseurl}} to /ITStrategy as some paths were detected by spellchecking. We can easily change again if we have a different URL in the future. Also, it is easier to remember.

Adding French spellcheck is a good idea. Also enabling cspell for Posts.
But I still think we should keep the site.baseurl by dropping 42f6752
The errors with the spellcheck come from image file names stored in assets. We could change file names or add the words to cspell. There's also probably a way to tell cspell to ignore regular expressions..

@smellems Sure, I'm open to these 3 options. Which one do you recommend?

@smellems Sure, I'm open to these 3 options. Which one do you recommend?

I had done it here https://github.com/sara-sabr/ITStrategy/pull/523/commits/70d666b6bf019f7c5962c625275c52f13286420e in PR #523 where most of these same changes are already.  Just added the words to cspell, probably the simplest way
Can you also cleanup #523 so we don't have the same changes in multiple PRs open at the same time.  I noticed the gitignore changes are also in #532

@smellems Sure, I'm open to these 3 options. Which one do you recommend?

I had done it here 70d666b in PR #523 where most of these same changes are already. Just added the words to cspell, probably the simplest way
Can you also cleanup #523 so we don't have the same changes in multiple PRs open at the same time. I noticed the gitignore changes are also in #532

Done. PR #523 and #532 have been cleaned up. This PR should be the only one with changes to cspell and .gitignore.

Je pense qu'on devrait aussi enlever les modifications aux variables site.baseurl

Je pense qu'on devrait aussi enlever les modifications aux variables site.baseurl

Bon point, c'est fait! :)

Le build ne passe pas parce que le URL joint l et amélioration en un seul mot... ça risque d'être un problème récurrent en français...
On peut ajouter chaque terme combiné dans les exceptions (un peu comme les acronymes en Anglais) mais on ouvre la porte à des coquilles dans le corps du texte.

Faudrait plutôt utiliser les RegExp
https://www.npmjs.com/package/cspell#predefined-regexp-expressions

Faudrait plutôt utiliser les RegExp
https://www.npmjs.com/package/cspell#predefined-regexp-expressions

Il faudrait effectivement trouver un moyen que le cspell ne s'applique pas aux hyperliens ou sources des images.
Je vais merger pour l'instant et créer une issue séparée.


Create copy of dataframe in public_data_interface.py to avoid user data corruption

It seems like the user dataframe is corrupted as public_data_interface.py tries to change the metdata in case of categorical columns. The fix is to make a copy of data and use the copy throughout the data interface.
Signed-off-by: gaugup<EMAIL_ADDRESS>

Makes sense, Approved.


Add Example for an IWDG on an STM32F4 with RTIC v1.0

This adds a simple example for how an IWDG can be used with RTIC on an STM32F4 microcontroller. It has been tested against an STM32F401RE CPU on a Nucleo F401RE development board with the built-in user button connected on PC13.
This has been tested with stable Rust 1.65.0, it is unknown which older versions of Rust also support this, but the support is determined by the used libraries.
The CHANGELOG.md has been slightly extended to align it more closely with the "keep a changelog" standard which it tries to adhere to. This might need updating in case some of the entries have already been released (are there even releases of this repository? If not, the file doesn't make too much sense and the commit history should IMHO suffice).
Solves rtic-rs/rtic-examples#42

I think it looks good, efficiently showcasing the use of a watchdog
   Compiling stm32f4_independent_watchdog v0.1.0 (/home/runner/work/rtic-examples/rtic-examples/rtic_v1/stm32f4_independent_watchdog)
error: linker `flip-link` not found
  |
  = note: No such file or directory (os error 2)

error: could not compile `stm32f4_independent_watchdog` due to previous error

I think installing/providing flip-link in CI seems sensible, so that's what's going on in #46. When flip-link is available we can re-trigger GHA and get this merged :+1:

I think installing/providing flip-link in CI seems sensible, so that's what's going on in #46.

ah, great, thanks! i was about to just remove flip-link from my example (as it isn't really needed for a watchdog example) when i saw the build failure, but this way around is of course also great 🙂

Could you please rebase, there's been some changes in CHANGELOG primarily

Could you please rebase, there's been some changes in CHANGELOG primarily

done. thanks for merging the other PRs!


Seawwedfs has a problem handling ports with 5 digits

My docker-compose:
version: "3.3"
services:
  master:
    container_name: seaweed_master
    image: chrislusf/seaweedfs:latest
    restart: always
    command: 'master -ip="<IP_ADDRESS>" -port=29001 -volumeSizeLimitMB=1024'
    networks:
       ocean:
         ipv4_address: <IP_ADDRESS>
  volume:
    image: chrislusf/seaweedfs:latest
    networks:
       ocean:
         ipv4_address: <IP_ADDRESS>
    command: 'volume -ip="<IP_ADDRESS>" -max=19 -mserver="<IP_ADDRESS>:29001" -port=30000'
  filer:
    image: chrislusf/seaweedfs:latest
    ports:
      - 31000:31000
    command: 'filer -master="<IP_ADDRESS>:29001" -ip="<IP_ADDRESS>" -port=31000'
    tty: true
    stdin_open: true
    networks:
       ocean:
         ipv4_address: <IP_ADDRESS>
networks:
  ocean:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: <IP_ADDRESS>/22
          gateway: <IP_ADDRESS>

Filler log:

I1217 23:54:30.369233 file_util.go:23 Folder /data Permission: -rwxr-xr-x

I1217 23:54:30.374919 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:32.168861 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:33.961961 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:35.755589 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:37.548793 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:39.342633 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:41.135520 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:42.928424 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:44.721807 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:46.514722 volume_grpc_client_to_master.go:43 checkWithMaster <IP_ADDRESS>:29001: get master <IP_ADDRESS>:29001 configuration: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:39001: connect: connection refused"

I1217 23:54:53.335709 disk_location.go:226 Store started on dir: /data with 0 volumes max 19

I1217 23:54:53.336036 disk_location.go:229 Store started on dir: /data with 0 ec shards

I1217 23:54:53.336366 volume_grpc_client_to_master.go:52 Volume server start with seed master nodes: [<IP_ADDRESS>:29001]

W1217 23:54:53.338201 tls.go:39 pemfile.NewProvider({   5h0m0s}) grpc.volume failed: pemfile: at least one credential file needs to be specified

I1217 23:54:53.338978 volume.go:369 Start Seaweed volume server 30GB 3.37 438146249 at <IP_ADDRESS>:30000

I1217 23:54:53.341626 volume_grpc_client_to_master.go:109 Heartbeat to: <IP_ADDRESS>:29001

Notice that filler try to connect with <IP_ADDRESS>:39001 but nowhere in docker-compose have I defined port 39001.
Because when I remove two zeros and use for example 291 and 300 everything works fine I assume Seaweedfs has a problem handling ports with 5 digits.
This is especially frustrating because I also interact with filler.sync and when I try to point to one of my host nodes with a 5 digit port:
I1217 23:40:20.774677 config.go:59 Reading security.toml from /etc/seaweedfs/security.toml

E1217 23:40:20.843005 filer_sync.go:129 get filer 'a' signature 0 error from srv10.mikr.us:40098 to my.home.domain:31000: GetFilerConfiguration my.provider.domain:40098: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp <IP_ADDRESS>:50098: connect: connection refused"

Unfortunately I can't just use a different port in this situation as my VPS provider provides gives me a only few ports. Each with 5 digits

After checking again, I'm starting to understand it. So fillers use gRPC to communicate with each other and ports are assigned automatically by adding 10000. Right?
https://github.com/seaweedfs/seaweedfs/blob/2e78a522ab3892debf9aefeb978177678ae52a83/weed/pb/grpc_client_server.go
For me, this makes this software completely unusable.
Isn't there an option somewhere in the command line or in the configuration file to change this value?

https://github.com/seaweedfs/seaweedfs/wiki/FAQ#grpc-ports


Normalize URLs for Windows

Normalize URLs so hybridly imports them as expected on Windows.

I think this should be done on the PHP side? We use DIRECTORY_SEPARATOR here: https://github.com/hybridly/hybridly/blob/0.x/packages/laravel/src/Support/VueViewFinder.php#L164
Also I'm curious because Hybridly was reportedly working on Windows (one of the devs in my team use it) 🤔

Tracking in https://github.com/hybridly/hybridly/pull/91


Learning React mohsin

[x] 3 hour 24 min video tutorial for react native this one

[x] 1st 45 mins
[x] 2nd 45 mins
[x] 3rd 45 mins (scroll view)
[x] 4th 45 mins (buttons, images, components)

[x] TutorialsPoint

[x] Overview
[x] Environment setup
[x] App
[x] State
[ ] Props
[ ] Styling
[ ] Flexbox
[ ] ListView
[ ] TextInput
[ ] ScrollView
[ ] Images
[ ] HTTp

[ ] Youtube :https://www.youtube.com/watch?v=usmvrBShCCU&list=PL8p2I9GklV468O2wk-n8Q1KmtMhnHHj4C&index=4

[x] 1
[x] 2
[x] 3
[x] 4
[x] 5 (file structure)
[x] 6
[x] 7
[x] 8
[x] 9
[x] 10
[x] 11
[x] 12
[x] 13 -Get input
[x] 14 -Form
[x] 15 - map
[x] 16- flex
[x] 17- grid
[ ] 18-
[ ] 19-
[ ]

closing the issue, please open if u continue this


[Bug] Atomic speculation in Map

🐛 Bug Report
We need the ability to "atomically speculate".
The basic problem is this:
1. start_atomic
2. insert(k, 0)
3. let v = get(k) + 1
4. insert(k, v)
5. let v2 = get(k)
6. assert_eq!(v, v2)

Step 6 will fail because v2 == 0 != v

This chain of operations would currently work as follows:
1. start_atomic
2. insert(k, 0) // nothing gets inserted yet
3. let v = get(k) + 1 // the get would return nothing (unless k had already existed before)
4. insert(k, v) // nothing gets inserted again
5. let v2 = get(k) // this would return nothing as well
6. assert_eq!(v, v2) // this would probably not even be reached

But I think I get what we're after here; I'll check the related APIs and see what we can do about it.


[Suggestion] Add a convenient way to install and update modpacks.

It could be something similliar to prism launcher:

Sorry, mod management features are not planned. It is recommended to use an external mod manager like ferium to manage mods and modpacks with olauncher.


Minor fixes related to the comments feature

Description

Update toggle button theme and icons
Fix comments onboarding modal z-index
Fix reaction when adding to an already added reaction, update list of users who reacted

Type of change

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

manually

Checklist:

[ ] My code follows the style guidelines of this project
[ ] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] New and existing unit tests pass locally with my changes

Test coverage results :test_tube:
:red_circle: Total coverage has decreased
// Code coverage diff between base branch:release and head branch: collab-fixes-3

Status
File
% Stmts
% Branch
% Funcs
% Lines

:red_circle:
total
54.13 (-0.01)
36.08 (-0.04)
32.83 (-0.01)
54.63 (-0.01)

:red_circle:
app/client/src/comments/CommentCard/CommentCard.tsx
73.49 (-0.45)
65.49 (-1.18)
43.9 (0)
74.03 (-0.48)

:red_circle:
app/client/src/components/ads/EmojiReactions.tsx
39.66 (-2.16)
27.78 (-2.22)
11.76 (0)
40 (-1.67)

:red_circle:
app/client/src/pages/Editor/ToggleModeButton.tsx
70.27 (-1.95)
35.71 (-11.17)
38.46 (-5.02)
68.32 (-2.09)

/ok-to-test sha=d2bc76f


Do not provide the test-helper feature

"test-helper.el" isn't a library intended to be loaded with require.
Instead it is loaded with load by ert-runner itself.  Because of
that, it is confusing to provide a feature using provide.  It also
isn't possible to use require to load test-helper because that
might, depending on the order of load-path load the "test-helper.el"
of another package that used ert-runner.
This is also discussed at rejeep/ert-runner.el#38.

Friendly ping!

Plong?

Friendly ping!
Would a pull-request help? (I would prefer if you did this yourself, but if I must do it myself, then I will.)

I would still appreciate it if you could address this. But because I don't have much hope and because I do not want any reminders of it when going through my own TODO list I am closing it.