(bc) problem with 4.0 redis

PHP Redis 4.0 was released 17-03-2018 and.. we have some bc:
Warning: Declaration of Snc\RedisBundle\Client\Phpredis\Client::append() should be compatible with Redis::append($key, $value)
Proposition:

release new major version for 4.0 php redis
in current major version fix composer.json and lock to 3.1.x php redis

lock to 3.1.x php redis

That won't work as the bundle doesn't depend on phpredis, since it can also work with predis.
The true solution, which is B/C compatible, is to invoke a different client based on which version is installed.

Actually https://ocramius.github.io/ProxyManager/docs/access-interceptor-value-holder.html might do exactly what is wanted here, and it'd be both backwards and future compatible.

@snc honest and blunt question as I currently have 4 projects failing CI and going to fail to deploy soon-ish because of this issue: are you still maintaining this project?
I'm happy to join in and get stuff fixed, but not if merging the PRs is going to take months, and given the amount of open issues and PRs, and your Github activity as a whole, I'm getting the impression of an abandoned project. Fine if that is the case, but in that case we have no other choice than to fork.

@curry684 you can always force to install redis 3.1.x by pecl, buts it's a temporary solution.
However i think symfony/cache is better option. And of course more trusted ;-)

symfony/cache is a caching solution, not a Redis encapsulation. I have projects using hashmaps, pubsub, ordered lists and everything else Redis offers.
Thanks for the PECL hint, I completely overlooked that option as I didn't expect it to be possible with the stock Docker containers, but it is and it will fix some of my CI issues hehe.

@curry684 If you send a reasonable PR I'll try and get it in, I have write access here because I remember nagging @snc too once upon a time. I think he's too busy overall :)

@Seldaek cheers, I think #405 should be the quick fix. If logging is disabled the wrapper is not used, so I disabled it by default if 4.0.0+ is installed, and issued a warning if explicitly enabled.

Well it didn't break tests on my 3.1.6 install, now also fixed tests with 4.0 installed hehe.

@Seldaek Could you tag a release please? :-)

@curry684 should get a 2.1.0 out over the weekend or early next week. Feel free to require 2.1-dev  in the meantime.

Up for grabs @ https://github.com/snc/SncRedisBundle/releases/tag/2.1.0

I ran into the same issue, here is my updated Client.php for the new Redis class, hope it helps:
https://gist.github.com/yellow1912/82acee8afd9e5b83826d35a8e4ff8584

I think we can release a new minor version for this, we can create a file named Client4.php for example? I'm not sure. The developer will have to specify in the config which client to use so it won't break with the older code. The only issue is that anywhere this Class is referred to we may have to update the use path.

We can actually detect the phpredis version during container compilation and select the right wrapper there, no manual work needed.
However I'm hesitant to take on the technical debt of adopting this file, as it means we'll be fixing up stuff and have a Client4.3.5.php in the end as Redis upstream keeps adding/changing/removing parameters and functions - if the base class doesn't exactly match compilation fails. I think we really need to generate the proxy class based on RTTI for this to become future proof.

@curry684 How would that work if you have to extend the base Redis File? Or is it necessary to extend that file?

You have to extend it so we can still keep passing the \Redis instances around that all other libraries and native code expect. The only thing the wrapper does right now is time calls and log them.
So the only way to both "be" a \Redis instance and have that behavior is to extend the class, and in PHP7 that means every function signature has to exactly match the overridden function literally. So the only way to make that work is to use RTTI to inspect the current \Redis instance, and regenerate all the methods like class RedisWrapper201804111305 extends \Redis { .... }.
At least, I don't see other ways hehe. Good thing is, that's pretty well doable - the Ocramius proxy manager does almost what we need, and Symfony and Composer do comparable things in generating containers and autoloaders.

I'll reopen this btw for the discussion as right now we only have a workaround really.

I think that can work, I guess with that the nice thing is that you do not have to do anything when they update the code on phpredis. I will play around with it abit today and see what I can do.

Is there a need to generate a random class like RedisWrapper201804111305, can we just simply generate the code and write it directly to our Phpredis/Client.php

We definitely should not overwrite vendor code at runtime (in a good environment the vendor folder should even be read-only). We should generate it in %kernel.cache_dir% similar to how Doctrine generate its proxies.
The random class name isn't terribly important but we would need something like that to avoid breaking production in case someone runs apt-get upgrade php-redis as we wouldn't be recompiling the container. This is actually a tough nut to crack well as it raises the question how we detect the change anyway.

The code to generate this code should be put somewhere that isrun before any other SNCRedisBundle code, I'm thinking of putting that directly in SncRedisBundle.php?

It should be generated during container compilation, so either in a compiler pass or the extension. Haven't looked at Doctrine yet how and when they generate the proxies (process should be similar).
The SmartReference proxy almost does what we want, but not entirely as it a) requires wrapping all functions separately and b) needs you to put all available functions in the arrays, thereby still requiring you to enumerate the functions by reflection. If you're doing that anyway it's not that much more effort to generically generate all of it. Which would bring my intended solution to suggestion 2.
If you're uncomfortable about the complexity of the required code don't worry, I can make time for it but all help is of course welcome, just wouldn't want you to waste a lot of time on a solution that's not going to work.

Then I think perhaps this will work:
https://github.com/nette/php-generator
If you place it in the CompilerPass, then you need to make sure to delete the cache after doing server upgrade (and you cannot use the symfony cli command to delete I think, in this very specific situation). Another option is to use the Bundle boot method, which is always run I think.
For the file name, it may make sense to generate name that match the exact Redis version if possible, that way we can check if that file already exists and skip it.
There will be a few changes in the configuration I believe, because right now you allow specifying the class in the configs, with the file being auto-generated I wonder how that will work.

The generator is imo overkill. We're building a bundle here used in thousands of production applications that we'd all be burdening with the extra dependency, while essentially we need to generate only rather simple straightforward code we can also do with some nowdocs.
I've looked into how Doctrine does all this yesterday and it matches up with what I was planning, also it interferes with some other running issues about detecting Redis failure and improving the logging process (I want to make that event based so it's future proof). I think the total change is going to be rather big if taking all that into account.

In that case, perhaps it may make sense to deploy a hotfix to make it work with the current version and 4.0 version version instead? I imagine that the change you are talking about will need time for consideration and tests?
I have a working version of the Client.php that works fine with 4.0, perhaps we can push in there in the bundle as something like Client4.php for people who need it while waiting for a proper, official fix.

This is a workaround to fix it:
In your config.yml:
snc_redis:
    clients:
        default:
            logging: false

@idetia that's actually the "fix" we released in 2.1.0, we default that setting to false if running with phpredis 4.0+. So you should just run composer update snc/redis-bundle.

@oerdnj thats the reason why i ask for the old package within ppa again on twitter

@dominikzogg a new version of the bundle is already available that circumvents the compatibility issues, so you can also just composer update to grab 2.1.2.

@curry684 but we sill need?
snc_redis:
    clients:
        default:
            logging: false

Nope.

@curry684 Would you mind sharing the status of this issue? I'm interested in helping to somehow solve it even if it's just a short term solution.

I'm pretty swamped in "real work" right now. Hoping to have a short holiday soon where I can actually do some work on getting that out of my head into git   😉

We are uptodate with SncRedisBundle and Predis and we're still having the error with Redis 4.x

I ran into the same issue. I run "snc/redis-bundle": "3.x-dev" but it doesn't solve the issue.

IMHO, If the extension respects BC, I think we can expect that the existing methods are not modified between minor or patch versions.
Given that premise, I think we could ship a static class by supported version, suing aliasing to keep the Client class available in a transparent way:
namespace Snc\RedisBundle\Client\Phpredis;

# Client/Phpredis/Client.php
$version = phpversion('redis');
if (version_compare($version, '4.0.0') >= 0) {
    class_alias(ClientRedis4::class, 'Client');
} elseif (version_compare($version, '3.0.0') >= 0) {
    class_alias(ClientRedis3::class, 'Client');
}

If there is some penalty for calling phpversion() and version_compare() at runtime, I think we should provide a task responsible for this in a Composer hook (post-package-install, post-package-update by instance).
I know this approach leaves out any new method that could exist in the local environment if the available Redis version is newer than the shipped by the bundle, but I think this at least a step to solve the main issue.
Regarding the concern about the extension update after the dependency resolution, I think that is out of the scope of this package: dependency resolution must be made before compiling the app in order to guarantee that everything is compatible. So, running an extension update after resolving dependencies is something that never should be contemplated by a sane environment. The same ugly scenario can explode if the PHP package itself is updated.

@phansys
We could do something like this but more simple by doing the class swap in the bundle extension.
We could support last minor version of each major version for method compatibility so that it would not be such a big deal to maintain. Only 2 classes to maintain like you proposed.
To manage that effectively phpredis minimum version could be checked by the bundle extension so that we could let user knows as soon as possible that their phpredis version is not compatible anymore with the bundle.

If there is some penalty for calling phpversion() and version_compare() at runtime, I think we should provide a task responsible for this in a Composer hook (post-package-install, post-package-update by instance).

No overhead if it's done in the bundle extension.

I know this approach leaves out any new method that could exist in the local environment if the available Redis version is newer than the shipped by the bundle, but I think this at least a step to solve the main issue.
Regarding the concern about the extension update after the dependency resolution, I think that is out of the scope of this package: dependency resolution must be made before compiling the app in order to guarantee that everything is compatible. So, running an extension update after resolving dependencies is something that never should be contemplated by a sane environment. The same ugly scenario can explode if the PHP package itself is updated.

Sadly, there is no silver bullet if we want to support multiple libraries without requiring them :/

That's fine for me. I can work on a PR based on that approach, but I don't know where can I get the Redis class for each extension version. Is there a builder or something similar which we can trust? IMO, that build process should be embedded at CI build in order to ensure the shipped version is always up to date.

Anyone is picking this up? I'm seriously considering doing something about this. We must have better support for Phpredis, the code should detect the current Phpredis and try to switch to that class.
I have several versions of PHP running across several projects and this is causing big issues.

@yellow1912 You can give it a try indeed :+1:

I don't think this issue is valid anymore. Signatures were updated in https://github.com/snc/SncRedisBundle/pull/507 so it's compatible now with newer redis versions.


Add configurable path-prefix for the server to listen on

Needed to be able to modify the path so that it would listen on mock/. Wanted to provide the change upstream

@keith-monteiro can this not already be done with --add-server and --validate-server? For example:
$ apisprout --add-server http://localhost:8080/mock --validate-server my-api.yaml

I have to say that I found this solution non-obvious; what is the purpose of the validate-server flag in this instance? Perhaps this just needs a bit more explanation in the docs.

I'm going to close this as #49 was merged and includes some extra documentation.
The --validate-server flag is required to enable the server path routing logic, otherwise it is ignored and only the OpenAPI paths are used with an assumed root of /. Would it maybe make more sense that --add-server always enables validation as well?


Send multipolygons as one joint mesh, not mesh-per-part

conflicts with boundaries/voids per polygon scheme


Update org.yaml to be added as a member of pipeline team

Seems i need to be in the pipeline members team to be able to review and approve PRs

This change is

Why do you think that? Reviewing and approving PRs should be based on OWNERs files as described in the contributing guide.

Well it has been a constant issue there. Even though OWNERS file has that listed in sub-directory its going to the top level OWNERS file.

@animeshsingh Can you give me a specific example of a PR where an approver in a sub file was not able to approve something?

Thanks - getting added to the org would be best. What do I need for that?

btw this was the last one where we had issues
https://github.com/kubeflow/pipelines/pull/915#issuecomment-470704297
and many like this. Lets start with being added to the org, and then we can take forward from there

Add yourself to the org here:
https://github.com/kubeflow/internal-acls/blob/cd7bc4997128b87f972c58f04b1cc70eb4a0d288/github-orgs/kubeflow/org.yaml#L29
Just add yourself as a member of the org not as a member of any teams.
Please insert yourself in alphabetical order.

i am already there
https://github.com/kubeflow/internal-acls/blob/b55f6fd70bfbec078bad516059fe913a68d6c757/github-orgs/kubeflow/org.yaml#L31
But I dont see myself listed when I go to
https://github.com/orgs/kubeflow/people

The permissions need to be manually sync'd.
I just sync'd them.. So check your email for an invitation from GitHub to join the org and accept it.
Closing this PR because it shouldn't be necessary.


Small adjustments to clarify behavior on on_error

Fixes DOC-2253
Clarified language for on_error=pause as there was confusion about the kind of error this would pause — that is, non-retryable errors will pause and not go to a terminal failure state. Retryable errors will still retry as this option does not apply to them.
This is a quick fix to avoid confusion for this option — a larger section on retryable & non-retryable errors will be covered in the coming weeks with DOC-1286

This change is

LGTM, a couple of very minor nits. I also double-checked with the team on "retryable" vs. "retriable" - I am pretty sure the former, which you have here, is preferred and that we should be correcting the latter. But perhaps worth waiting for more feedback on this?

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @kathancox and @taroface)

v21.2/create-changefeed.md, line 132 at r1 (raw file):

`diff` | N/A |  Publish a `before` field with each message, which includes the value of the row before the update was applied.
`compression` | `gzip` |  Compress changefeed data files written to a [cloud storage sink](#cloud-storage-sink). Currently, only [Gzip](https://www.gnu.org/software/gzip/) is supported for compression.
`on_error` | `pause` / `fail` | New in v21.2: Use `on_error=pause` to pause the changefeed when encountering **non**-retryable errors — for example, when a changefeed cannot connect to a downstream sink for an extended period of time. `on_error=pause` will pause the changefeed instead of sending it into a terminal failure state. **Note** that retryable errors will continue to be retried with this option specified.

Use with [`protect_data_from_gc_on_pause`](#protect-pause) to protect changes from [garbage collection](configure-replication-zones.html#gc-ttlseconds).

Default: `on_error=fail`

Very small nit, but if this is an em dash I think there shouldn't be spaces around it.
Code quote:
 —

v21.2/create-changefeed.md, line 132 at r1 (raw file):

`diff` | N/A |  Publish a `before` field with each message, which includes the value of the row before the update was applied.
`compression` | `gzip` |  Compress changefeed data files written to a [cloud storage sink](#cloud-storage-sink). Currently, only [Gzip](https://www.gnu.org/software/gzip/) is supported for compression.
`on_error` | `pause` / `fail` | New in v21.2: Use `on_error=pause` to pause the changefeed when encountering **non**-retryable errors — for example, when a changefeed cannot connect to a downstream sink for an extended period of time. `on_error=pause` will pause the changefeed instead of sending it into a terminal failure state. **Note** that retryable errors will continue to be retried with this option specified.

Use with [`protect_data_from_gc_on_pause`](#protect-pause) to protect changes from [garbage collection](configure-replication-zones.html#gc-ttlseconds).

Default: `on_error=fail`

Suggest **Note: Retryable per our typical usage
Code quote:
**Note** that

Fixed both! Thanks for the review @taroface


fix(cache): Add cache warmup for non-legacy charts

SUMMARY
This PR is a rehash of https://github.com/apache/superset/pull/23012 which was later reverted by https://github.com/apache/superset/pull/23579 in combination with https://github.com/apache/superset/pull/23569.
The logic defined here is the inverse of https://github.com/apache/superset/pull/23012, i.e., rather than trying to identify if a chart is a non-legacy chart (via the presence of the query-context—which was problematic), instead we check if the chart is a supported legacy chart/viz type.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF

TESTING INSTRUCTIONS
Added unit tests.
ADDITIONAL INFORMATION

[ ] Has associated issue:
[ ] Required feature flags:
[ ] Changes UI
[ ] Includes DB Migration (follow approval process in SIP-59)

[ ] Migration is atomic, supports rollback & is backwards-compatible
[ ] Confirm DB migration upgrade and downgrade tested
[ ] Runtime estimates and downtime expectations provided

[ ] Introduces new feature or API
[ ] Removes existing feature or API

cc: @alexryndin @dheeraj-jaiswal-lowes

@michael-s-molina this PR is now ready for re-review.

@john-bodley Thank you so much. This one is very helpful!

Hi @john-bodley, we have found something funny. We noticed that some charts have been cached by cache warmup job, which is good. But if we click the dashboard, it seems those charts in the dashboard are not using the warmup cache. Do you have any idea? Thank you.

Hi @stepcheunghk , Are there any native filters or other filters applied to the chart as part of dashboard?

Hi @dheeraj281 , you are right. Definitely there are some filters applied to the chart/ dashboard. What should I do now? Thanks man.

@stepcheunghk Yes, thats the reason.. It refreshes the chart objects related to the dashboard. When native filter is applied on the dashboard, its a different query now that is why. If you dont keep any filter with default, it should work as expected.

@dheeraj281 I see. Thanks for your prompt reply and clear explanation. 🙂

Hi @dheeraj281 @stepcheunghk
if I have a dashboard with a native filter with a default value and also in it, I have charts with filters inside (with clauses where/having), how should I do cache_warmup so it would refresh my dashboard with default values and all charts inside it with their own filters?

Hi @oriabyi I am not aware of any such functionality right now. As discussed above It refreshes the chart objects related to the dashboard. it basically loads the chart url with force=true. One way of refreshing dashboard could be a separate selenium script that loads the dashboard url with url param "force=true"
Even we had this requirement of refreshing a dashboard with a native filter with a default value and also in it. To handle that in superset for our internal use, I have changed the cache-refresh functionality to work from the backend instead of using selenium and  chart url approach. In backend it will identify charts and all the associated dashboard level filters of it and runs the exact same query which is their at dashboard level using chartDataCommand. If many users wants this, I can create a PR for the same.
cc: @rusackas @villebro

@dheeraj281, thank you, it helped a lot, truly appreciate it.


Add 'storeClone' option to buildMemoryStorage function

See issue 580 for more details

Looks like there is some issue with the CI

The CI failed because of linting, please run pnpm lint -- --fix and pnpm format before push to lint your code.

I added a review to update the cloneData property instead of creating a new one. Overall, suuper thanks for your time in this PR :)

Thanks for your review. This is the first time writing typescript code. As yo ucan expect, my local configuration is not exactly mature right now :sweat_smile:
I updated the test, but I'm not sure if this is enough, please let me know what you think.
About storeClone:
I removed it. It was an attempt to be a bit more explicit, as I find 'double' on cloneData less explicit. In the other hand, 'double' on cloneData limit amount of parameters and allow us to use the new option without adding cleanupInterval and maxEntries to false every time.
You decide what's best for this library and adding 'double' to cloneData seems like a fine typescript way of adding functionnality.
Another note about this whole clone thing. I really think that the double options should be the default value. I would argue that anyone trying this library for the first time might have a hard time understanding why their axios.get calls doesnt returns the same data every time. And suddenly having to check for cached property or having to provide additionnal configuration might block some users from using the library altogether.

Instead of double I suggested all.
But it would be more explicit and also more configurable to use an enum.
Perhaps something like:

onSet
onGet

Where the user can specify one, both or none of the options (so an array of string maybe ?).
I think this aproach is the best, it wont break compatibility if you want to add clone to another method.
Let the user specify: ['onSet', 'onGet']
I dont know how one would neatly implement this in typescript tho.

Thanks!


The extension is reading the style.csv file with incorrect delimiters, the first delimiter is not the name but the number instead?

The extension is reading the style.csv file with incorrect delimiters, the first delimiter is not the name but the number instead?

What's the actual problem here?
The extension adds a column on the left for sorting, but your positive and negative prompts are all in the right place?

positive and negative prompts are all in the right place,can be filled in correctly,But the extension does not read correctly,

So if I use this extension to edit, it will save with incorrect delimiters?

This is the original format delimiter.

Could you post the styles file here so I can test it please.

styles.csv

OK, that style file has some weird lines in it (lines 2 and 6 have extra commas in them).
I've made the extension more robust in the latest commit, should work now.


Upgrade go-kit to v0.9.0

This PR removes the replace directive that replaces go-kit v0.9.0 with v0.3.0 and updates the use of the github.com/go-kit/kit/log package to be compatible with the APIs supported by v0.4.0 and beyond.
What this PR does / why we need it:
The v0.3.0 APIs in github.com/go-kit/kit/log are incompatible with those in v0.4.0 and beyond. This makes it impossible to import packages like kubevirt.io/client-go/kubecli into other projects where other dependencies rely on newer versions of go-kit (go mod will pick the higher version and this results in compilation errors in kubevirt.io/client-go/log due to conflicting APIs).
Which issue(s) this PR fixes
NONE
Special notes for your reviewer:
NONE
Release note:
Removed go module pinning to an old version (v0.3.0) of github.com/go-kit/kit

Hi @zcahana. Updated the release notes. To add a little more detail, the go-kit module seems to have changed the API of the log package in an incompatible way between minor versions (v0.3.0 and v0.4.0). Notably, they've removed the log.Context type entirely and instead context is added to a structured logger instance using top-level package functions (log.With, log.WithPrefix):
v0.3.0
logger := log.NewContext(log.NewJSONLogger(log.NewSyncWriter(os.Stdout))).With("abc", "123")

v0.4.0
logger := log.With(log.NewJSONLogger(log.NewSyncWriter(os.Stdout)), "abc", "123")

The way kubevirt uses the package right now is compatible with v0.3.0. In my PR I update the places that use the log package to be compatible with v0.4.0 and higher. If my module requires (either directly or indirectly) both kubevirt.io/client-go/log and some other module that requires github.com/go-kit/kit/log at a higher version, say v0.10.0, it leads to a compilation error. Because of the way go selects a module version

MVS starts at the main module (a special vertex in the graph that has no version) and traverses the graph, tracking the highest required version of each module. At the end of the traversal, the highest required versions comprise the build list: they are the minimum versions that satisfy all requirements.

it would try to build everything with the highest minor version of go-kit (v0.10.0) which doesn't work if kubevirt.io/client-go/log is built around the v0.3.0 API. The root of the problem here is that go-kit doesn't correctly use semantic versioning. In the strictest sence, v0.3.0 and v0.10.0 should have compatible APIs, but alas, they do not.

If I get this correctly, other consumers, who may have too explicitly pinned to github.com/go-kit/kit v0.3.0 for compatibility with kubevirt, will continue to use v0.3.0 for their builds (as long as they don't remove their replace directives). Is the way kubevirt.io/client-go now uses go-kit's logger compatible with v0.3.0? I think it is but just want to make sure.

Because of the breaking change between minor versions code can be compatible with either v0.3.0 and below or v0.4.0 and above. With the change in my PR consumers who depend on both github.com/go-kit/kit/log at v0.3.0 or below and kubevirt.io/client-go/log would need to update their version of github.com/go-kit/kit/log to a newer version and update the use of that package in their code to prevent compilation errors.

Thanks for this detailed explanation @jrife!

Because of the breaking change between minor versions code can be compatible with either v0.3.0 and below or v0.4.0 and above. With the change in my PR consumers who depend on both github.com/go-kit/kit/log at v0.3.0 or below and kubevirt.io/client-go/log would need to update their version of github.com/go-kit/kit/log to a newer version and update the use of that package in their code to prevent compilation errors.

I still didn't manage to completely figure out whether the change introduced by this PR can be a breaking change to some consumers, and particularly to those who are relying on go-kit v0.3.0 (i.e., they have a similar replace directive in their go.mod).
If I understand it correctly (I'm not sure I do :smile:), as long as they have that replace directive, they'll continue to use 0.3.0 (as replace directives are honored for the "main" module only, and can force the build to use a version lower than the one required by a dependency (such as kubevirt.io/client-go)). If that's correct (is it?), the our (new) usage of go-kit/log will still be compiled with go-kit v0.3.0. And if that's correct too (is it?), this will compile just fine as the v0.4.0+ API is compatible with v0.3.0 too.

I still didn't manage to completely figure out whether the change introduced by this PR can be a breaking change to some consumers, and particularly to those who are relying on go-kit v0.3.0 (i.e., they have a similar replace directive in their go.mod).

This can be a breaking change for consumers whose module imports github.com/go-kit/kit/log at v0.3.0 or below directly or whose module imports another module that includes github.com/go-kit/kit/log at v0.3.0 or below in its dependency graph:
Scenario 1
my-module imports github.com/go-kit/kit/log in one of its own packages and consumes the API, expecting the behavior supported in v0.3.0 (e.g. log.NewContext).
my-module
|
|--github.com/go-kit/kit @ `v0.3.0`
|--kubevirt.io/client-go

In this case upgrading to a version of kubevirt.io/client-go that includes the change in this PR would require the consumer to update their own use of the github.com/go-kit/kit/log package to be compatible with the newer APIs. There is no single version of go-kit/kit that satisfies the requirements of code expecting the API from versions <= v0.3.0 and of code expecting the API from versions > v0.3.0.
Scenario 2
my-module imports some other module that in turn imports github.com/go-kit/kit/log in one of its own packages and consumes the API, expecting the behavior supported in v0.3.0 (e.g. log.NewContext).
my-module
|
|--github.com/some/other/module @ someversion
|  |--github.com/go-kit/kit @ `v0.3.0`
|--kubevirt.io/client-go

In this case there is no easy way to resolve this conflict for the maintainer of my-module. They would either have to update the version they use of github.com/some/other/module to a version that hopefully uses github.com/go-kit/kit at a higher version, work with the maintainer of github.com/some/other/module to upgrade the version, or avoid the use of github.com/some/other/module altogether.

If I understand it correctly (I'm not sure I do 😄), as long as they have that replace directive, they'll continue to use 0.3.0 (as replace directives are honored for the "main" module only, and can force the build to use a version lower than the one required by a dependency (such as kubevirt.io/client-go)). If that's correct (is it?), the our (new) usage of go-kit/log will still be compiled with go-kit v0.3.0. And if that's correct too (is it?), this will compile just fine as the v0.4.0+ API is compatible with v0.3.0 too.

The v0.4.0+ API of github.com/go-kit/kit/log is incompatible with v0.3.0 and below. The problem isn't so much the version of the module you choose it's that there is no single version of github.com/go-kit/kit/log that satisfies the requirements of code expecting the old-style APIs and new-style APIs (i.e. a replace directive doesn't help to resolve these conflicts). My original problem (the reason I submitted the PR) basically looks like this:
My Scenario
my-module
|
|--kubevirt.io/client-go @ v0.43.0 <-- Code in `kubevirt.io/client-go/log` expects `v0.3.0` APIs.
|--github.com/some/other/module
|  |--github.com/go-kit/kit @ v0.10.0

my-module imports kubevirt.io/client-go/kubecli which in turn imports kubevirt.io/client-go/log which is written around the v0.3.0 APIs of github.com/go-kit/kit/log. It won't compile because the dependency resolution selects v0.10.0 as the go-kit version to use which is incompatible with what kubevirt.io/client-go/log expects. If I add a replace directive to my go.mod file to force go to build using v0.3.0 this just moves the compilation problem to github.com/some/other/module because it expects the newer APIs.
There's no perfect solution here (someone somewhere will always have a compilation error), but my logic behind submitting this PR is that v0.3.0 is quite old and moving forward it's probably more likely for other modules to be using versions > v0.3.0 than <= v0.3.0. It's probably better to be compatible with the newer versions going forward. Let me know if you agree with the reasoning here, or if you see a better way.

I tried today again to untangle all this a little and just export our golang types and a plane generated client, but failed again. Some of our dependencies pull in a lot of other dependencies. :/
We need to find a general solution for this. No one deserves this kind of dependency hell.
I think we should  settle on a model where all our go types consist of easy to resolve dependencies where one can generate a client with client-gen and just override the few existing kubernetes.io dependencies with the version used in the external projects main go.mod.
I could come up pretty easily with changes to generate a stripped down generated client for kubevirt, but the CDI dependencies have openshift.io dependencies which makes it a mess again ...
@mhenriks maybe we can discuss this.

@rmohr @zcahana I'm not sure what more general solution you have in mind, but one idea I had to solve the problem with this particular dependency is to replace github.com/go-kit/kit/log with a different structured logger like zap. The root problem in this case is that github.com/go-kit/kit/log doesn't really follow semantic versioning properly (v0.4.0+ should be backwards compatible with v0.3.0). If, for example, go.uber.org/zap was used instead, which I think maintains backwards compatibility through all it's minor versions (v1.0.0 -> v1.19.1), then it would eliminate version conflicts in this package in future releases of kubevirt.io/client-go.  I could submit a PR for this if the Kubevirt team is OK with the idea.

@rmohr @zcahana I'm not sure what more general solution you have in mind, but one idea I had to solve the problem with this particular dependency is to replace github.com/go-kit/kit/log with a different structured logger like zap. The root problem in this case is that github.com/go-kit/kit/log doesn't really follow semantic versioning properly (v0.4.0+ should be backwards compatible with v0.3.0). If, for example, go.uber.org/zap was used instead, which I think maintains backwards compatibility through all it's minor versions (v1.0.0 -> v1.19.1), then it would eliminate version conflicts in this package in future releases of kubevirt.io/client-go.  I could submit a PR for this if the Kubevirt team is OK with the idea.

I would really not mind getting rid or go-kit/kit/log but I would prefer if we end up with the same structured logger which k8s is converging to.
In general regarding to fixing the dependency issues, we just discussed this in todays community meeting. @mhenriks and I roughly favoured there a model where we would expose our api structs in separate repos so that one can just use client-gen to generate clients and would only have to adjust one or to k8s versions in go.mod.

I would really not mind getting rid or go-kit/kit/log but I would prefer if we end up with the same structured logger which k8s is converging to.

This would solve my immediate problem with the go-kit/kit/log dependency, and like I said I'd be happy to make the change. What structured logger is k8s converging to? Any links or discussions about this?

In general regarding to fixing the dependency issues, we just discussed this in todays community meeting. @mhenriks and I roughly favoured there a model where we would expose our api structs in separate repos so that one can just use client-gen to generate clients and would only have to adjust one or to k8s versions in go.mod.

This sounds reasonable. If I understand correctly under this model the kubevirt project would only export the structs themselves (e.g. like those in clieng-go/api/types.go) and consumers could generate thick clients themselves with client-gen using whatever k8s version is suitable thus eliminating a lot of the dependencies currently carried by client-go?

This would solve my immediate problem with the go-kit/kit/log dependency, and like I said I'd be happy to make the change. What structured logger is k8s converging to? Any links or discussions about this?

Would be great if you make the switch.
The good new is that it is already in our codebase. The import would be k8s.io/klog/v2. A few hints:

https://kubernetes.io/docs/concepts/cluster-administration/system-logs/
https://github.com/kubernetes/klog

Note that our logger already co-exists with glog and klog/v1 and we are collecting all the logs from glog and klog/v1 and transform that in our structured logging format. I am not sure how much work it is to continue doing that with klog/v2.

This sounds reasonable. If I understand correctly under this model the kubevirt project would only export the structs themselves (e.g. like those in clieng-go/api/types.go) and consumers could generate thick clients themselves with client-gen using whatever k8s version is suitable thus eliminating a lot of the dependencies currently carried by client-go?

Yes exactly. The best example is https://github.com/kubernetes/api. We would need one repo like this from cdi which brings its own dependencies which are hard to resolve and here we would do the same things to eliminate our dependencies. At the end we would have a repo which would almost exclusively depend on 2 or 3 core kubernetes dependencies where you just override the version with your projects version.


Supported arch(s)?

The Makefile is hardcoded to use amd64. What are the chances this could be built for arm?

It works for ARM.  make GOOS=linux GOARCH=arm should give you arm binaries.
bin/sctl: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

If demand is enough we could also add an ARM package to the releases.

Awesome, thanks!

Thanks for bringing this up.  I'm going to add a note in the README about different archs and look into autobuilding for releases.

I'd be interested in pre-compiled binaries and possibly contributing to that. Are you building your released manually right now, I don't see them in your travis config?

Awesome!  I've been working on Actions to automatically build and push to S3 as part of the regular releases.  I'll add an ARM target.
What would be awesome is feedback on how Stellar works on ARM and if there are any issues from the cross-compiled binaries.  If so, we might have to shift away from Actions.
Thanks!

I'll give it a test drive sometime over the next week and let you know if I run into any snags.

FYI, I hit a snag getting containerd on arm. Once I finish shaving that yak I can get started with stellar.

I was thinking about making ARM containerd builds available.  I can do that
if you think it will be useful :)
On Wed, Feb 27, 2019 at 6:01 PM Ben Woodward<EMAIL_ADDRESS>wrote:

FYI, I hit a snag https://github.com/containerd/containerd/issues/2901
getting containerd on arm. Once I finish shaving that yak I can get started
with stellar.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ehazlett/stellar/issues/27#issuecomment-468065937,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAP6IkPfW9yYxoASs_u3hAAIOPARa3a8ks5vRw5bgaJpZM4a56Ss
.

ARM containerd builds would be very useful. If you decide to do that, please also provide the Makefile/script so folks can run those builds themselves. Should that live in this repository or be upstreamed to containerd itself?
IMO the biggest hurdle I see is the lack of basic documentation for building containerd for ARM. Reducing that friction would help stellar users since it's a prereq.

It's actually super simple if you have an ARM device :)  Just make.  Cross compiling however is much worse :)
I'll work to get CI building these but for now here is the latest master for armhf: https://s3.us-east-2.amazonaws.com/stellar-release/containerd/armhf/containerd-linux-armhf-e72ad44427f623a53c2d38c46598753d5e6fd63b.tar.gz


Enhancement: Portainer compatible docker-compose

Contact Details
<EMAIL_ADDRESS>What features would you like to see added?
The ability to easily deploy and manage an instance through portainer
More details
The use of the env file hard coded into the software causes the deployment to fail. Portainer has the ability to import .env files and then render them during deployment. This can be done by substituting "env_file: .env" with "env_file: stack.env". Unfortunately the .env file is also used as a volume and i don't believe there is a way to do that kind of substitution in portainer.
It also seems like many of the docker-compose volumes are not included in the image itself and thus the entire repo needs to be downloaded in order for the application to run
Which components are impacted by your request?
General
Pictures
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

env file hard coded into the software

are you referring to the dockerfile? is it possible for you to comment out touch .env && \ and see if it impacts your use case?
Have you seen this guide? I know podman is not equal to portainer but maybe there's some lucidation in this guide (I use neither)

https://docs.librechat.ai/install/container_install.html

It also seems like many of the docker-compose volumes are not included in the image itself and thus the entire repo needs to be downloaded in order for the application to run

this is true. I'll gladly take any suggestions and help to writing a new dockerfile that does this.

you should also see if you encounter any of these issues with this image: https://github.com/users/danny-avila/packages/container/package/librechat-dev-api which uses the alternate deploy-compose.yml

I just checked your dockerfile and it already does "COPY . /app" which means the volumes SHOULD be ubiquitous, though i haven't tested this theory yet. I will try your suggestion on the alternate deploy-compose and potentially submit a PR for a Dockerfile/compose adjustment if necessary

The repo is actually not necessary at all, nor is the .env file. You can just put everything in the compose file itself. Secrets can go into the Portainer env and be referenced in the Compose file.

I think the recent update in #1415 closes this

I'll drop my portainer compose file here since it might be useful for some:
version: "3.8"
services:
  api:
    image: ghcr.io/danny-avila/librechat-dev:latest
    container_name: LibreChat
    ports:
      - 3080:3080
    restart: always
    env_file:
      - stack.env
    volumes:
      - /LibreChat/images:/app/client/public/images
  meilisearch:
    container_name: Meilisearch
    image: getmeili/meilisearch:v1.5.1
    restart: always
    env_file:
      - stack.env
    volumes:
      - /LibreChat/meili_data_v1.5:/meili_data

I used an online database (see: online db )
All variables are in the portainer env. I imported the .env.example and customized it (I updated the MONGO_URI with my online db)

Thanks @fuegovic , I have success with this portainer compose file below with mongodb in docker (using v4 as my cpu does not support avx) , copied paste most .env.example variables into the advance mode for Environment variables field.
# https://github.com/danny-avila/LibreChat/issues/1272
# review .env at https://github.com/danny-avila/LibreChat/blob/main/.env.example
version: "3.8"
services:
  api:
    image: librechat/librechat-dev:latest
    container_name: LibreChat
    ports:
      - 3080:3080
    restart: always
    env_file:
      - stack.env
    environment:
      - HOST=<IP_ADDRESS>
      - NODE_ENV=production
      - MONGO_URI=mongodb://mongodb:27017/LibreChat
      - MEILI_HOST=http://meilisearch:7700
   # https://hub.docker.com/u/librechat - uses single image from DockerFile
    volumes:
      - /LibreChat/images:/app/client/public/images
  meilisearch:
    container_name: chat-meilisearch
    image: getmeili/meilisearch:v1.5.1
    restart: always
    env_file:
      - stack.env
    environment:
      - MEILI_HOST=http://meilisearch:7700
      - MEILI_NO_ANALYTICS=true
    volumes:
      - /LibreChat/meili_data_v1.5:/meili_data
  mongodb:
    container_name: chat-mongodb
    # ports:  # Uncomment this to access mongodb from outside docker, not safe in deployment
    #   - 27018:27017
    # Modify to mongo:4.4.18 for missing AVX CPU
    image: mongo:4.4.18
    restart: always
    volumes:
      - /LibreChat/data-node:/data/db
    command: mongod --noauth

I was able to successfully deploy in portainer as per @jereloh - but how can I customize librechat.yml within portainer? Doesnt seem portainer supports the docker-compose.overide.yml
Any suggestions?

@kempec110
I personally use a remote yaml file I host on github
You can look at my repo for examples and instructions: https://github.com/fuegovic/lc-config-yaml

Thanks @fuegovic , I have success with this portainer compose file below with mongodb in docker (using v4 as my cpu does not support avx) , copied paste most .env.example variables into the advance mode for Environment variables field.
# review .env at https://github.com/danny-avila/LibreChat/blob/main/.env.example
version: "3.8"
services:
  api:
    image: librechat/librechat-dev:latest
    container_name: LibreChat
    ports:
      - 3080:3080
    restart: always
    env_file:
      - stack.env
    environment:
      - HOST=<IP_ADDRESS>
      - NODE_ENV=production
      - MONGO_URI=mongodb://mongodb:27017/LibreChat
      - MEILI_HOST=http://meilisearch:7700
   # https://hub.docker.com/u/librechat - uses single image from DockerFile
    volumes:
      - /LibreChat/images:/app/client/public/images
  meilisearch:
    container_name: chat-meilisearch
    image: getmeili/meilisearch:v1.5.1
    restart: always
    env_file:
      - stack.env
    environment:
      - MEILI_HOST=http://meilisearch:7700
      - MEILI_NO_ANALYTICS=true
    volumes:
      - /LibreChat/meili_data_v1.5:/meili_data
  mongodb:
    container_name: chat-mongodb
    # ports:  # Uncomment this to access mongodb from outside docker, not safe in deployment
    #   - 27018:27017
    # Modify to mongo:4.4.18 for missing AVX CPU
    image: mongo:4.4.18
    restart: always
    volumes:
      - /LibreChat/data-node:/data/db
    command: mongod --noauth

Just want to update a new config that i used with portainer with the latest 0.7.2 librechat so that i can use chatgpt-4o :)
# This file is modified from https://github.com/danny-avila/LibreChat/blob/main/docker-compose.yml
# Rename .env to stack.env and review https://github.com/danny-avila/LibreChat/blob/main/stack.env.example
# Remove cloudflare if not required

version: "3.8"
services:
  api:
    container_name: LibreChat
    ports:
      - "${PORT}:${PORT}"
    depends_on:
      - mongodb
      - rag_api
    image: ghcr.io/danny-avila/librechat-dev:latest
    restart: always
    user: "${UID}:${GID}"
    extra_hosts:
      - "host.docker.internal:host-gateway"
    environment:
      - HOST=<IP_ADDRESS>
      - MONGO_URI=mongodb://mongodb:27017/LibreChat
      - MEILI_HOST=http://meilisearch:7700
      - RAG_PORT=${RAG_PORT:-8000}
      - RAG_API_URL=http://rag_api:${RAG_PORT:-8000}
    env_file:
      - stack.env
    volumes:
      # - type: bind
      #   source: .env
      #   target: /app/.env
      - ./images:/app/client/public/images
      - ./logs:/app/api/logs
  mongodb:
    container_name: chat-mongodb
     # Modify to mongo:4.4.X for compatiblity with missing AVX CPU
    image: mongo:4.4.29
    restart: always
    user: "${UID}:${GID}"
    volumes:
      - ./data-node:/data/db
    command: mongod --noauth
  meilisearch:
    container_name: chat-meilisearch
    image: getmeili/meilisearch:v1.7.3
    restart: always
    user: "${UID}:${GID}"
    environment:
      - MEILI_HOST=http://meilisearch:7700
      - MEILI_NO_ANALYTICS=true
    volumes:
      - ./meili_data_v1.7:/meili_data
  vectordb:
    container_name: vectordb
    image: ankane/pgvector:latest
    environment:
      POSTGRES_DB: mydatabase
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
    restart: always
    volumes:
      - pgdata2:/var/lib/postgresql/data
  rag_api:
    container_name: rag_api
    image: ghcr.io/danny-avila/librechat-rag-api-dev-lite:latest
    environment:
      - DB_HOST=vectordb
      - RAG_PORT=${RAG_PORT:-8000}
    restart: always
    depends_on:
      - vectordb
    env_file:
      - stack.env

  # Cloudflared if required
  cloudflared:
    image: wisdomsky/cloudflared-web:latest
    restart: unless-stopped
    network_mode: host
    environment:
      WEBUI_PORT: 1001

volumes:
  pgdata2:


Require prettier ^1.1.0

Let's upgrade to the stable release and get the ball rolling 💪

✨ Awesome


feat(h1): allow ignoring invalid header lines in requests

This just needs an update to httparse, yea?

@seanmonstar Done.


Aligner Configuration

Let the User select the Alignment Algorithm, algorithm-specific configurations, etc...

Mostly resolved by 6c3128f0f27b94d12045b982b594afb8a8ae0910. Closing for now.


Amazon MFA in --headless broken

Amazon MFA (2SV) in --headless mode doesn't work.
If I didn't have a 👶 due in the next few days, I'd write up a PR for a "semi-headless" mode which would prompt for an OTP. Checking "Don't require OTP on this browser" with chromedriver would be cool too, but keeping that persistent is probably challenging.

There is no MFA logic for the amazon login flow at the moment. If you have a MFA challenge, you need to complete it yourself in the browser (which as you point out won't work well if you're running --headless).
I'll rename the FR. Thanks for the report and congrats on the new baby!

There is no MFA logic for the amazon login flow at the moment. If you have a MFA challenge, you need to complete it yourself in the browser (which as you point out won't work well if you're running --headless).
I'll rename the FR. Thanks for the report and congrats on the new baby!


Update the MethodJitTailCallFailed event ID

This change maps the event to the ID in https://github.com/dotnet/coreclr/blob/2a8529c6130f6c70488e8bace26404b319eed00f/src/vm/ClrEtwAll.man#L3175
The current ID maps the MethodJitInliningFailed event ID, which is wrong.

/cc @noahfalk @brianrob


Using vizlab templates for footer/header

So the template seems to work, but would also need a little love from @mwernimont to push out. It doesn't look like the normal fonts, and maybe a little small.

I'm never very sure when it comes to viz.yaml, to me it all looks good, but probably a good idea to have  the yaml man @jiwalker-usgs give it a look.


GoogleTranslator Not working for Indian Languages

deep_translator version: 1.3.2
Python version: 3.7
Operating System: win10

Description
Translation to English not working for Indian language text transliterated in English
What I Did
GoogleTranslator(source='hindi', target='en').translate(text="ghar jaana hai")

is returning ghar jaana hai. Whereas the googletranslate website is returning proper translation want to go home here

I've been having the same issue with English to Dutch and fixed it by changing the target language url argument used to call Google Translate.
I modified this line: https://github.com/nidhaloff/deep-translator/blob/b9e395baef7ef62820a8383bf66f4404e5fcdb99/deep_translator/google_trans.py#L38
I made it tl=self._target, instead and now it works properly. Maybe you can give it a try.

@vinod1234567890 Sorry for the late reply, I'm very busy in the last days. You are right this appears to be an issue only when using the Indian language! at least until now. I will check it out asap.
@morpheus65535 many thanks for pointing out your issue with the dutch language and how you fixed it. I'm wondering why you didn't make a pull request? anyone your comment here helped me to fix the issue for the dutch language. I would like to give you credits for it but I wasn't sure since you didn't open an issue or made a pull request. Anyway thanks

@nidhaloff TBH I was waiting on feedback from you. I've just created PR #36 waiting for your review.

@morpheus65535 I don't know why you waited for my feedback. If you faced this issue with the dutch language, you should've opened a separate issue in the first place, because this issue is about another topic, so I can't see why you waited for my feedback here!
After reading your comment a couple of days ago, I went and fixed this issue that's why I can't accept your PR now sorry

I guess there is not much you can do about it with the current setup and here is why.

Whereas the googletranslate website is returning proper translation want to go home here

Thats true, but only for the desktop version.

deep-translator currently fetches the mobile site of google translator and there it is not translating this phrase as well

@florianbussmann yes you are right. I think we can do nothing about this issue at least for now


Wallet address displayed in lowercase

Describe the Bug
Wallet addresses appear in lowercase (that is, a combination of numbers and only lowercase letters)
To Reproduce
Open any profile and see the address (under the full name) is in lowercase
Expected Behavior
Wallet addresses should display with the correct casing, to prevent issues when checking it against the submitted picture and video
Screenshots

Device and Browser Information
Google Chrome v95 on Windows 10, Google Chrome v95 on Android 11

Upper or lower case doesn't affect Ethereum Addresses. I don't see the point on changing this.

I was thinking it makes it easier to read and compare it to, say, the address displayed on the submissions.
After posting this issue I went into the code and saw that this is the way the addresses are fetched from the API so maybe it's not that simple to change

@ivanlewin I think what you are proposing is to encourage new profiles to use the lower-case variant of their ETH address when they record their video, is that correct?


Difficulty updating to Spyder 4.0.0rc1

I installed Anaconda 3 (with Spyder 3.3.6), and I wanted to upgrade to Spyder 4.0.0rc1, so I ran
conda update qt pyqt
conda install -c spyder-ide spyder=4.0.0rc1

But dependency solving took a long time finally conda told me the conflict was too much.
So I used conda uninstall spyder to try to uninstall 3.3.6, but it turned out that lots of the packages (such as numpy, matplotlib, etc) got uninstalled together.
Is there an easier way to upgrade to Spyder 4?

Is there an easier way to upgrade to Spyder 4?

Yes, please create a new conda env for it instead of trying to install it in the base env or a previous env you have.


[Bug Report] When use that has submenu, I set default-active property, then the hasn't menu been active I menu

Element UI version
1.3.1
OS/Browsers version
windows 7 / chrome 56.0.2924.87 / firefox 47.0.2
Vue version
2.3.2
Reproduction Link
https://jsfiddle.net/martinko2009/ee6uu6y2/
Steps to reproduce
When I set activeIndex to 1，the menu item is active and looks different with others.
When I set activeIndex to 2， the menu item which has submenu is not active and look same as others.
当我设置activeIndex为1的时候，这个菜单选项“处理中心”看上去是蓝色的，是激活状态。
但是当我设置activeIndex为2的时候，菜单项“我的工作台”看上去还是白色的字，没有处于激活状态。
What is Expected?
I want to make the first class menu item which has submenu look different by setting default-active.
我想将default-active的值，设置为一个一级菜单（包含子菜单）的key值时，这个一级菜单在样式上可以和其他的一级菜单不一样，是处于激活状态的。
What is actually happening?
I set default-active to the key of the first class menu item which has submenu, but it doesn't look different, not active .
当我将default-active的值设置为一个一级菜单（包含子菜单）的key值时，这个一级菜单样式上看上去没有变化，感觉没有被激活，用户不知道，这个是当前的菜单项。

Did you solve the problem?

no，I didn't solve the problem.

Currently, submenu can only be activated when its option get selected. When activated, the font color of submenu is white, but with a blue active bar, and font color of the selected option will be  blue.
So all you need is to activate the option in submenu.
You can set activeIndex2: '2-1', and it will work. Does this solve your problem?
    data() {
      return {
        activeIndex: '1',
        activeIndex2: '2-1'
      };
    },

but I just want to active firstclass menu, not the submenu.

but I just want to active firstclass menu, not the submenu.

There's no way to do this for now.


Support quering with complex conditions

Currently ObjectManager supports methods getOneById and getListBy that retrieve data based on one field. A method that supports multiple conditions is required. The method syntax will be based on the where conditions used in express-cassandra.

This has been resolved by using express-cassandra and the .findOne and .find methods with filters passed as parameter. Analogous changes have been made for in-memory implementation.


chore: try to improve boxes caching

Benchmark results
No metrics with a significant change found.

Detailed results
All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call  to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.
This benchmark source data is available in JSON format on S3 here.
Proof generation
Each column represents the number of threads used in proof generation.

Metric
1 threads
4 threads
16 threads
32 threads
64 threads

proof_construction_time_sha256
5,705 (-2%)
1,548 (-1%)
710
745 (-3%)
778

L2 block published to L1
Each column represents the number of txs on an L2 block published to L1.

Metric
8 txs
32 txs
64 txs

l1_rollup_calldata_size_in_bytes
1,412
1,412
1,412

l1_rollup_calldata_gas
9,464
9,452
9,476

l1_rollup_execution_gas
616,105
616,093
616,117

l2_block_processing_time_in_ms
1,357 (-3%)
5,081 (-3%)
10,128 (-2%)

l2_block_building_time_in_ms
47,003 (-2%)
185,343 (-2%)
370,674 (-3%)

l2_block_rollup_simulation_time_in_ms
46,824 (-2%)
184,709 (-2%)
369,420 (-3%)

l2_block_public_tx_process_time_in_ms
25,765 (-2%)
104,082 (-5%)
212,790 (-3%)

L2 chain processing
Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric
3 blocks
5 blocks

node_history_sync_time_in_ms
10,010 (+1%)
15,300 (+1%)

node_database_size_in_bytes
14,499,920
21,315,664

pxe_database_size_in_bytes
18,071
29,868

Circuits stats
Stats on running time and I/O sizes collected for every kernel circuit run across all benchmarks.

Circuit
simulation_time_in_ms
witness_generation_time_in_ms
proving_time_in_ms
input_size_in_bytes
output_size_in_bytes
proof_size_in_bytes
num_public_inputs
size_in_gates

private-kernel-init
169 (+2%)
3,714
22,198 (-1%)
20,630
64,614
89,536
2,731
1,048,576

private-kernel-inner
637 (+1%)
4,311
48,263
92,318
64,614
89,536
2,731
2,097,152

private-kernel-tail
559 (+1%)
2,910 (-1%)
35,900 (-1%)
90,237
77,498
10,656
266
2,097,152

base-parity
6.69 (+3%)
1,341 (+1%)
2,901 (-1%)
128
64.0
2,208
2.00
131,072

root-parity
50.8 (+1%)
52.2 (-19%)
43,684
27,084
64.0
2,720
18.0
2,097,152

base-rollup
793 (-2%)
2,338
74,493 (+1%)
119,610
756
3,648
47.0
4,194,304

root-rollup
116 (+1%)
66.7 (+2%)
19,102
25,297
620
3,456
41.0
1,048,576

public-kernel-app-logic
532
2,898
46,983 (-1%)
104,941
86,302
114,784
3,520
2,097,152

public-kernel-tail
1,228 (+2%)
21,351 (-10%)
153,801 (-1%)
395,386
7,522
10,656
266
8,388,608

private-kernel-reset-small
611 (+2%)
2,223 (+1%)
41,658
120,733
64,614
89,536
2,731
2,097,152

merge-rollup
29.6 (+3%)
N/A
N/A
16,534
756
N/A
N/A
N/A

public-kernel-setup
624
N/A
N/A
104,941
86,302
N/A
N/A
N/A

public-kernel-teardown
527
N/A
N/A
104,941
86,302
N/A
N/A
N/A

private-kernel-tail-to-public
N/A
8,718 (+1%)
81,931
N/A
N/A
114,784
3,520
4,194,304

Stats on running time collected for app circuits

Function
input_size_in_bytes
output_size_in_bytes
witness_generation_time_in_ms
proof_size_in_bytes
proving_time_in_ms
size_in_gates
num_public_inputs

ContractClassRegisterer:register
1,344
9,944
461 (-3%)
N/A
N/A
N/A
N/A

ContractInstanceDeployer:deploy
1,408
9,944
41.9 (-2%)
N/A
N/A
N/A
N/A

MultiCallEntrypoint:entrypoint
1,920
9,944
1,453 (-1%)
N/A
N/A
N/A
N/A

SchnorrAccount:constructor
1,312
9,944
1,021
N/A
N/A
N/A
N/A

SchnorrAccount:entrypoint
2,304
9,944
2,158 (+1%)
16,768
46,253
2,097,152
457

Token:privately_mint_private_note
1,280
9,944
1,168
N/A
N/A
N/A
N/A

Token:transfer
1,376
9,944
4,117
16,768
52,556 (+1%)
2,097,152
457

Benchmarking:create_note
1,312
9,944
989
N/A
N/A
N/A
N/A

FPC:fee_entrypoint_public
1,344
9,944
229
N/A
N/A
N/A
N/A

SchnorrAccount:spend_private_authwit
1,280
9,944
77.4
N/A
N/A
N/A
N/A

Token:unshield
1,376
9,944
3,256 (-1%)
N/A
N/A
N/A
N/A

FPC:fee_entrypoint_private
1,376
9,944
4,057
N/A
N/A
N/A
N/A

Tree insertion stats
The duration to insert a fixed batch of leaves into each tree type.

Metric
1 leaves
16 leaves
64 leaves
128 leaves
512 leaves
1024 leaves
2048 leaves
4096 leaves
32 leaves

batch_insert_into_append_only_tree_16_depth_ms
11.3 (-1%)
18.4 (-1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_count
16.7
31.8
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_16_depth_hash_ms
0.658 (-1%)
0.567 (-1%)
N/A
N/A
N/A
N/A
N/A
N/A
N/A

batch_insert_into_append_only_tree_32_depth_ms
N/A
N/A
52.6
81.5
262 (-2%)
505
994 (-2%)
1,962 (-1%)
N/A

batch_insert_into_append_only_tree_32_depth_hash_count
N/A
N/A
95.9
159
543
1,055
2,079
4,127
N/A

batch_insert_into_append_only_tree_32_depth_hash_ms
N/A
N/A
0.538
0.502
0.475 (-2%)
0.472
0.470 (-2%)
0.468 (-1%)
N/A

batch_insert_into_indexed_tree_20_depth_ms
N/A
N/A
63.0
120 (-1%)
379 (-2%)
742
1,475 (-2%)
2,943 (-1%)
N/A

batch_insert_into_indexed_tree_20_depth_hash_count
N/A
N/A
106
208
692
1,363
2,707
5,395
N/A

batch_insert_into_indexed_tree_20_depth_hash_ms
N/A
N/A
0.547
0.538 (-1%)
0.515 (-2%)
0.510
0.510 (-2%)
0.512 (-1%)
N/A

batch_insert_into_indexed_tree_40_depth_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
67.0

batch_insert_into_indexed_tree_40_depth_hash_count
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
107

batch_insert_into_indexed_tree_40_depth_hash_ms
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
0.595

Miscellaneous
Transaction sizes based on how many contract classes are registered in the tx.

Metric
0 registered classes
1 registered classes

tx_size_in_bytes
83,794
665,117

Transaction size based on fee payment method
| Metric |  |
| - |  |


No reaction to endOfLine settings

Hi friends, i am having an issue in vim in which prettier asks me to delete the extra/empty line at the end of a file, however vscode correctly enforces the need for an empty line at the end of a file.
To be clear im on linux and i do prefer my files to have an empty ending line at the bottom of the file.
coc-settings.json
{
    "coc.preferences.formatOnSaveFiletypes": ["javascript", "typescript", "python"],
    "prettier.requireConfig": true
}

.prettierrc
{
    "semi": true,
    "tabWidth": 4,
    "endOfLine": "auto"
}

.eslintrc.json
{
    "env": {
        "browser": true,
        "es2021": true,
        "node": true
    },
    "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",
        "prettier",
        "plugin:prettier/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "@typescript-eslint"
    ],
    "rules": {
        "@typescript-eslint/no-explicit-any": "off",
        "@typescript-eslint/explicit-module-boundary-types": "off",
        "@typescript-eslint/no-unused-vars": "off",
        "no-useless-catch": "off",
        "linebreak-style": [
            "error",
            "unix"
        ],
        "quotes": [
            "error",
            "double"
        ],
        "semi": [
            "error",
            "always"
        ],
        "prettier/prettier": [
            "error",
            { "endOfLine": "auto" }
        ]
    }
}

vim

vscode

vscode has it correct in this case, what is happening with vim?

Unlike vscode, vim doesn't show the last end of line, when you have extra empty line at the end, it means you have \n\n at the end of buffer.


Cache pr-filters API request

Follow-up to #2757, checks one item from #2671.

Cache CI status for faster Status filter
Rename Status → Checks (as mentioned in https://github.com/sindresorhus/refined-github/pull/2757#issuecomment-583701763)
Call API instead of relying on ci-link
Fix some spacing again, because GitHub likes to change stuff around

BTW (in reply to https://github.com/sindresorhus/refined-github/pull/2757#issuecomment-583273593), the status:pending filter works again as expected :tada:
Test
(same links as in the original PR #2133)

https://github.com/sindresorhus/refined-github/pulls (Filter should be present)
https://github.com/HardikModha/github-playground/pulls (Filters should not be present)

The next step would be to use element-ready and nowAndOnAjaxedPages. Would you like to extend this PR or should I merge this for now?

I'm merging this for now so it appears in today's release

I'm merging this for now so it appears in today's release

The next step would be to use element-ready and nowAndOnAjaxedPages.

@fregante I will give it a shot when I have some time, unless anybody else has done it already until then.


Add AWS resource details API

Add support for querying API resource details

Codecov Report
Base: 61.14% // Head: 60.02% // Decreases project coverage by -1.12% :warning:

Coverage data is based on head (2d62502) compared to base (aa3f9ed).
Patch coverage: 3.29% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #334      +/-   ##
===========================================
- Coverage    61.14%   60.02%   -1.13%
===========================================
  Files           43       43
  Lines         4411     4495      +84
===========================================
+ Hits          2697     2698       +1
- Misses        1529     1612      +83
  Partials       185      185

Flag
Coverage Δ

unittests
60.02% <3.29%> (-1.13%)
:arrow_down:

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

Impacted Files
Coverage Δ

pkg/adapters/grpc/resources_grpc.go
0.00% <0.00%> (ø)

pkg/providers/aws/core/provider.go
32.14% <0.00%> (-29.23%)
:arrow_down:

pkg/membrane/membrane.go
77.04% <100.00%> (+0.11%)
:arrow_up:

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

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


"The calendar can't be loaded from Home Assistant component"

Hi there, not sure if this is a bug, but I can't figure it out! I got it working for about 10mins and it's no longer working, have tried reinstalling via HACS but no luck. Nothing comes up under Configuration > Logs.
It's currently showing this on the dashboard

The current code is simply the following - have really stripped everything down in the troubleshooting process.
 type: 'custom:atomic-calendar-revive'
 entities: calendar.xcm_home

I'm just installing / reinstalling / uninstalling via HACS. As mentioned above, it worked briefly, so not sure what the issue could be. The google_calendars.yaml and that side of things should be set up correctly.
Any ideas?
Thanks,
N

Duplicate... submitting it the first time took me to an Error 404 page on Github, so I submitted again. Sorry!

Duplicate... submitting it the first time took me to an Error 404 page on Github, so I submitted again. Sorry!


Switch to elm-format and 4 space indentation

Quoted from avh4/elm-format's Readme:

elm-format formats Elm source code according to a standard set of rules. It is inspired by the popular gofmt.
The benefits of elm-format:

It makes code easier to write, because you never have to worry about minor formatting concerns while powering out new code.
It makes code easier to read, because there are no longer distracting minor stylistic differences between different code bases. As such, your brain can map more efficiently from source to mental model.
It makes code easier to maintain, because you can no longer have diffs related only to formatting; every diff necessarily involves a material change.
It saves your team time debating how to format things, because there is a standard tool that formats everything the same way.

One more benefit to add: elm-format will provide some automatic code updating when switching from Elm 0.17 to 0.18.
See also editor integration to run elm-format from within your editor.

Looks good 👍 (need to figure out how to turn on PR reviews and approvals)


If trigger('all') is called, all the callbacks should run once instead of twice.

All the functions bound to 'all' should have different arguments, i.e. the first arguments is the eventName.
If trigger('all') is called, the original code would run callbacks twice. At the first time, it would consider them as  normal functions, and wouldn't transfer the eventName. That would be the reason why some functions bound to 'all' events malfunction. On the other hand, it should not run twice when someone explicitly triggers an event only once.

This patch looks correct ... but isn't it a bug to ever try to trigger "all" ? That certainly won't trigger all bound events.
I'm not sure if we should merge this ... because although it fixes the obvious problem of running all twice, doing a .trigger("all") is very incorrect in the first place.

So, trigger("all") should be forbidden, and "all" is kind of a event keyword.Triggering all bound events seem ridiculous, since callbacks usually have various argument structures. Where to go?

... close the ticket, I think. The only other thing to do would be to throw a specific exception, but I don't think that's necessary here.


FE implementation

new workspace structure here https://github.com/project-vinyl/jubmoji.quest/pull/36
thk! @AndrewCLu


Cassandra improvments

Fixes https://github.com/quasar-analytics/quasar/issues/1676

changes the way connectionUri is defined for spark-cassandra
adds spark cluster specific configurations for spark-cassandra
puts spark-cassandra on travis (some race conditions were detected, will deal with that in separate PR)

Once this is done we can move spark-cassandra to backend module

@drostron this is ready for review

@drostron changes are made

Looks good. Needs a merge from master.

@jsantos17 i think those tests were different after all, CI failed but it is 1am and I'm going to bed


[BUG] Issue with dynamic content

Describe the bug
I am trying to load dynamic content from the network when the pager reaches the end. The data is added to the array properly, but the pager behaves very strangely.
To Reproduce

Add some data to your pager via a @Published or @State array
When you reach the end of your pager, add more content to the array

Expected behavior
You will see that the pager no longer functions correctly.
Screenshots / Videos
I can't show a screenshot or video because of NDA restrictions, but the best I can describe the behavior is that the views appear to "stack" on top, as opposed to scrolling. It's very strange, its best to test for yourself.
Environment:

iOS 14
iPhone 7

Hi @metsfan , a sample project  is enough. The description of the bug is very vague and it could be dependant on your implementation. I'm gonna need a sample project here, even dummy code that reproduces the issue. Otherwise, I'm in the dark here and will eventually close the issue if no further information.
I can point you to an example I created for an article in Medium where I use a @Published to dynamically add more items to Pager, it works like a charm:

https://github.com/fermoya/SwiftUIPagerTutorial
https://medium.com/better-programming/paged-scroll-in-swiftui-a-step-ahead-c6a5f74f9924

Please take a look at this code and see if it can help.

Closing this issue as no more info has been provided. If any questions, feel free to reopen.
To see an implementation using @Published, please visit:

https://github.com/fermoya/SwiftUIPagerTutorial
https://medium.com/better-programming/paged-scroll-in-swiftui-a-step-ahead-c6a5f74f9924

Thanks for responding. I finally came back to this issue to resolve it and I found that the issue was stemmed from the fact that i was using \.self as my key for the pager. Even though my object conformed to Hashable and Equatable for some reason it did not work right. I changed to using the index of the item which is an integer, and everything works 100% properly now. Thanks for the question response. I have no idea if it's the Pager or my object that has the issue but it doesn't much matter because it works now :) thanks again.


Adding Integral FeedForward to Hydro

Allowing HydroDispatch constructor to create IntegralFF constraint or Budget constraint depending on the FeedForward passed

Need to push few more changes to add test, DON'T MERGE just yet

https://github.com/NREL/PowerSystems.jl/pull/405 has been merged and PSY tagged please update the project TOML to PowerSystems v0.8.0 and re-run the tests


Display Note icon in chapter

Like bookmarks, there should be an icon in the text that indicates that there is a note for the verse.  This will be very similar to the implementation for bookmarks.  The code will be in src/lib/components/ScriptureViewSophria.svelte

Enabled notes to be stored in local storage.

Updated NoteIcon.svelte to be consistent with the android app.


Critical dependency error when use react-loadable

Bug report

What is the current behavior?
In the code splite, react-loadable is used. For reuse, I encapsulate the Loadable function and return a loadable component through the path of the incoming component, but this causes an error Critical dependency: the request of a dependency is an expression, the page is always in the loading state, and the component is not loaded. If I don't use function encapsulation and use Loadable directly, there will be no problem.
// wrong
import Loadable from 'react-loadable'

const LoadableComponent = path => {
  return Loadable({
    loader: () => import(path),
    loading() {
      return <CircularProgress />
    },
  })
}

const TopticList = LoadableComponent('views/topic-list')

export default () => [
  <Route exact render={() => <Redirect to="/list" />} path="/" key="home" />,
  <Route component={TopticList} path="/list" key="list" />,

If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
// right
import Loadable from 'react-loadable'

const TopticList = Loadable({
  loader: () => import('views/topic-list'),
  loading() {
    return <CircularProgress />
  },
})

const TopticList = LoadableComponent('views/topic-list')

export default () => [
  <Route exact render={() => <Redirect to="/list" />} path="/" key="home" />,
  <Route component={TopticList} path="/list" key="list" />,

Other relevant information:
webpack version:  4.29.5
Node.js version: 8.12.0
Operating System: os 10.3.0
react-loadable: 5.5.0

You code is too dynamic and not statically analysable. Rewrite it to have at least a partially constant expression in import().
Maybe this way:
const TopticList = LoadableComponent(() => import('views/topic-list'))

@sokra
import React from 'react'
import { Route, Redirect, withRouter, } from 'react-router-dom'
import { inject, observer, } from 'mobx-react'
import Loadable from 'react-loadable'

import CircularProgress from '@material-ui/core/CircularProgress'

import compose from 'utils/compose'

// 结合 mobx 或者 redux 需要将 withRouter 放在最外层
// https://reacttraining.com/react-router/web/api/withRouter
const LoginRoute = ({ isLogin, component: Component, ...rest }) =>
  <Route
    {...rest}
    render={
      props =>
        isLogin ? <Component {...props} /> :
          <Redirect to={{ pathname: '/user/login', search: `?from=${rest.path}`, }} />
    }
  />

const InjectedRoute = compose(
  withRouter,
  inject(stores => ({
    isLogin: stores.appStore.user.isLogin,
  })),
  observer,
)(LoginRoute)

const LoadableComponent = path => {
  return Loadable({
    loader: () => import(path),
    loading() {
      return <CircularProgress />
    },
  })
}

const TopicList = Loadable({
  loader: () => import('views/topic-list'),
  loading() {
    return <CircularProgress />
  },
})

export default () => [
  <Route exact render={() => <Redirect to="/list" />} path="/" key="home" />,
  <Route component={TopicList} path="/list" key="list" />,
  <Route component={LoadableComponent('views/topic-detail')} path="/detail/:id" key="detail" />,
  <Route component={LoadableComponent('views/user/login')} path="/user/login" key="login" />,
  <InjectedRoute component={LoadableComponent('views/user/info')} path="/user/info" key="info" />,
  <InjectedRoute component={LoadableComponent('views/topic-create')} path="/topic/create" key="create" />,
]

There is still a problem with your solution
Error: Cannot find module './0.server-entry.js'
    at Function.Module._resolveFilename (module.js:548:15)
    at Function.Module._load (module.js:475:25)
    at Module.require (module.js:597:17)
    at require (internal/module.js:11:18)
    at Function.requireEnsure [as e] (server-entry.js:46:25)
    at loader (webpack:///./client/router/index.jsx?:68:60)
    at load (/Users/ender/learning/github/react-cnode/node_modules/react-loadable/lib/index.js:28:17)
    at init (/Users/ender/learning/github/react-cnode/node_modules/react-loadable/lib/index.js:121:13)
    at new LoadableComponent (/Users/ender/learning/github/react-cnode/node_modules/react-loadable/lib/index.js:150:7)
    at /Users/ender/learning/github/react-cnode/node_modules/react-tree-walker/dist/react-tree-walker.js:174:30 code: 'MODULE_NOT_FOUND'

i use react ssr, after using react-loaderable, the server portal page has been packed a lot. When I started the server, I only read the server-entry on the hard disk. Other versions don't know where to come from. and the issue is above
0.server-entry.js  75.5 KiB       0  [emitted]
2.server-entry.js  25.7 KiB       2  [emitted]
3.server-entry.js  11.6 KiB       3  [emitted]
4.server-entry.js  13.3 KiB    4, 9  [emitted]
5.server-entry.js  9.04 KiB       5  [emitted]
6.server-entry.js  5.95 KiB       6  [emitted]
7.server-entry.js  6.38 KiB       7  [emitted]
8.server-entry.js     5 KiB       8  [emitted]
9.server-entry.js     2 KiB       9  [emitted]
  server-entry.js   116 KiB       1  [emitted]  app

@chnliquan have you found the solution? I'm experiencing the same problem.

I'm having this same issue as well.

I'm also having this issue


feat(Patterns): Add SVGR build process and SVGO settings

Overview

Updates patterns to be SVGR built and adds pattern specific SVGO options.
Renames some files and types to work with SVGR.
Adds usePatternId as internal hook that generates a unique iterative id per each pattern on the page.
Adds babel transforms to replace extant references to pattern ids and urls throughout each pattern.
Updates implementations of NotificationItem and FloatingCard to use new Patterns and remove imports to Pattern component.

PR Checklist

[x] Related to designs:
[x] Related to JIRA ticket: https://codecademy.atlassian.net/browse/GM-288
[x] I have run this code to verify it works
[ ] This PR includes unit tests for the code change

📬Published Alpha Packages<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fb425028539400b37f247f--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-patterns@0.4.8-alpha.da4dec.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fb46c1afc7e6089d6b98b5--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-patterns@0.4.8-alpha.d6594c.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fb4919e0e9a40b5c82f32e--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-patterns@0.4.8-alpha.01de31.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fb523be3d9331a3d4919b4--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-patterns@0.4.8-alpha.38e56b.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fb58f3e3d9331af5491c99--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-patterns@0.4.8-alpha.a69174.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fdb51111c0dff703fa5326--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-patterns@0.4.8-alpha.e0759d.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fe0c2d571f0666c299623d--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.4.73-alpha.ce9357.0@codecademy/gamut-labs@19.16.11-alpha.ce9357.0@codecademy/gamut-patterns@0.4.8-alpha.ce9357.0@codecademy/gamut@35.3.1-alpha.ce9357.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60fee8d2086ff408c4a2a1c8--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.4.73-alpha.7f8056.0@codecademy/gamut-labs@19.16.11-alpha.7f8056.0@codecademy/gamut-patterns@0.4.8-alpha.7f8056.0@codecademy/gamut@35.3.1-alpha.7f8056.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60feec637e4c9510e09c43b2--gamut-preview.netlify.appDeploy Logs

📬Published Alpha Packages:@codecademy/gamut-kit@0.4.74-alpha.9bbf6f.0@codecademy/gamut-labs@19.16.12-alpha.9bbf6f.0@codecademy/gamut-patterns@0.4.8-alpha.9bbf6f.0@codecademy/gamut@35.3.2-alpha.9bbf6f.0<EMAIL_ADDRESS>
🚀 Styleguide deploy preview ready!https://60ff067ab014be2f4ae0d6a7--gamut-preview.netlify.appDeploy Logs


Buck daemon event bus encountered an error

I'm trying to get RBE working, and besides taking longer than I'd expect (but that might be the buildbarn setup, unknown yet), it dies before completing a compilation.
Jobs completed: 95. Time elapsed: 228.6s. Cache hits: 75%. Commands: 4 (cached: 3, remote: 0, local: 1)
Command failed: Buck daemon event bus encountered an error, the root cause (if available) is displayed above this message.

Caused by:
    0: status: Unknown, message: "error reading a body from connection: stream closed because of a broken pipe", details: [], metadata: MetadataMap { headers: {} }
    1: error reading a body from connection: stream closed because of a broken pipe
    2: stream closed because of a broken pipe

I suspect what's happening here is I'm running out of RAM, everything slows to a crawl then I get the error message and top indicates the same. The machine I'm on currently only has 16Gb of RAM. RBE is occurring on a machine with 128Gb (although I'm fairly certain linking takes place locally only?).
Is there a way to control the parallelism?
Additionally, I tried calling buck2 rage since that seemed like an error reporting mechanism
Invocation: (type a number between 0 and 0) 0
Selected invocation at Fri Apr 21 14:48:32 2023 -04:00

2023-04-21T18:52:56.994947Z  WARN buck2_client::commands::rage: Couldn't send rage results to scribe, rage ID `b4325f0f-e40a-467c-bd95-db93ed52823d`
Command failed: Failed to spawn pastry

Which is leading me to think it's an internal tool only? Is that right?

Is that right?

We should either patch rage to generate text data or hide it in open source version.

CC @iguridi who has implemented the rage command.

Is there a way to control the parallelism?

-j

although I'm fairly certain linking takes place locally only?

We have links happening remote and locally, largely driven by how much data is being moved IIRC. Guessing @krallin might know more here.

Yeah the input size can control where we run, though that’s an option that
I don’t think our PSS examples use (that’s a field on CommandExecutorConfig)

I suspect what's happening here is I'm running out of RAM, everything
slows to a crawl then I get the error message and top indicates the same.
The machine I'm on currently only has 16Gb of RAM.

And what’s using all this RAM? buck? Something else (linker?)
If too many links are running concurrently then the best approach is
probably to change the link weight, which IIRC is a C++ toolchain field.
On Sat, 22 Apr 2023 at 01:02, Alex Lian @.***> wrote:

Is there a way to control the parallelism?
-j
although I'm fairly certain linking takes place locally only?
We have links happening remote and locally, largely driven by how much
data is being moved IIRC. Guessing @krallin https://github.com/krallin
might know more here.
—
Reply to this email directly, view it on GitHub
https://github.com/facebook/buck2/issues/189#issuecomment-1518410065,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AANIHVQSM5KJNMC2KL5FU3DXCMGXRANCNFSM6AAAAAAXHGXEL4
.
You are receiving this because you were mentioned.Message ID:
@.***>


benchmarking perf numbers and loss convergence

### Tasks
- [ ] discuss what to add / show in https://github.com/pytorch/torchtitan/blob/main/docs/performance.md
- [x] (ETA 10/31) rerun 1D + torch.compile on 8B 128 GPU https://github.com/pytorch/torchtitan/issues/619
- [x] float8 perf regression investigation
- [x] loss convergence runs

### Tasks
- [x] 3D 405B with Zero-Bubble PP (might need to revisit)

@tianyu-l It would be good if you can also add the bandwidth that you had available per GPU in the cluster. I tried recreating the MFU numbers, only to realize that the A100 cluster only brought 200 GB/s bandwidth where as your AWS cluster brings 400 GB/s with EFA, creating a significant difference between the MFU achievable.


Key lstm/basic_lstm_cell/kernel not found in checkpoint

The same issue already opened, sorry.
I had tried to run your model on the latest version of TF (1.2.0), but encountered the following error:
 Key lstm/basic_lstm_cell/kernel not found in checkpoint
I've found @cshallue answer. The original version didn't work out for me. After some digging, I've changed values in vars_to_rename - did the trick.
OLD_CHECKPOINT_FILE = "model.ckpt-1000000"
NEW_CHECKPOINT_FILE = "model2.ckpt-1000000"

import tensorflow as tf
vars_to_rename = {
    "lstm/basic_lstm_cell/weights": "lstm/basic_lstm_cell/kernel",
    "lstm/basic_lstm_cell/biases": "lstm/basic_lstm_cell/bias",
}
new_checkpoint_vars = {}
reader = tf.train.NewCheckpointReader(OLD_CHECKPOINT_FILE)
for old_name in reader.get_variable_to_shape_map():
  if old_name in vars_to_rename:
    new_name = vars_to_rename[old_name]
  else:
    new_name = old_name
  new_checkpoint_vars[new_name] = tf.Variable(reader.get_tensor(old_name))

init = tf.global_variables_initializer()
saver = tf.train.Saver(new_checkpoint_vars)

with tf.Session() as sess:
  sess.run(init)
  saver.save(sess, NEW_CHECKPOINT_FILE)

One might find it useful.

Simply creating vurtualenv and downgrading tensorflow seems to work too:
virtualenv ./env
./env/bin/pip install tensorflow==1.0 werkzeug
source ./env/bin/activate

If you have an outdated checkpoint file (as I found in Syntaxnet), just use the "official" contributed translator you can find in:
models/research/syntaxnet/tensorflow/tensorflow/contrib/rnn/python/tools/checkpoint_convert.py

If you have an outdated checkpoint file (as I found in Syntaxnet), just use the "official" contributed translator you can find in:
models/research/syntaxnet/tensorflow/tensorflow/contrib/rnn/python/tools/checkpoint_convert.py

I uploaded the converted checkpoint (V2) here:
https://drive.google.com/file/d/1MN_Az1fF-DFDt0FNt5KFO8Fo0xl2KdVc/view?usp=sharing
This has beed tested with Tensorflow 1.12


Running "shell:prepareLibsass" (shell) task fails: Fatal error: strderr is not defined

Running "shell:prepareLibsass" (shell) task
Preparing libsass version 3.2.2
  cleaning target directory
  downloading repository to target directory
Cloning into 'libsass'...
  checking out branch/tag and initializing submodules
Note: checking out '3.2.2'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at 66631c0... Merge pull request #1156 from xzyfer/feat/salt-the-earth-of-compact

Running "get-emscripten-version" task
Fatal error: strderr is not defined

Since your output says Running "get-emscripten-version" task, I don't think it's shell:prepareLibsass that is failing. The task is trying to output strderr while it should be stderr. I fixed that in master just now. I assume you don't have emscripten installed / available in PATH.

thanks. Indeed i have to install emscripten. For some reason i expected that running npm install  also installed it. I hope that building the latest version possible fixed #29

Well now i can run ./emcc -v:
~/Dropbox/testomgeving/emscripten$ ./emcc -v
WARNING  root: (Emscripten: settings file has changed, clearing cache)
INFO     root: (Emscripten: Running sanity checks)
emcc (Emscripten GCC-like replacement + linker emulating GNU ld ) 1.32.0
clang version 3.6.0 (https://github.com/kripken/emscripten-fastcomp-clang ba2eba3c4548c27b82bf945e8eba37bf630585a8) (https://github.com/kripken/emscripten-fastcomp bdf2fc7e758ee9a4594bed666d0a7a86e6e787b1)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Candidate multilib: .;@m64
Selected multilib: .;@m64
INFO     root: (Emscripten: Running sanity checks)

And ./emscripten:
this helps projects using emscripten find it
EMSCRIPTEN_ROOT = os.path.expanduser(os.getenv('EMSCRIPTEN') or       '/home/bass/Dropbox/testomgeving/emscripten') # directory

I still got the error mentioned above. Should i have to link emcc globally?

Should i have to link emcc globally?

it needs to be available in PATH, yes.
I installed emscripten via homebrew, btw. brew install emscripten --HEAD (the --HEAD option requires compiling emscripten on your system, rather than downloading binaries - this can take a while).

Well okay, adding emscripten to the path, solves this issue.
Notice that on ubuntu i can also run sudo apt-get install emscripten which installs version 1.10.0. Running emcc --version for  version 1.10.0. returns a first line with the commit nummer NOT set:
emcc (Emscripten GCC-like replacement) 1.32.0 () which means that the get-emscripten-version task fails in the first place.
Also the dependency for the closure compiler was missing, see #31

which means that the get-emscripten-version task fails in the first place.

fixed the regex accordingly…


Use settings as hash for Settings overrides in IdpMetadataParser#parse

Intents to fix issue #330

Travis CI seems to have failed on jruby on unrelated code.

It was a temp problem with the CI.
What do you think if we check the value of options[:settings] (if is provided in the method) and then based on what kind of object is, we call or not the  OneLogin::RubySaml::Settings constructor?

Solved at:

Allow multiple authn_context_decl_ref in settings
Allow options[:settings] to be an hash for Settings overrides in IdpMetadataParser#parse
include vendor folder on SimpleCov filters


Unable to Pickle ServiceBus Message Object

Package Name: azure-servicebus
Package Version: <IP_ADDRESS>b4
Operating System: Red Hat 4.8.5-39
Python Version: 3.6.8

Describe the bug
When attempting to pickle.dump() an array of Message objects a TypeError is raised.
To Reproduce
Steps to reproduce the behavior:

Attempt to pickle a Message object

Expected behavior
The object is pickled correctly
Screenshots
import pickle
from azure.servicebus import Message

msgs = [Message(body={"test"})]
pickle.dump(msgs, open("./dump", "wb")

File "stringsource", line 2, in uamqp.c_uamqp.StringValue.__reduce_cython__
TypeError: no default __reduce__ due to non-trivial __cinit__

Closing as duplicate of https://github.com/Azure/azure-sdk-for-python/issues/12901


Remove outdated ribon bar and module styling

Resolves https://github.com/dnnsoftware/Dnn.Platform/issues/3563
Summary

Removes all current admin.css styling which includes old ribbon bar, edit bar and module CSS styling that takes effect when logged in as an administrator.

I tried testing out everything on the file manager and all admin actions in persona bar I have not ran into any issues as of yet. We can put some things back as needed as it is a clean slate to start with.
I noticed it helped align the settings/edit/move boxes that I always had problems with to where they need to be along with fixing the register button issue while logged in as admin.
I think the styles are all being applied by the new theme as needed.  Only concern I had was if anyone still used ribbon bar or edit CP but I figured in 9.5 they should consider moving to persona bar if they have not yet.
So this actually fixes 2 issues I was having 👍

I agree, there are some z-indexes for the action menus and stuff. Still good but has a small potential for a breaking change on 3rd party themes maybe. I would keep this but merge it for 10 to be safe. Thoughs?

Sorry, hit close by mistake, just reopened

IMO I think this cleanup should be safe for version 10 for sure. I can address that in another PR after this one has been completed for version 9.  I can use this PR and make minimal adjustments to fix the icons for modules aligning and the register button issue that I noticed it had cured and remove the edit and ribbon bar CSS.  While I am in here I will see if there is anything else I can help with.
That way I can make changes to version 9 for version 10 or does that matter?  I am not sure how the changed files in 9 might effect version 10 files.   So to play it safe I am thinking I need to make CSS changes here first in 9 then make a 10 version.  If it does not matter you can approve this for 10 and I will make a new version 9 PR.
I wish all the different CSS files in DNN could be edited in the CSS editor.  It would be nice to have easy access to files like these in DNN 10.
I am also very concerned with the CSS file load order which I will bring up that issue soon.  I think this has a bit of an issue with it that has been causing a lot of grief for CSS designers and module developers.
For version 9 maybe I can release another PR with minimal adjustments to fix the icons for modules aligning and the register button issue that I noticed it had cured and remove the edit and ribbon bar CSS.
I can make another PR with this version for version 10.
We need to create one fix for version 9 to sweeten up this version as far as it can go.  The inline block and module icon CSS bugs DNN 9, I can leave all other css intact CSS and adjust those.
That and the CSS for the issue recently for the admin logs drop down which seems pretty buried in the code I spent a long time reading all the logic there trying to locate it.
I will be poking around here for the next couple weeks it looks like to dial these three issues in and move on.

I just went through all of the CSS trying to see if there was anything that relates to DNN 9.5
Do we use a Control Bar? Edit Bar? or any of the old CP's?  That is all the Z stuff relates to... I dont see that anything here effects my current installation of DNN 9.5
In fact things seem perfectly fine.  Can anyone get an example of when any of these things effect version 9.5 of DNN?  Persona Bar controls everything except couple pages I have had no issues with.  I think it is a bunch of unnecessary code that could lighten up DNN in my opinion here now unless someone can show an example of where any of this matters in the current version of DNN 9.

Due to the fact that all admin modules are PersonaBar extensions since DNN 9.2, any old control panel cannot be used any longer.

After discussing this in the approvers meeting, due to the potential breaking nature of these changes we will be targeting to merge this as part of Dnn10 for now.

Thanks everyone for the help here!  Thank you @bdukes for the rebase.


[ENH] Make Block, SparseIndex and HNSW cache size aware

Description of changes
Summarize the changes made by this PR.

Improvements & Bug fixes

...

New functionality

...

Test plan
How are these changes tested?

[ ] Tests pass locally with pytest for python, yarn test for js, cargo test for rust

Documentation Changes
Are all docstrings for user-facing APIs updated if required? Do we need to make documentation changes in the docs repository?

#2697  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Ishiihara and the rest of your teammates on  Graphite

Not sure if this is just noise, but seeing this made me think of this adaptive replacement cache (ARC) that we used in Consul to do our caching dirty work. It's like an LRU on sterioids in that it takes into account recent resource usage to adapt its eviction strategy. Apparently PostgreSQL uses it internally too.
It's probably out of scope for this change, but wanted to get the gears turning in case there was a need to get more sophisticated with our caching strategies.


NME: Fix output names of PBRMetallicRoughness block

See https://forum.babylonjs.com/t/how-to-use-lightmaps-with-the-node-shader-and-the-pbrmetallicroughness-node/22990/7

I don't think so, it was a bug, using the block by code would fail.


Build pipeline - finished!

Finished the create a build pipeline!

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: Fazer01 sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.