PROPOSAL: pluggable storage backend for chart repo server

Proposal: pluggable storage backend for chart repo server
User case
The idea here wants to solve the same issue described in #2093.
There is needs to put the charts on a storage besides Linux file system, such as Swift. The proposal here is to keep helm chart_repo client unchanged, and divide helm chart_repo server logic to two parts:

chart repository logic(main part should be "index.yaml" generation and chart reading logic) ;
chart storage logic.
The idea here is to keep chart repo client/server HTTP interface unchanged, but make the storage backend part of chart repo server be pluggable:
It can read charts from Linux file system, Swift, and etc.

Thanks for creating this new proposal.
As I understand it, this would make it possible to run helm serve and use a back-end like Swift or S3 instead of the local filesystem. Is that right?

Yes.
That is correct. :-)

Coming back to this topic now, after the downloaders are pluggable.
Would you accept a PR which only solves the first bullet of @tonyaw use-case?
My thinking is that if I want to compose an alternative tiller client (not necessarily in helm plugin, but with helm code pkg import...), let's say, which want to use non-http backend, than from chart mgmt PoV I have to be able to:

Download and dep-build charts from my custom backend - that is solved by the pluggable downloaders
Upload charts to my custom backend - this does not mandate any helm code I think, since downloader core is already own code and not part of helm
(Re)generate index.yaml and push to custom backend

Since the first two is fine already, now I want to solve the last thing. Index generation is currently accept local directory with charts to parse. I would like to introduce a generic layer under IndexDirectory() in pkg/repo/index.go. Than IndexDirectory() would call this generic layer, just like custom user code. Generic interface maybe only need to transfer the list of chart URLs to parse.
How does it sound?

chartmuseum allows for pluggable storage backends and regenerates index.yaml based on the contents from that backend. I think we can consider this closed and users who are interested in doing this should use chartmuseum as their repository server instead of helm serve. helm serve was never meant to be anything more than a basic web server for development purposes anyways. :)


UX improvement on Warnings [design]

This task is automatically imported from the old Task Issue Board and it was originally created by Greg Ociepka.
Original issue is here.

For now we will display warning with orange stripes background and errors with red stripes background. Warnings will be displayed after hovering the node (just as dataflow errors are). There is a question if we want to show warnings nicer in the future. This task is about designing improved way of displaying warnings in the future.
Blockers:
#184237388 resolved
#184237276 resolved

New design of warnings was implemented in GUI2


Clarification request: creating resources

In the Creating Resources section, it is stated:

The request MUST include a single resource object as primary data.

It is not said anything about other potentially valid top level members (like jsonapi, included, links, none of which would make sense a priori in a client-issued payload, and meta, which could).

jsonapi, included, and links don't currently have a meaning in client issued payloads...though at least included and links are likely to acquire a meaning in the future (for sideposting and extension negotiation respectively). at the moment, we don't explicitly prohibit those members from appearing in request documents (i.e., client issued payloads), but maybe we should...

I'm curious what would be a possible meaning of top level links in a client-issued payload?

One possible meaning is being explored in https://github.com/json-api/json-api/pull/957/commits/9b8235d246fb44b5b87025b8b0c85c1eab1f8b8c. Note, though, that the final meaning is very likely to be different in some details than what's proposed there.

Ok, fair enough. Closing this then.


Multiple resource-exhaustion-related errors after an update to v8.0.0

Environment details

OS: Container Optimized OS (cos-stable-81-12871-119-0)
Node.js version: 14.4.0
npm version: 6.14.5
@google-cloud/logging version: 8.0.0

Steps to reproduce
I have a service running in a managed instance group that uses @google-cloud/logging. After a recent update of @google-cloud/logging from v7.3.0 to v8.0.0 I've observed that the service was running out of memory rapidly and no logs were written anymore. This was due to a log queue building up in memory and not being forwarded to Cloud Logging. I've observed many errors related to bandwidth exhaustion, as well as seeing per minute log write quota being reached. Sample errors:

Code 8, "Quota exceeded for quota metric 'Log ingestion requests' and limit 'Log ingestion requests per minute' of service 'logging.googleapis.com' for consumer 'project_number:XXXXXXXXXX'."
Code 8, "Bandwidth exhausted".
Code 13, "Received RST_STREAM with code 2"

I've reached ~8 million errors in 15 minutes.
After a downgrade to v7.3.0, all went back to normal.

@alexander-fenster this sounds like something we should dig into next week. We converted the library to TypeScript between v7.3.0 and v8.x.x, and a lot of dependencies were updated during this process.
@merlinnot thank you for the bug report, for now I've made it a p2 since you have a workaround.

@merlinnot would you be able to provide an example of how you are integrating with  the logging library (are you  using a wrapper like @google-cloud/logging-winston or @google-cloud/logging-bunyan?) or are you using the library directly.
If you're using the library directly, perhaps you could share some source that provides a basic outline of how you're interacting the library?

@bcoe I'm using the library directly. As far as I remember, log.write has/had a buffering (batching) mechanism for logs, that's what I was relying on - calling log.write and not awaiting it. It works with v7, doesn't work with v8.

@merlinnot Thank you for the report - I found a problem and I'm working on a fix.

@merlinnot we've released a candidate release of the library which we believe should address your batching issues:
<EMAIL_ADDRESS>Let us know if it works well for you, and we'll call this issue fixed?

@merlinnot we've released the latest version of the library with the batching fix, please let us know if you  continue to run into any issues.

Hey, I somehow missed your message, sorry. As a mitigation we had to start using a default COS logging agent (the one in Ruby) and there's no real reason for us to switch back, so I don't have an easy way to test that. But I believe in your skills so we can consider the issue closed :)


can't disable TLS 1.0, 1.1, 1.2

Welcome!

[X] Yes, I've searched similar issues on GitHub and didn't find any.
[X] Yes, I've searched similar issues on the Traefik community forum and didn't find any.

What version of the Traefik's Helm Chart are you using?
10.19.4
What version of Traefik are you using?
2.6.3
What did you do?
set the following:
ports.websecure.tls.enabled = true
ports.websecure.tls.options = traefik-default@kubernetescrd
tlsOptions.default.minVersion = VersionTLS13
tlsOptions.default.sniStrict = true

On any Ingress deployed that this traefik consumes the following annotations:
traefik.ingress.kubernetes.io/router.tls: "true"
traefik.ingress.kubernetes.io/router.entrypoints: websecure
traefik.ingress.kubernetes.io/router.tls.options: traefik-default@kubernetescrd

kubectl get tlsoption default -n traefik -o yaml

apiVersion: traefik.containo.us/v1alpha1
kind: TLSOption
metadata:
  annotations:
    meta.helm.sh/release-name: traefik-external
    meta.helm.sh/release-namespace: traefik
  creationTimestamp: "2022-06-09T01:41:11Z"
  generation: 2
  labels:
    app.kubernetes.io/instance: traefik-external
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: traefik
    helm.sh/chart: traefik-10.19.4
  name: default
  namespace: traefik
  resourceVersion: "752027"
  uid: edda0817-db65-42df-85d0-140c35c70696
spec:
  minVersion: VersionTLS13
  sniStrict: true

I see traefik started with:
...
    - --entrypoints.websecure.http.tls=true
    - --entrypoints.websecure.http.tls.options=traefik-default@kubernetescrd
...

No matter what combination of things I try or referencing the "TLSOption" via just default... it doesn't matter
When using testssl.ssh or any other online tool that will check an endpoint for supported TLS versions.... TLS 1.0 and 1.1 and 1.2 are still showing as supported....
Lost as to how to disable things...
What did you see instead?
see above
What is your environment & configuration?
see above
Additional Information
none

i figured this out


Update column definitions

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.81%. Comparing base (e02bad7) to head (f22ef90).
Report is 1 commits behind head on main.

Additional details and impacted files
@@             Coverage Diff              @@
##               main     #268      +/-   ##
============================================
+ Coverage     91.71%   91.81%   +0.09%
  Complexity      534      534
============================================
  Files            93       93
  Lines          1896     1894       -2
  Branches        124      124
============================================
  Hits           1739     1739
+ Misses          106      104       -2
  Partials         51       51

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Update Set-SPOHideDefaultThemes.md

https://github.com/MicrosoftDocs/office-docs-powershell/issues/3179

Docs Build status updates of commit 3ec650b:
:clock10: Full build: the average full build time is 14 min(s) 12 sec(s), this is based on the last 51 build(s) for this repository.
:warning: This is a FULL build due to the incremental build being disabled in configuration file (.openpublishing.publish.config.json in 'live' branch). For more detailed info, please click here.

Docs Build status updates of commit 3ec650b:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Set-SPOHideDefaultThemes.md
:white_check_mark:Succeeded
View (sharepoint-ps)

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

Docs Build status updates of commit 7f12836:
:clock10: Full build: the average full build time is 14 min(s) 13 sec(s), this is based on the last 52 build(s) for this repository.
:warning: This is a FULL build due to the incremental build being disabled in configuration file (.openpublishing.publish.config.json in 'live' branch). For more detailed info, please click here.

Docs Build status updates of commit 7f12836:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Set-SPOHideDefaultThemes.md
:white_check_mark:Succeeded
View (sharepoint-ps)

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

Docs Build status updates of commit 6234eff:
:clock10: Full build: the average full build time is 14 min(s) 15 sec(s), this is based on the last 87 build(s) for this repository.
:warning: This is a FULL build due to the incremental build being disabled in configuration file (.openpublishing.publish.config.json in 'live' branch). For more detailed info, please click here.

Docs Build status updates of commit 6234eff:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

sharepoint/sharepoint-ps/sharepoint-online/Set-SPOHideDefaultThemes.md
:white_check_mark:Succeeded
View (sharepoint-ps)

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


Console create:plugin - PascalCase namespace

Winter CMS Build
dev-develop
PHP Version
8.0
Database engine
MySQL/MariaDB
Plugins installed
No response
Issue description
Winter CMS 1.2
Console command create:plugin incorrectly changes namespace. Camelcase names are changed to capitalized names.
Example:
php artisan create:plugin WebVPF.MyName

Plugin.php file generation result:
<?php namespace Webvpf\Myname;
...

Must be:
<?php namespace WebVPF\MyName;

Steps to replicate
Create a plugin
Workaround
No response

Just need to change a single line here: https://github.com/wintercms/winter/blob/wip%2F1.2/modules/system/console/BaseScaffoldCommand.php#L47. PRs welcome.

@LukeTowers Actually, to be synced with the scaffold methods' code style, we'll need another modification here to add the ucfirst case: https://github.com/wintercms/storm/blob/develop/src/Scaffold/GeneratorCommand.php#L144-L146

@RomainMazB I'm not sure I understand, could you expand on that?

Sure @LukeTowers.
To convert "WebVPF" to "WebVPF" and ensuring the first letter is uppercase to keep the PascalCase style, we need to use the php native ucfirst function, or the Str::ucfirst laravel helper.
So, to me, we have two ways to fix this:
The cheap:
// Using native ucfirst function or Str::ucfirst directly inside the method you mentioned
$ucfirst_author = ucfirst($vars['author']);
$ucfirst_plugin = ucfirst($vars['plugin']);
$vars['plugin_namespace'] = "{$ucfirst_author}\\{ucfirst_plugin}";

The good (to me):
// GeneratorCommand.php
    protected function processVars($vars)
    {
        $cases = ['upper', 'lower', 'snake', 'studly', 'camel', 'title', 'ucfirst']; // Add ucfirst casing

// BaseScaffoldCommand.php
$vars['plugin_namespace'] = "{$vars['ucfirst_author']}\\{$vars['ucfirst_plugin']}";

The second one looks prettier with the rest of the method:
$vars = parent::processVars($vars);

$vars['plugin_id'] = "{$vars['lower_author']}.{$vars['lower_plugin']}";
$vars['plugin_code'] = "{$vars['studly_author']}.{$vars['studly_plugin']}";
$vars['plugin_url'] = "{$vars['lower_author']}/{$vars['lower_plugin']}";
$vars['plugin_folder'] = "{$vars['lower_author']}/{$vars['lower_plugin']}";
$vars['plugin_namespace'] = "{$vars['ucfirst_author']}\\{$vars['ucfirst_plugin']}";

return $vars;

instead of this:
$vars = parent::processVars($vars);

$ucfirst_author = ucfirst($vars['author']);
$ucfirst_plugin = ucfirst($vars['plugin']);

$vars['plugin_id'] = "{$vars['lower_author']}.{$vars['lower_plugin']}";
$vars['plugin_code'] = "{$vars['studly_author']}.{$vars['studly_plugin']}";
$vars['plugin_url'] = "{$vars['lower_author']}/{$vars['lower_plugin']}";
$vars['plugin_folder'] = "{$vars['lower_author']}/{$vars['lower_plugin']}";
$vars['plugin_namespace'] = "{$ucfirst_author}\\{ucfirst_plugin}";

return $vars;

@LukeTowers I think that @RomainMazB was referrencing that we would need to add ucfirst modifier (https://www.php.net/manual/en/function.ucfirst.php) to make the first character of the string uppercase. However, that is not needed as studly case is basically equal to PascalCase (https://www.php-fig.org/psr/psr-12/#21-basic-coding-standard).

@arvislacis you've got a point. So now the question is: why php artisan create:plugin WebVPF.MyName generates these studly variables:
"studly_author" => "Webvpf"
"studly_plugin" => "Myname"

and Str::studly('WebVPF') generates the good studly case 🤔
>>> Str::studly('WebVPF');
=> "WebVPF"
>>> Str::studly('MyName');
=> "MyName"

@arvislacis @LukeTowers , here is why.
The BaseScaffoldCommand class has the HasPluginArgument trait, which means that the arguments relies on the PluginManager's normalizeIdentifier method: https://github.com/wintercms/winter/blob/wip/1.2/modules/system/console/traits/HasPluginArgument.php#L54-L58
This method actually lowercase the plugin name and author, which fails all the rest of the process...
https://github.com/wintercms/winter/blob/wip/1.2/modules/system/classes/PluginManager.php#L575-L579
When the tiny problem becomes a "big" one 😄

Fair point. What I would like to see is that the namespace is generated from the provided input verbatim rather than trying to do any case modifications to it. It should be up to the dev whether their namespace is Webvpf or WebVPF.

Yes, I agree on you with this - the best solution in this situation probably would be to take input verbatim..., the only modification maybe could be applied only to the first letter to make it always uppercase so it matches the coding standarts and guides (for example, if dev accidentally or by other means enter everything in the lowercase), anyways, that's also a disputable point.

@arvislacis yes, their is chance where the dev will fail on typing, especially when creating model or controller after creating the plugin...
I agree with the verbatim stuff but this introduce possible dev errors. We should warn this into the documentation.

@LukeTowers , I was about to submit a PR when discovering something that is strange but provides another way to treat two problems at once.
On the 1.2 branch, you introduced a getNormalizedIdentifier method with the parameter lower which should define if we want a lower-cased normalized identifier or not:
https://github.com/wintercms/winter/blob/5ccde6fb46ac4e8a65316e183949ebde566d705d/modules/system/classes/PluginManager.php#L575-L589
I thought this method was our perfect solution, but actually this method can't return anything but a lower-cased normalized identifier due to the fact that itself uses the normalizeIdentifier method which - as we defined previously - forcefully return a lower-cased identifier.
I've searched into the code where this method is used and I've found 7 places where the lower parameter is set to true and 1 where the default false value is used:

As we now know, all of these usages could use the lower parameter set to true because the getNormalizedParameter basically rely on the normalizeIdentifier which return a lower cased string.
What I suggest is to introduce a lower parameter in the method which caused our initial problem, defaulted to true so we could:

Define in our scaffold command if we want to use a lower case version for the plugin and author names
Fix the lower parameter from the getNormalizedParameter which atm doesn't do anything (even if we actually doesn't need it atm)

The lower parameter into the getNormalizedParameter method could also be defaulted to true at this point of time where all the place where we use it work with a lower-cased string

Something like:
     public function normalizeIdentifier(string $code, bool $lower = true): string
     {
         $lowerCode = strtolower($code);

         $code = $this->normalizedMap[$lowerCode] ?? $code;

         return $lower ? strtolower($code) : $code;
     }

     /**
      * Returns the normalized identifier (i.e. Winter.Blog) from the provided
      * string or PluginBase instance.
      */
     public function getNormalizedIdentifier(PluginBase|string $plugin, bool $lower = true): string
     {
         return $this->normalizeIdentifier($this->getIdentifier($plugin), $lower);
     }

@jaxwilko can you look at @RomainMazB's comment above when you've got a moment? Too late at night for me to fully parse it at the moment.

Hey all, I've raised PR https://github.com/wintercms/winter/pull/588 which resolves the issue.
The problem from my perspective is that normalizeIdentifier() would check $this->normalizedMap for the code, but when the code was not found would return the lowered input rather than the actual input.
To simplify things, I've moved this logic into getNormalizedIdentifier() (which still has the additional functionality of handling plugin objects & returning a lowered identified), and then updated normalizeIdentifier() to call  getNormalizedIdentifier(). This was done for backwards compatibility so we didn't have to change normalizeIdentifier()'s public api.
Now when creating a plugin the casing is preserved from the user input, i.e.

Please let me know if you have any thoughts or comments on this :)

Fixed by #588.


[Test] Add Phi3 via GGUF

Add Phi3 when loaded via GGUF to the test matrix. Do a little renaming of the other Phi3 name for selected_model at the same time.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 62.67%. Comparing base (8caf911) to head (37d4206).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #800      +/-   ##
==========================================
+ Coverage   55.42%   62.67%   +7.24%
==========================================
  Files          55       55
  Lines        4076     4072       -4
==========================================
+ Hits         2259     2552     +293
+ Misses       1817     1520     -297

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add default events object to shallow wrapper simulate

Hey,
I had to pass preventDefault mock lot of times to simulate event in shallow rendering, so I thought it would be nice to have it by default there.
Not sure about the jsdom dependency, is there maybe a better way maybe to create mock event ?
(or maybe have just some mostly used subset of that object there)
Fixes: https://github.com/airbnb/enzyme/issues/277

It failed on old node's because of jsdom not working there :(

I feel like something I would rather see is a mocking event object in enzyme that I can pass to simulate.
Something like this:
wrapper.simulate('click', enzyme.mockEvent);

And that is effectively an object that represents the shape of a typical event.

We definitely cannot rely on browser APIs for shallow.
I would love to see a well built event mocking system built for enzyme that would remove some of the boilerplate, but I hesitate to add something that only implements it half-way - which we would then have to have a potential additional breaking change for in the future.

I'm going to close this in favor of #368 which I think is going more closely in the direction that we want, but I believe will accomplish everything you are wanting.
Thanks!


fix typo on API-reference.md

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot


add a command to check a lock

sometimes you want to check if an environment is locked without
actually stealing the lock. i often want to see if production was
locked by someone, but i can't check without taking the lock myself.

awesome!


Exclude hidden field when unchecked_value: false

Rails does not generate a hidden field for checkboxes if
unchecked_value is false. The nested boolean creates its own hidden
field and ignores this rule from rails. That means that the hidden
field is generated for a falsey value when using the nested style, but
not when using the inline style.
This commit fixes this problem by making the nested style behave like
the inline style, adhering to the standard set by rails.
Resolves: #1320
Note that this may cause problem for people relying in this faulty behavior. But I think it's a good idea to fix this inconsistency in the long run.

Looks good to me. @rafaelfranca, any thoughts?

Hi @fschwahn
Could you rebase your branch with the master branch?

@feliperenan thanks for moving forward with this, I just rebased.


List searchCourse

There are some problems with this function.

What is the searchName, should I use a Fuzzy query?

searchCourseType If a student doesn't have a major, what is the searchCourseType.

Please read the document.
* @param searchName                 search course name. Rule: searchName in "course.name[section.name]"
Major is a must, also read the document.

Sorry, the document is not clear enough.
Should I use a Fuzzy query to search the searchName
I can't understand the search course name. Rule: searchName in "course.name[section.name]"  what is "in" ?

what is "in" ?

a in b = b.contains(a)

如果学生必须有专业，那么当调用 void removeMajor(int majorId); 时，这个专业的所有学生都会被一起删除吗？这不符合常理。


Allow compiling with openMP on macOS

With CC=gcc-XX and a beautiful env variable CONIFEREST_FORCE_OPENMP_ON_MACOS=1

Cross-compilation for ARM doesn't work:
dlopen(/Users/hombit/.virtualenvs/coniferest/lib/python3.11/site-packages/coniferest/calc_paths_sum.cpython-311-darwin.so, 0x0002): tried: '/Users/hombit/.virtualenvs/coniferest/lib/python3.11/site-packages/coniferest/calc_paths_sum.cpython-311-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64')), '/System/Volumes/Preboot/Cryptexes/OS/Users/hombit/.virtualenvs/coniferest/lib/python3.11/site-packages/coniferest/calc_paths_sum.cpython-311-darwin.so' (no such file), '/Users/hombit/.virtualenvs/coniferest/lib/python3.11/site-packages/coniferest/calc_paths_sum.cpython-311-darwin.so' (mach-o file, but is an incompatible architecture (have 'x86_64', need 'arm64'))

I think I fixed everything. Unfortunately it builds binary wheels with OpenMP for everything but macOS ARM64. It looks like it is not currently possible to cross-compile with OpenMP support. However, I give instructions on how to compile it from source on ARM Mac


Password minimum length changed

Codecov Report

Merging #1179 (b756e7b) into master (3a73e95) will increase coverage by 30.03%.
The diff coverage is n/a.

:exclamation: Current head b756e7b differs from pull request most recent head 97a931d. Consider uploading reports for the commit 97a931d to get more accurate results

@@             Coverage Diff             @@
##           master    #1179       +/-   ##
===========================================
+ Coverage   40.92%   70.95%   +30.03%
===========================================
  Files         414      139      -275
  Lines        8988     2248     -6740
  Branches     1532      406     -1126
===========================================
- Hits         3678     1595     -2083
+ Misses       5076      598     -4478
+ Partials      234       55      -179

Impacted Files
Coverage Δ

src/decoder.ts
83.56% <0.00%> (ø)

src/Contract.ts
10.00% <0.00%> (ø)

src/logging/Logger.ts
22.22% <0.00%> (ø)

src/logging/CategoryLogger.ts
43.75% <0.00%> (ø)

src/blockchains/blockchains.ts
51.04% <0.00%> (ø)

src/local-storage/historyStorage.ts
83.33% <0.00%> (ø)

src/workflow/create-tx/CreateErc20Tx.ts
79.38% <0.00%> (ø)

src/create-account/SelectCoins.tsx

src/services/transactions/TxListener.ts

src/common/Balance/Balance.tsx

... and 273 more

Continue to review full report at Codecov.

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

@BOOMER74 can you please fix the conflicts?


Glitch Effect LCS Title

This glitch effect looks pretty good.
https://codepen.io/anatravas/pen/mOyNWR

The LCS title is the text in gradient


[feat] Add support for directories in 'keep_files'

Support directories in the keep_files field of a RegressionTest.

Closes #669
Closes #668

@jenkins-cscs retry daint


Configurable joystick deadzones

When I play with my xbox360 controller I notice a quite severe drift which makes it hard to play the game. Can you please consider adding options for joystick deadzones?

Sorry, looked on your tutorial video and found the option


generic ssh key 'Too many retries waiting for SSH to be available.'

Hi, when I use docker-machine for provisioning a remote host and set a ssh key with --generic-ssh-key ~/.ssh/id_rsa I get the following error Error creating machine: Error detecting OS: Too many retries waiting for SSH to be available.  Last error: Maximum number of retries (60) exceeded. When I don't set the --generic-ssh-key flag it works. I even tried to place the ssh key on another path which didn't work aswell.

Hi,
Does your key has a passphrase? I suspect this to be partly related to #3306. The rest should be fixed with #3330.
But as you noticed, the --generic-ssh-key flag is not necessary in your case because it's the default location anyway.

Ah that's the error. My key is password protected.

@BraunreutherA If you're feeling ambitious, would be good to get you to try a master build (now containing @bamarni's fix) and see if it fixes your issue.

@nathanleclaire did you already consider having nightly builds available? That could help in such situations.

@bamarni We've considered it at various times and even had unofficial ones available but so far haven't set up the infrastructure to support it.  In the future the Docker projects are intended to share more infrastructure to (hopefully) have a common set of interfaces to things like nightlies, but we aren't sure when that will shape up.

cool 👍

I have the same problem with latest master.
$ ~/bin/docker-machine version
docker-machine version 0.7.0, build ae9f392
$ ~/bin/docker-machine create --driver generic --generic-ip-address=<IP_ADDRESS>  node1
Running pre-create checks...
Creating machine...
(node1) No SSH key specified. Assuming an existing key at the default location.
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Error creating machine: Error detecting OS: Too many retries waiting for SSH to be available.  Last error: Maximum number of retries (60) exceeded

It does not work even if I give ssh key explicitly:
$ ~/bin/docker-machine create --driver generic --generic-ip-address=<IP_ADDRESS> --generic-ssh-key=$HOME/.ssh/id_rsa  node3
Running pre-create checks...
Creating machine...
(node3) Importing SSH key...
Waiting for machine to be running, this may take a few minutes...
Detecting operating system of created instance...
Waiting for SSH to be available...
Error creating machine: Error detecting OS: Too many retries waiting for SSH to be available.  Last error: Maximum number of retries (60) exceeded

Okay, now I know what's the problem. docker-machine tried to connect the host with root user but my ssh key has no permission to do that.
It would be nice if docker-machine supports nonroot sudoer.

It already does : --generic-ssh-user :)

@bamarni Thank you for letting me know!

I have no idea why this been solved like this, but I've removed --generic-ssh-user parameter and it started to work )

@holms I solved this by ADDING the --generic-ssh-user parameter 😆

Refer https://github.com/boot2docker/boot2docker/issues/1362#issuecomment-442842774

Refer https://github.com/boot2docker/boot2docker/issues/1362#issuecomment-442842774


Building model body multiple times when calling model_fn() multiple times

Description
I am constructing a meta learning framework on tensor2tensor which requires calling model_fn() multiple times. And I find that the framework will build the model body multiple times, even with reuse=True flag. The pseudocode is as follows:
def model_fn_raw(self, feature): # the origin model_fn
      ...
     tf.print("scope:", tf.get_variable_scope(), "name:", tf.get_variable_scope().name)
     log_info("Building model body")
     body_out = self.body(feature)
      ...

def model_fn(self, feature): # wrap the origin model_fn with meta learning part
     # step1: call model_fn_raw() the first time to compute loss
     with tf.variable_scope(tf.get_variable_scope()):
           _, loss = model_fn_raw(self, feature)
     # step2: meta learning part, update params and assign it to all variables
     updated_para = updated_para_once(loss)
     assign_para_op = tf.assign(tf.trainable_variables(), updated_para)
     with tf.control_dependencies(list(assign_para_op)):
         # step3: call model_fn_raw() the second time to compute loss with new params
         # set the reuse flag as True
          with tf.variable_scope(tf.get_variable_scope(), reuse=True):
               logits, loss = model_fn_raw(self, feature)
     restore_origin_params()
     return logits, loss

In this way, when excuting model_fn(), the model body should be built only once because I set reuse=True at the second time. However the model body is still built twice when I running the code, with printed logs as follows:
INFO:tensorflow:Transforming feature 'targets' with symbol_modality_10152_256.targets_bottom
INFO:tensorflow:Building model body
:::MLPv0.5.0 transformer ...
...(Other logs of model components)
INFO:tensorflow:Transforming body output with symbol_modality_10152_256.top
INFO:tensorflow:Transforming feature 'inputs' with symbol_modality_10152_256.bottom
# (this should be the end. but the same logs are printed again)
INFO:tensorflow:Transforming feature 'targets' with symbol_modality_10152_256.targets_bottom
INFO:tensorflow:Building model body
:::MLPv0.5.0 transformer ...
...
INFO:tensorflow:Transforming body output with symbol_modality_10152_256.top
INFO:tensorflow:Transforming feature 'inputs' with symbol_modality_10152_256.bottom

I also have checked and printed variable_scope in model_fn_raw(). And I find that the scope name in the first and second call is the same, but the address is not.
For example,
# scope address and name printed in the first call
scope: <tensorflow.python.ops.variable_scope.VariableScope object at 0x7fcb13928ba8>
name: transformer/body
# in the second call
scope: <tensorflow.python.ops.variable_scope.VariableScope object at 0x7fcb137747f0>
name: transformer/body

The name is consistent but the address is changed, which means that the variable scope is not the same one in the first and second call.
So I open this issue and hope someone can help me to address this problem. How to construct the model body only once and reuse it in multiple calls? Is it because of the assign ops in step 2 that leads to the multiple constructions?
Environment information
OS: CentOS 7.5

$ pip freeze | grep tensor
tensor2tensor==1.10.0
mesh-tensorflow==0.1.7
tensorboard==1.12.2
tensorflow-gpu==1.12.0

$ python -V
Python 3.6.2

hello, do you have any idea about how to use the MAML in tensor2tensor？


.java files are missing and I stead .class files are pushed

In the LearncollectionFramework folder,  .class files have been pushed instead of .java files.

.java files are there in src folder

Got it


Minimal support for component(1)

Added support for component(1): https://github.com/component

ping @jmas

Hello, I think it is not actualy now.
On 22 March 2015 at 03:22, David da Silva Contín<EMAIL_ADDRESS>wrote:

ping @jmas https://github.com/jmas
--
Reply to this email directly or view it on GitHub
https://github.com/janl/mustache.js/pull/393#issuecomment-84490576.

--
Mobile: +38 099 669 15 06

@jmas, I didn't understand what you mean there. :/

@dasilvacontin Sorry for not informative comment. This "component(1) support" is not actual for me now because I started use another tool. It seems people not interest to use this future. So you can drop this pull request.

You meant useful, right? Okay, I close the PR. Thanks for the follow up!


Expose timelines data.

Request from DAIT.
Test notes

A ⇓ Data button is displayed in the population details container.
The button exports the currently filtered data to .csv with one record per ID per event.

Tested and confirmed new Data button in the population details container downloads csv of data. Passed in all browsers.


Development: Fix grading key issues and example solution repo download button

Checklist
General

[ ] This is a small issue that I tested locally and was confirmed by another developer on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Client

[x] I followed the coding and design guidelines and ensured that the layout is responsive.
[x] Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
[x] I added authorities to all new routes and checked the course groups for displaying navigation elements (links, buttons).
[ ] I added multiple screenshots/screencasts of my UI changes.

Motivation and Context

There were small bugs related to the bugs related to example solution download repo button in course exercises and bonus grading key button in exam summary for instructors.
Description

Fixed route for bonus grading key button in exam summary for instructors.
Matched and highlighted the related grade step if they are numerically equivalent (e.g. '5' and '5.0') in GradingKeyOverviewComponent.
Prevented displaying example solution download repo button in non-programming course exercises.

Steps for Testing

Prerequisites:

1 Instructor
1 Student
1 Text, Modeling or File Upload Exercise
1 Programming Exercise
1 Graded student exam with bonus configuration (e.g. https://artemis-test1.artemis.in.tum.de/course-management/12/exams/50/student-exams/135/summary)

For bonus grading key route fix:

As an instructor, go to the exam summary of graded student exam with bonus configuration and check that View Bonus Grading Key button navigates to the bonus grading key as expected.
Repeat the same steps with a student to ensure it is not broken.

For matching and highlighting the related grade step:

Go to grading key overview of an exam (from exam summary) or course (Statistics tab). You can use the provided student exam above.
Check that the matching grading key is highlighted according to the grade query parameter in the url. E.g., if there is a grade step 1.0 in table, you can try manually typing ?grade=1.0 and ?grade=1 to the url to see both highlights the same grade step.

For preventing displaying example solution download repo button:

As an instructor, set the example solution publication date of a course text, modeling or file upload exercise to a past date.
Navigate to the exercise detail page and check if the Download Solution Repo button is not visible.
As an instructor, set the example solution publication date of a course programming exercise to a past date.
Navigate to the exercise detail page and check if the Download Solution Repo button is visible and repo can be downloaded as expected.

Review Progress

Code Review

[ ] Review 1
[ ] Review 2

Manual Tests

[ ] Test 1
[ ] Test 2

Exam Mode Test

[ ] Test

Test Coverage

Not changed.
Screenshots

Codecov Report

Merging #6114 (a3ab7c3) into develop (74cac91) will increase coverage by 0.00%.
The diff coverage is n/a.

Additional details and impacted files
@@            Coverage Diff             @@
##             develop    #6114   +/-   ##
==========================================
  Coverage      80.05%   80.05%
  Complexity     12780    12780
==========================================
  Files           2206     2206
  Lines          87263    87263
  Branches       13014    13014
==========================================
+ Hits           69859    69860    +1
  Misses          9713     9713
+ Partials        7691     7690    -1

Impacted Files
Coverage Δ

...idebar/conversation-selection-sidebar.component.ts
87.97% <0.00%> (+0.63%)
:arrow_up:

Flag
Coverage Δ

client
76.08% <ø> (+<0.01%)
:arrow_up:

server
84.46% <ø> (ø)

Continue to review full report at Codecov.

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


Fix script loading in sandbox windows

This PR fixes loading script files in sandboxed windows, such as Issue Reporter or Process Explorer.  The sandbox windows use a custom schema (vscode-file vs. file) and need to have this configured when being bootstrapped.
This is for issue https://github.com/microsoft/azuredatastudio/issues/14623.

Pull Request Test Coverage Report for Build 653366865

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.007%) to 43.37%

Totals

Change from base Build 651927353:
0.007%

Covered Lines:
25405

Relevant Lines:
53455

💛  - Coveralls

I'll take a look at that uglyify error in the build.

IIUC, this is just to workaround the issue for the March release. You will need to figure out the actual root cause of the issue later, right?

@alanrenmsft this is the fix for this issue and this is basically the same code that is upstream to support sandbox windows.  I don't have further plans to do anything for this scenario outside the normal vscode merge process.


Move "getting started with CWL" away from Docker focus

Is your feature request related to a problem? Please describe.
Our getting started with CWL guide assumes that the user wants to create a Docker based legacy tool. As we shift our definition of tools, our getting started tutorial is telling people to set up an autobuilding Docker image and then immediately after telling them they shouldn't have done that.
Describe the solution you'd like
Remake the getting started with CWL guide like I did the WDL guide.
Even though I believe the current getting started with CWL guide is no longer fit for purpose as a getting started, it is still perfectly serviceable for Docker-based tools. When I revamped the getting started with WDL guide, I removed the old getting started with WDL stuff completely, but I think there is a good reason to keep the CWL equivalent around (albeit in advanced topics, and with some changed wording to indicate that it is for legacy tools).
Describe alternatives you've considered
Remake the getting started with CWL guide like I did the WDL guide, and do not keep the legacy tools version around.
Additional context
I can attempt to integrate this idea into https://github.com/dockstore/dockstore-documentation/pull/180 because it does fit into the theme of revamping docs r/e github apps, but I am leaning towards doing it in a new PR as that one is monstrously large enough as is, and I want to make sure I give reviewers enough time to look it over.
┆Issue is synchronized with this Jira Story
┆friendlyId: DOCK-2118
┆sprint: S6 - Embarrass, Wisconsin
┆taskType: Story

@bethsheets There would be a lot of things that would fit under that category...
advanced-topics/
--> legacy/
------> legacy-registration-of-tools.rst (currently in dockstore-tools.rst)
------> legacy-registration-of-wfs.rst (currently in dockstore-workflows.rst)
------> services-1.1-template.yml (currently in assets/templates, just never rendered)
------> wdl-tool-tutorial.rst (currently deleted, but could be brought back because git is magic)
...but I'm not quite sure if making an autobuilding Docker-based CWL tool is strictly legacy? You can have an autobuilding Docker image and still use gh-app registration, as far as I'm aware, the resulting entry just won't be connected to your Docker image's tags nor will the Dockerfile be embedded in the Dockstore entry. So, my issue with GSW-CWL as it currently stands isn't that it goes over how to make an autobuilding Docker image, but rather that an autobuilding Docker image is not required for gh-app tools. It's making a new user do extra work unnecessarily, ie, increasing the barrier of entry to writing a CWL tool which is a big deal when you're brand new to CWL like the tutorial assumes. But the process of setting up a quay.io account is not something Dockstore controls nor is it strictly legacy.
@denis-yuen @coverbeck Would love your thoughts on this.

ather that an autobuilding Docker image is not required for gh-app tools. It's making a new user do extra work unnecessarily, ie, increasing the barrier of entry to writing a CWL tool which is a big deal when you're brand new to CWL like the tutorial assumes

Hmmm, several ideas here.
Using Docker is definitely increasing the barrier to writing a CWL tool (or workflow), but it (or something similar to it) is required to make a portable reproducible tool that can be used somewhere else which is kind of our main reason for existing.
That said, our method for registering tools by linking a quay.io account and looking at builds, that method will eventually be legacy after the github apps for tools process rolls out.
Which is a long-winded way of saying that even when github apps for tools is front and center, and some of these legacy approaches are dismantled, I think Docker should be prominent in our documentation and not glossed over. You could introduce the idea of using pre-created containers like biocontainers if one is available as an alternative to making your own Docker container, but I think it is still a worthwhile exercise to learn how to create simple Docker containers to know what is going on.

Although this has already been merged, Denis brings up a good point and I want to revisit it.

(re-opened based on last comment)

@aofarrel
For Dockstore's Intro to **CWL,** we could use a different example to make this a little easier on the end user. Instead of using a Docker container created/maintained by Dockstore (the bamstat tools), we could instead show an example where we reuse a container from Biocontainers. This could signal to the end user that they don't have to make their own container to get started when writing a workflow.


Lag with rust-analyzer indexing

With lsp_status.register_progress() neovim lags on each typed character.
Apparently it's happening due to lots of indexing progress messages from rust-analyzer.
Also the lag is noticeable in process of initial indexing just after rust-analyzer server started inside a project.
The details are here

Thanks for the report! Can you send the relevant snippet(s) of your config?
I suppose we need some sort of rate limiting, though I'm not entirely sure what policy that should use.

Thanks for the report! Can you send the relevant snippet(s) of your config?
I suppose we need some sort of rate limiting, though I'm not entirely sure what policy that should use.

besides regular setup made just as instructed in readme, I have the following lualine config:
local lualine = require('lualine')
lualine.status()

local lsp_status = require('lsp-status');
local lspconfig = require('lspconfig');

lsp_status.register_progress()
local function lsp()
    return require('lsp-status').status()
end
lualine.sections.lualine_c = { lsp }
lualine.theme = 'forest_night'

and rust-analyzer is setup this way:
lspconfig.rust_analyzer.setup({
    capabilities = capabilities,
    on_attach = on_attach,
    settings = {
        ["rust-analyzer"] = {
            cargo = {
                loadOutDirsFromCheck = true,
                allFeatures = true
            },
            procMacro = {
                enable = true
            },
            checkOnSave = {
                command = "clippy"
            },
        }
    },
    root_dir = util.root_pattern('Cargo.lock', '.git'),
})

besides regular setup made just as instructed in readme, I have the following lualine config:
local lualine = require('lualine')
lualine.status()

local lsp_status = require('lsp-status');
local lspconfig = require('lspconfig');

lsp_status.register_progress()
local function lsp()
    return require('lsp-status').status()
end
lualine.sections.lualine_c = { lsp }
lualine.theme = 'forest_night'

and rust-analyzer is setup this way:
lspconfig.rust_analyzer.setup({
    capabilities = capabilities,
    on_attach = on_attach,
    settings = {
        ["rust-analyzer"] = {
            cargo = {
                loadOutDirsFromCheck = true,
                allFeatures = true
            },
            procMacro = {
                enable = true
            },
            checkOnSave = {
                command = "clippy"
            },
        }
    },
    root_dir = util.root_pattern('Cargo.lock', '.git'),
})

I'm wondering if this has to do with how often lualine evaluates the lsp component. I haven't been able to reproduce the issue yet, but - looking through status, diagnostics, and messages, I'm not sure where redundant work can be avoided. Those functions mostly just look through a table filled by a callback when message events come in. It's possible that the implementation could be optimized (e.g. table.insert is used a lot and could be replaced, there are a few places where maybe we could skip some loops?), but I'm surprised that this would cause so severe an error if the component isn't being invoked too often.
Another alternative (and maybe the best option) would be to change the plugin to generate a statusline string on a fixed frequency, then make status query this string. I'm not likely to get to this work anytime soon, but I'd happily review a PR for it.
Also, if you have a public repo I could use to reproduce this issue, that would be very helpful.

@wbthomason thank you for investigating it.
As mentioned by @kid in https://github.com/neovim/nvim-lspconfig/issues/395 the issue also happens with vim-airline.
Furthermore until I switched to neovim lsp I've been using vim-airline + coc, rust-analyzer status messages were smooth back then thank to throttling implemented in coc I suppose.
I've managed to create a minimal reproducer.
It requires cargo and rust-analyzer available in $PATH, starting command is in readme.

Beautiful, thanks for the repo to reproduce the issue. I'll give it a go as soon as I have a chance.

I also get a little bit of lag for a moment each time right after I save, although that goes away quickly each time and doesn't come back until I save again. I'm using lightline.vim.

Sorry, I still have not had time to look into this in depth. I tried to reproduce it using @onsails's minimal repro setup, but can't - I don't see any lag.
At a guess, this is just happening because we update the statusline on every new message, and some statuslines take a long time to draw. It looks like coc-rust-analyzer does eager updates too (https://github.com/fannheyward/coc-rust-analyzer/blob/ead54f58cef1275263fcf6a7281ce14a472c29ea/src/ctx.ts#L59-L60), so there must be something happening in coc.nvim's StatusBarItem type (or somewhere related) to avoid updating so frequently.
If anyone wants to take a stab at a PR for this, I'd be happy to help guide things from the lsp-status end. I would suggest looking at coc's StatusBarItem code and replicating any debounce logic here.

@wbthomason thank you for investigating it.
As mentioned by @kid in neovim/nvim-lspconfig#395 the issue also happens with vim-airline.
Furthermore until I switched to neovim lsp I've been using vim-airline + coc, rust-analyzer status messages were smooth back then thanks to throttling/debounce implemented in coc I suppose.
I've managed to create a minimal reproducer.
It requires cargo and rust-analyzer available in $PATH, starting command is in readme.
You can notice that the spinning rectangle is freezing and if you hold down l key for example you will notice it's lagging.

I had the lag before, but can not reproduce it with this test.
I want to propose an optimization. Instead of calculating the statusline text in statusline.status() we calculate it in the lsp_handler and set a buffer variable with the result of statusline.lsp_status(). When we need to redraw the statusline we just return this variable. Also, I added a variable to check if we need to render the new statusline only if the text changed.
I created a draft PR  with the changes #42 if you can please test if it improves the performances.

I'm not the original reporter, but I just wanted to chime in and say I tested your branch @joshuachp, and it does seem to solve the problem for me. I'll keep using it and see if that holds true long-term.

I'm not the original reporter, but I just wanted to chime in and say I tested your branch @joshuachp, and it does seem to solve the problem for me. I'll keep using it and see if that holds true long-term.
Edit: Unfortunately, after using it a bit more, I'm still seeing the same lag

Thanks for testing, I think that in the case of rust-analyzer we are hitting a limitation of neovim if we redraw every update it will always lag no matter what. I will try to limit the number of redraws with next commit.

Closed by #43 and #45


Missing xml files deps!

If there arent present on purpose we should at least document where they can find them!
Start setup...
Setup done! 2.037533760070801s
Importing companion spec. XML...
[Errno 2] No such file or directory: 'c:\\Users\\HeineAn\\Downloads\\Sample-Server-asyncio-develop\\Sample-Server-asyncio-develop\\deps\\UA-Nodeset\\DI\\Opc.Ua.Di.NodeSet2.xml'
Traceback (most recent call last):
  File "c:/Users/HeineAn/Downloads/Sample-Server-asyncio-develop/Sample-Server-asyncio-develop/src/server.py", line 233, in <module>
    asyncio.run(main())
  File "C:\Users\HeineAn\AppData\Local\Programs\Python\Python37-32\lib\asyncio\runners.py", line 43, in run
    return loop.run_until_complete(main)
  File "C:\Users\HeineAn\AppData\Local\Programs\Python\Python37-32\lib\asyncio\base_events.py", line 584, in run_until_complete
    return future.result()
  File "c:/Users/HeineAn/Downloads/Sample-Server-asyncio-develop/Sample-Server-asyncio-develop/src/server.py", line 65, in main
    di_idx = await server.get_namespace_index("http://opcfoundation.org/UA/DI/")
  File "C:\Users\HeineAn\AppData\Local\Programs\Python\Python37-32\lib\site-packages\asyncua\server\server.py", line 471, in get_namespace_index
    return uries.index(uri)
ValueError: 'http://opcfoundation.org/UA/DI/' is not in list

Is this the lastest develop? I introduce an error with #22 but fixed it with #26 .


Both roles and collections should not be required in the requirements.yaml file

Either or both collections and roles are valid in the requirements file.
https://docs.ansible.com/ansible/latest/galaxy/user_guide.html
RequiementsV2Model is missing an r.

Was fixed in #165. Thanks again RandyLevensalor for your contribution! :)


Adding Dynamic Linking to File and Line Number

I'm curious how difficult would it be to make the report dynamically link to the TODO (or other), to their file and line number? Sublime's Find report does this pretty well and I have seen other packages do it so I'm curious if its an easy addition that would be a great feature to have :)

This is currently tracked in #78 (which is a PR and probably why you didn't see it).


[PyTorch] Fix semantic segmentation normalization

Mirror changes from https://github.com/d2l-ai/d2l-en/pull/1980.

Job d2l-zh/PR-1031/1 is complete.
Check the results at http://preview.d2l.ai/d2l-zh/PR-1031/


Enable Link-Time Optimization (LTO)

Hi!
I noticed that in the Cargo.toml file Link-Time Optimization (LTO) for the project is not enabled. I suggest switching it on since it will reduce the binary size (always a good thing to have) and will likely improve the application's performance a bit. If you want to read a bit more about LTO, I can recommend starting from this Rustc documentation.
I suggest enabling LTO only for the Release builds so as not to sacrifice the developers' experience while working on the project since LTO consumes an additional amount of time to finish the compilation routine. If you think that a regular Release build should not be affected by such a change as well, then I suggest adding an additional dist or release-lto profile where in addition to regular release optimizations LTO will also be added. Such a change simplifies life for maintainers and others interested in the project persons who want to build the most performant version of the application. Using ThinLTO should also help to reduce the build-time overhead with LTO. If we enable it on the Cargo profile level, users, who install the application with cargo install will get the LTO-optimized version "automatically". E.g., check cargo-outdated Release profile.
Basically, it can be enabled with the following lines:
[profile.release]
<other options>
lto = true

I have made quick tests (Fedora 41, Rustc 1.83) by adding lto = true to the Release profile. The binary size reduction is from 5.9 Mib to 4.9 Mib.
Thank you.

Hi, thank you for letting me know about this, honestly I had no idea, I'm still learning more about cargo as well as rust so this helps a lot. I'll check that out and add it on next release.
Have a good day


When compiled with master branch, SyntaxError: Unexpected token var

I run into a strange problem, when I try to compile with my fork (or main repository) on master branch, I don't get compile error but after uploaded my script screeps report SyntaxError: Unexpected token var on (formated code)
$1 = Module.STDWEB_PRIVATE.to_js($1);
$2 = Module.STDWEB_PRIVATE.to_js($2);
$3 = Module.STDWEB_PRIVATE.to_js($3);
Module.STDWEB_PRIVATE.from_js($0, (function() {
    return var body = (($1)).map(__part_num_to_str);
    return ($2).spawnCreep(body, ($3));;
})());

After some investigation, it's look like https://github.com/daboross/screeps-in-rust-via-wasm/commit/e7be1e65955f4d50b656c2d60848312c572ed664#diff-787e8a3cc9552b2bba8c81654731a887R21 change some js thing and didn't expect this new error. It's work fine on the parent of this commit and don't work with this new commit.
As a total noob in js I don't really know how to fix this.

#92 Well...

Thanks for reporting this! As you saw I ran into a similar issue after updating my AI to the latest master branch. Should be fixed as soon as that code is merged.

Should be fixed as of https://github.com/daboross/screeps-in-rust-via-wasm/commit/788cf9231ec5eec14bfa391ae2bf879d1ea5fe33.
As far as I know this bug was never part of one of the crates.io releases of screeps-game-api, so I won't make a hotfix release for it.
Still, it should be fixed in master. Let me know if it still occurs.


Godot steam rolls the entire project when saving if your hard drive is full

Tested versions
Reproductible in 4.3.stable and I'm assuming at least every other version of Godot 4. Probably 3 as well.
System information
Godot v4.3.stable (77dcf97d8) - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 (NVIDIA; <IP_ADDRESS>03) - Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz (6 Threads)
Issue description
Occurred in version 4.3.stable. I'm assuming this is also the case for all other Godot versions but I haven't tested. So I don't know exactly what caused this, but the drive my Godot folder of the project I have been working on for almost a year was full (Steam was downloading an update for a game), but then godot tried to save the project while the drive was full- it then proceeded to crash. When I reopened it, I noticed that every single tscn and gdshader file had a file size of zero. Godot somehow erased all the contents of all gdshader and tscn files.
Side note: I feel like this could be fixed by when attempting to save a file, first make a copy, verify that the copy saved correctly, if it did then override the original, if that saves correctly then you can remove a copy. This would make it impossible for any file to become corrupt while attempting to save. Sorry if this isn't very coherent, I just lost almost a year of work, mostly my fault for not making a backup, but still.
Steps to reproduce

Install satisfactory update with 4 gigabytes of free space
When your drive has 0 bytes free, press f5
Cry

Minimal reproduction project (MRP)
Any project

See also:

https://github.com/godotengine/godot/issues/45354

Notably, even files that shouldn't have been saved, like the shaders which weren't even open at the time, were wiped

Side note: I feel like this could be fixed by when attempting to save a file, first make a copy, verify that the copy saved correctly, if it did then override the original, if that saves correctly then you can remove a copy.

This should be already happening and it's called "safe save". Sometimes it can fail when file is read-only and you are left with tmp files in your project; the original file is untouched.

The problem is that the safe save won't help if the engine doesn't detect that the file system is full, unless it does correctly detect failure and stops writing back

Shouldn't it fail at OS level though? In that case Godot would be able to handle it. Do apps normally account for full disk space?

I don't expect that would or should fail, it renames one file onto another I think, that should reduce the amount of data on the drive

No, but the safe save first writes a file and if writing fails, stops the operation; otherwise it renames it over old file. If that doesn't prevent errors, it means you can write the file with no enough space, in which case I assume it overwrites any files randomly.

That is the assumption yes, but unsure exactly how the detection works, and when things go wrong
It's possible that the OS causes issues due to temporary storage in memory before writing back etc.
Haven't dug into the small details here, and could be due to various issues with the detection and writing multiple files
Theoretically one part of the operation could fail because space ran out at a critical point etc.
Also depends on how the rename itself works, it might be the OS doesn't recover gracefully etc.

Not sure how the detection would work but the closing operation of FileAccess on windows doesn't check if any errors occured, so I'm not sure how this would recover assuming the file creation succeeded and then writing to the temporary file failed
So as long as the temporary file was created, any error writing to it meanwhile doesn't seem to matter, and the empty temporary file just overwrites the original
I might be missing something in the code but I don't see anything that would prevent this scenario

Windows can create mountable vhd from the partition manager and Linux can do anything with ramdrives etc, so there's no reason why we can't test this problem.

Who said we couldn't test it? This discussion is relevant to pinpointing what the issue is specifically and the point of failure, and specifically that the safe save system isn't necessarily guaranteed to avoid this depending on what the low level operations are doing, which is something to test

Thanks for the report! Consolidating in https://github.com/godotengine/godot/issues/45354, as this is due to the same cause.

Notably, even files that shouldn't have been saved, like the shaders which weren't even open at the time, were wiped

Godot likely attempted to save these files anyway, even if it's only to change their modification date. This will happen especially if you had shaders opened in the shader editor bottom panel, even if the bottom panel is currently collapsed.
There's an issue tracking this for project.godot in particular, but I can't find it right now.


Needle Parity

Needels Parity

Needels are missing Faster Inject speed if you have Medskill 2.
Broken Needles
And probably more
Additional context
We still have upstream needles.

Dupe of #3978


Add cryptor

What this PR does / why we need it:
Add cryptor for encrypt and decrypt for dolphin
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

How to use:

Config the encryption algorithm

[DEFAULT]
dolphin_cryptor = des

Encryption and decryption

from dolphin.cryptor.factory import CryptorFactory

plain_text = 'This is plain text'

myCryptor = CryptorFactory.get(CONF.dolphin_cryptor)
encrypted_text = myCryptor.encode(plain_text)
decrypted_text = myCryptor.decode(encrypted_text)

Can u accommodate example/section about usage of this by other modules

Few doubts:
a) Why are we trying to put AES and DES? Are we going to use both?
b) Why not simply use AES 256 with Symmetric key and IV? In your code you are using the same key everytime so IV is required to make it not getting re-used

Can u accommodate example/section about usage of this by other modules

A example has been put in release note

Few doubts:
a) Why are we trying to put AES and DES? Are we going to use both?
b) Why not simply use AES 256 with Symmetric key and IV? In your code you are using the same key everytime so IV is required to make it not getting re-used

Actually I haven't dived too much into which encryption algorithm is most suitable for us, I just choose three most common encrytion algorithm to make an example about how to add a encryption algorithm to encryptor factory.


Anyone active?

Seems like a day commit, and no activity? Interesting

hey so i got this to work pretty easily but it took majority of my solana ... lol luckily i was only testing with a small amount.

error was "provider owner is not allowed" on chain

@daralect
hey so i got this to work pretty easily but it took majority of my solana ... lol luckily i was only testing with a small amount.
What do you mean by it took majority of my solana?
error was "provider owner is not allowed" on chain
That's because the readme says it, this bot spams transactions.
When you spam 100 transactions, if one succeeds, the other transactions will show provided owner is not allowed as you already created the associated token account.
Buy Tx is composed of:

ata creation
buy ix
compute budget limit
compute budget price from the array

Sell Tx is composed of:

sell ix
close ata
compute budget limit
compute budget price from the array


Advanced Regular Expressions

Using XRegExp allows for more powerful regular expressions. It compiles advanced regular expressions down to normal javascript regular expressions. All existing regular expressions are compatible.
XRegExp provides the following features:

Adds new regex and replacement text syntax, including comprehensive support for named capture.
Adds new regex flags: s, to make dot match all characters; x, for free-spacing and line comments; n, for explicit capture mode; and A, for astral mode (full 21-bit Unicode matching).
Provides a suite of functions that make complex regex processing easier.
Fixes or helps you avoid the most commonly encountered cross-browser inconsistencies in regex behavior and syntax.
Supports addons that add even more new regex syntax, flags, and methods. Offical addons support Unicode, recursive matching, and grammatical patterns.

(Taken from website)
Currently, using XRegExp is tedious.
var regexp = XRegExp(String.raw`
    (\d)+
`, "xi")

It could be better if
var regexp = /
    (\d)+
/xi

compiled to
var regex = XRegExp(String.raw`
    (\d)+
`, "xi")

if a compiler flag was enabled.

It should be possible to compile the XRegExp regular expression a to a normal javascript regular expression with a xregexp property added for named captures.

Working on pull request

@2426021684 I just want to mention that I don't think we'd be willing to take that PR. We haven't actually discussed the issue, and this is extremely tied to a single library.
Additionally, this is an extension of expression level syntax, and we are strongly conservative on those changes unless it is tied to a promising ECMAScript proposal that looks like it will be ratified into the standard.

Would
var regexp = /
    (\d)+
/xi

compiling to
var regexp = new RegExp("(\d)+", "i")

using the XRegExp library at compile time instead of at runtime be better? Then XRegExp would only be needed at runtime if the regexp contained named captures.

I don't think that would be better. In general, we've been pretty lax about our regular expression parsing because there are various extensions that might exist, so we're fairly hands-off about it. We don't try to report errors if your regular expression is malformatted, and detecting various extensions is in the same league of complexity.
If XRegExps are so tedious, why not make a helper function?
function xregexp(t: TemplateStringsArray, ...args[]) {
    let result = t.raw[0];
    for (let i = 1; i < args.length; i++) {
        result += t.raw[i];
        result += args[i];
    }
    return XRegExp(result);
}

Ok


[Android] Read ext env config files even when specific flavor name isn't given

Hi,
I realized if a specific flavor name isn't passed in gradle command like 'gradle assemble', the env file entered in envConfigFiles is not read for the corresponding flavor. In contrary, I think it would be more appropriate that in each tasks within the default task must read the correspondent env file. So in 'gradle assemble' case, the correspondent file (specified in envConfigFilesMap) should be read before 'assembleDebug' task is run, likewise the accurate file should be read just before running 'assembleRelease' task.
To solve that, in this PR, I am adding a new task to read the accurate env files just before preparing the specific flavor task's dependencies. I look forward your comments.

I think this would solve my issue where I have multiple product flavors that are being created, but they aren't using the .env defined in envConfigFiles. They all just use the default .env

Tested, and now using this commit, my one comment would be that I'd prefer it to use the react.gradle method (seems safer, cleaner), but regardless, this commit helpful :)

Not sure why this wasn't merged in before. I created my own pull request to address the exact same thing @cenkakin https://github.com/luggit/react-native-config/pull/180

:+1:! Sorry for dropping the ball, this should be working in the latest thanks to #180 and others.


fix: use @_cdecl rathar than @_silgen_name

fixes #24

I don't know why, but Swift 6.0 snapshot toolchain cannot build dc22783428825e28bef124e7116c2337debadb82. So I'm going to revert #15.
$ make run
swift build --triple aarch64-none-none-elf -c release -Xswiftc -Osize --experimental-lto-mode=full -Xswiftc -experimental-hermetic-seal-at-link
Building for production...
[6/8] Compiling Kernel kernel.swift
make: *** [Makefile:24: swift] Error 1
$ swift build --triple aarch64-none-none-elf -c release
Building for production...
[2/4] Compiling Kernel kernel.swift
(swift crashes here silently)


Conflict with bootstrap 3

With bootstrap.css, something on cell/header size calculating is wrong. So the cells of the same column of different rows are not aligned with the header.
Everything is back to normal after remove bootstrap. But our layout is totally based on bootstrap. So please help.

is this fix in the latest version of slickgrid?  or would i need to apply one of the recommended fixes above?

I'll look at this and try to apply a patch soon. That said, I'm using bootstrap and haven't noticed enough of a problem for it to even register with me. However it's worth noting:

the behaviour of jQuery changed around 1.8 so the solution will depend on the version you're using. The master is at 1.7 and the alternate at 1.11.
this is definitely related to the css 'border-box' setting, which bootstrap uses
the two approaches are to
(a) turn border-box off for the slickgrid elements (he simplest approach), or
(b) modify the slickgrid code/css to use border-box, but this would have to be tested under both jQuery versions

... to answer the question, currently this has not been patched on either master

A patch for this issue has been added to the 'alternative master' repo. It should fix all cases.
Repo: https://github.com/6pac/SlickGrid
Latest release: https://github.com/6pac/SlickGrid/releases
Blog post: http://low-bandwidth.blogspot.com.au/2015/06/slickgrid-with-jqueryui-and-bootstrap.html
The latest release has added examples for Bootstrap and the jQueryUI Accordion that may help provide a standardised page for testing, and demonstrate a known good configuration.

I have to still enable the following slick.grid.css after getting the patch from @6pac  in order to work in firefox the first grid loads .. it was misaligned
/box-sizing: content-box !important;/
to
box-sizing: content-box !important;
But enabling it fixed the issue

I had same issue on Firefox, It was fixed by adding below code in my CSS.
.slickgrid,
  .slickgrid *,
  .slick-header-column {

          box-sizing: content-box;
          -moz-box-sizing: content-box;
          -webkit-box-sizing: content-box;
          -ms-box-sizing: content-box;

  }

the patches to my repo should handle either 'border-box' or 'content-box', through the mechanism of jQuery 1.8+ which should handle them correctly.
It does appear that Firefox has an issue, however it appears to be something different again.
as such I'm leaving things as-is, and the above patches should be considered the official Firefox solution.


VX_AMD_MIGRAPHX - missign pre-req for Ubuntu22

@kiritigowda can you add this to the setup script? Needed to run migraphx on Ubuntu22, which needs -lcrypto. QA had some issues with running the tests and this fixed it
sudo apt install libssl-dev

addressed with #1410


Update efls-train docs

Update efls-train docs

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


OpenAPI shared components

Question
How to union generated shared components from two different openapi sepcifications?

I'm trying to understand whether this is essentially a duplicate of https://github.com/apple/swift-openapi-generator/issues/132 or if that doesn't work for you for some reason.

No its not a duplicate. Its a different issue, that one not related.
So I have two apis described in openapi yaml: A -> which have some shared components S, and B which uses the same shared components S. I generate two libraries from the yamls and of course there are two duplicate types now AS and BS.

So I have two apis described in openapi yaml: A -> which have some shared components S, and B which uses the same shared components S. I generate two libraries from the yamls and of course there are two duplicate types now AS and BS.

I'm not sure I understand.
If by "two apis" you mean you have two operations in the OpenAPI document that make use of the same type in #/components/schemas, then these will use the same type. Or are you saying you two independent services in the one YAML file?
Would you be able to provide a minimal example to help us understand better?

I’m facing a similar issue and would appreciate some guidance.
We have two separate JSON files, each defining the same "User" component. These components are currently in different modules but represent the same entity. I'm looking for a way to unify them, so I can use just one.
For example:
- Module Address:
public typealias User = Components.Schemas.User // from Address module OpenAPI file
- Module Car:
public typealias User = Components.Schemas.User // from Car module OpenAPI file
However, in my code, I can’t do the following:
func test(_user: Address.User) {      var user: Car.User = _user // error }

We have two separate JSON files, each defining the same "User" component. These components are currently in different modules but represent the same entity. I'm looking for a way to unify them, so I can use just one.

@Inshaki the types generated in different modules are distinct, and there's no way to unify them.
Can you confirm if these are separated into separate files because they are separate services or just because you want to spread the definition of your single API service across multiple files.
If it's the former, you'll need to restructure to separate the shared types into their own OpenAPI doc, generate in their own shared target, and use additionalImports: in the config file of the two downstream targets.
If it's the latter, then Swift OpenAPI Generator only supports a single openapi.yaml or openapi.json for each target and it's expected that this contain the entire API, so you could explore some preprocessing to merge this into one OpenAPI document that defines your service.

For example:
- Module Address: public typealias User = Components.Schemas.User // from Address module OpenAPI file
- Module Car: public typealias User = Components.Schemas.User // from Car module OpenAPI file
However, in my code, I can’t do the following: func test(_user: Address.User) { var user: Car.User = _user // error }

I can't really tell which of these it is from this example. Do you have a CarAPI and an AddressAPI (probably not), or do you have a single API that makes use of cars and addresses, that both have users?
(Just a logistical note here that I'm about to head out for a long weekend so you might not hear from me until Tuesday).

The CarModule and AddressModule are indeed separate modules (within the same backend though), each with its own set of APIs. However, they share some common models like User. While creating a shared OpenAPI document seems like a solid approach, we prefer not to modify the existing JSON files directly.
Given this, would it be possible to set up the shared components without altering the original JSON files? If so, how would you recommend structuring this?
Any further guidance would be greatly appreciated.

If the set of OpenAPI document JSON files you have to hand constitute the API definition of a single backend, then you will need to preprocess them as input to Swift OpenAPI Generator since it only supports a single OpenAPI document as input, named either openapi.yaml or openapi.json.
You will likely need to use another tool for this as part of your build pipeline, e.g. jq.

I suspect this would also be helped by #25, as it'd allow actually generating a single copy of the shared types, and they'd be referenced from both modules.


Is re-exporting tokio::main really useful?

You cannot use the hyper::rt::main attribute macro as it is without depending on tokio crate, so the re-export is not quite useful as a shorthand. I fear that it could be rather a source of confusion.

Very good point, I hadn't considered that, and just noticed that it worked in the examples, but that's because there's already tokio in the dev-dependencies. We should remove it for now.


VSCode caught Desync today, but missed it yesterday

Product and Version [VS/VSCode]:
VSCode 1.47.1 on both sides
OS Version [macOS/Windows/Linux]:
Win10Home build <IP_ADDRESS>2 on host, Win7HPSP1 on Participant
Live Share Extension Version:
1.0.2427 on both
Target Platform or Language [e.g. Node.js]:
Node.js / TS / Preact / Python
What were you doing when you encountered the desync?
Today it was detected a couple minutes after joining the session. The host was editing a .tsx file.
Yesterday, though, the desync occurred after we had been collaborating for approx 4 hours. (Typically, we will collab for 7+ hours/day). [UPDATED] On the Host side a file was moved between folders while it still showed as open on the Participant's side (we didn't notice this at the time). On the Host side, the file appeared to have been moved, but several minutes later it re-appeared in its old location.
Re connectivity issues, we did not notice any connectivity issues yesterday (we usually have a zoom session running concurrently, and occasionally (once/month) zoom will briefly report a connectivity issue).
Note that yesterday's desync wasn't detected by VSCode, but we noticed (while editing an .scss file) that css property "padding" was misspelled as "paddingg" on the Participant-side, but correct on the host. When Participant corrected his side, the host side was "paddin". This went back and forth a few times until we realized what was going on. The Participant rebooted his computer and rejoined the LiveShare session, but this did not fix the problem. The host then closed the LiveShare session and restarted it, and that fixed it.
How often have you encountered desyncs?
Today is Thurs. We just discovered and started using this extension only a few days ago on Monday. Our first real sync problem was the one yesterday. Since starting using the extension, however, we noticed that odd things happen if we are too quick to start LiveShare after starting VSCode.
We have around 11 git repos for this project, and we half-suspect that the problem could be related to not waiting long enough (for all git repos to FULLY sync/load) before starting the LiveShare (just a guess?). However, today the host had been coding in VSCode for an hour before starting the LiveShare, and the Participant had started VSCode a few minutes before connecting to the LiveShare.
We are both working remote (C19-era), both using residential ADSL internet (ISP ==  Telus), located approx 20miles apart (Nanaimo, BC, Canada region)
GREAT extension -- wish we had known about it even earlier.
Extensions in use:
PARTICIPANT:
C:\Users___>code --list-extensions --show-versions
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>HOST:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>

Thanks very much for the thorough report. I know how frustrating this issue can be. It's one of our top priorities to resolve at the moment, so reports like this are much appreciated, especially since the issue is hard to pin down.
Unfortunately, I don't think we'll have it entirely resolved in the next couple of days or weeks. Would you please keep us up-to-date with your experience? I'll post back on this thread as we make progress and you can let us know if it's seemed to improve your experience.
Things that seem to be correlated to desyncs: long running sessions, file operations (deletes/renames), connectivity issues. Let us know if you find you get out of sync outside of these situations.

Same day as left initial comment. Approx one hour into our shared sesson. No file renames/moves/deletions. No connectivity issues. Three files open (2 x .tsx and 1 .scss) After Participant worked on one of the .TSX and the .SCSS for approx 40 mins, Host wanted to commit changes to git, but noticed that his Source Control panel was now blank. We disconnected the LiveShare, and Host was obliged to re-start VSCode for the Source Control panel to return. Commit then proceeded without incident.
Note at our git repos are hosted on our webhost, not on github.

Interesting! Any chance you can get a repro for the issue?

Sorry to be obtuse, but unsure your meaning. Suspect repro is repo, but what do you mean about getting a repo for the issue?

He meant reproduce I think

Thanks Selim - sure, we'll try to reproduce the error early next week.

Thanks @gibberishbc ! What I'm looking for is a detailed list of steps that anyone could follow to reproduce the problem - it makes it much easier to fix.
However, that's asking for a lot :).
I'm working on adding more diagnostic logging so that next time you do run into the issue, your logs would be able to let us know what happened. I'll let you know when those changes go in.

Hey all, we just updated the extension with some more diagnostic capabilities. If you encounter a sync issue again, could you do me a huge favor and go through the following steps?
On both the host and the guest:

Enable the liveshare.diagnosticMode setting
Open the file that's out of sync
Run the liveshare.getCoeditingInformation command (ctrl+shift+p to open the command palette, then search for "Get co-editing information") and paste the results below

To check that messages are being sent and received, open the Output view (ctrl+shift+u) and select "Visual Studio Live Share Coediting" from the dropdown. Type a character. On the sending end, you should see output like:
[2020-12-10 23:51:25.351 ] Post message: {"messageType":"textChange","changes":[{"length":0,"newText":"a","start":400}],"changeServerVersion":12,"clientId":24,"fileName":"/src/foo.txt","time":1607644285349,"sendId":16}
On the receiving end, you should see output like:
[2020-12-10 23:51:27.713 ] Receive message: {"context":{"GuestSessionId":"31","IsOwner":"False"},"sourceId":"Coauthoring","eventId":45,"jsonContent":"{"messageType":"textChange","changes":[{"length":0,"newText":"a","start":400}],"changeServerVersion":12,"clientId":24,"fileName":"/src/foo.txt","time":1607644427514,"sendId":25}","time":1607644427713}
Are messages being sent and received?

Hey @cssyphus , are you still continuing to experience issues? We've done a number of fixes in the last few months, and I hope we've fixed your problem. If we haven't could you please chime in on the relevant issue from this list?
https://github.com/MicrosoftDocs/live-share/issues/4260
Or if it's not in the list, file a new issue. Thanks!


Lag behaviour while dragging quickly

I just pondered around with vue-grid-layout and react-grid-layout library and it feels like there is a lag when try and drag the grid box quickly as compared to react version where the box always stays in sync with the pointer and feels more quick.
Is it because of performance or because of some animation lag we are using in vue-grid-layout ?
Here is the react version: https://strml.github.io/react-grid-layout/examples/0-showcase.html

probably related to #37 and #61

Easy fix:
  .vue-resizable.resizing { pointer-events: none; }

I have found that the following styles greatly increase performance:
  .vue-grid-item.cssTransforms { transition-property: inherit !important; }
  .vue-resizable.resizing { pointer-events: none; }
  .vue-draggable-dragging { pointer-events: none; }

@joshmn It's great. Also I think this one is good too from @ThePlastic  as it preserves some transition .vue-grid-item.vue-draggable-dragging { transition:none; z-index: 3; } . Cheers 💯


[Enhancement] Optimize ORC writer performance for decimal types

Why I'm doing:
The original implementation of orc::Decimal::compare is time-consuming.
What I'm doing:
Rewrite.
What type of PR is this:

[ ] BugFix
[ ] Feature
[x] Enhancement
[ ] Refactor
[ ] UT
[ ] Doc
[ ] Tool

Does this PR entail a change in behavior?

[ ] Yes, this PR will result in a change in behavior.
[x] No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

[ ] Interface/UI changes: syntax, type conversion, expression evaluation, display information
[ ] Parameter changes: default values, similar parameters but with different default values
[ ] Policy changes: use new policy to replace old one, functionality automatically enabled
[ ] Feature removed
[ ] Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

[x] I have added test cases for my bug fix or my new feature
[ ] This pr needs user documentation (for new or modified features or behaviors)

[ ] I have added documentation for my new feature or new function

[ ] This is a backport pr

Bugfix cherry-pick branch check:

[x] I have checked the version labels which the pr will be auto-backported to the target branch

[ ] 3.2
[ ] 3.1
[ ] 3.0
[ ] 2.5

do you have any micro benchmark data to prove it's better?

do you have any micro benchmark data to prove it's better?

updated in the description.


Add Marketo Tracking Script

Script written by consultants to help tracking in Marketo. The code generates field values pulled in by Marketo.

LGTM! Thanks!


Bug: Game Crash with Class Selection

When I teleported with a class assigned the class was gone on the account after teleporting and then it crashed opening it and then the other accounts (4 instances 2 clients) could assign a class once use it and then crash after trying to assign another class or log in again and assign a class from the base. Currently I made 5 accounts and at least 4 are soft locked / crash when pressing J to bring up class assign with at least 2 clients open. I am not sure if the teleporter messed up the data being saved and then behind the scenes it messes up other accounts or what is going on but its a game crashing bug that should be fixed. Please ask questions and feedback is welcome.

Thanks for reporting this bug. I think I've encountered it myself. I will have a look at it once I tackle the class system in the web port effort I am currently doing.

Oh wow there's a web port tooo? I read the wiki stuff it said webstuff hard because of some technical difficulties but it must been older. Hey is it hard to add animations for melee, ranged (bow), throw and cast or is it like copy and paste the attack animation, add new animation spites but it lots of work need to fix bigger things first but it could be done later when other important things are good kind of thing? Also how can / how reasonable is it add more armour / sprite equipment layers (head, chest, legs, shoulder, hands, feet, wrist, waist, back, shirt, pants, tabard, neck, fingers, accessories etc.? It is 2D so the art is easier than 3D / 2.5D so I was hoping to levelerage the 2D stuff to add lots of depths cus 3D slows it all down but 2D is fast and fun lol. You got an AMAZING job so far but I'm soooo curious how to make it really good like WoW but better cus its 2D so the art is easier than 3D. Also talent / skill trees and hey this really nice person says it okay to use his cool plugins for cool RPG features like diablo style inventory and there is crafting and cool loot lol. https://github.com/don-tnowe/godot-wyvernbox-inventory/issues/32#issuecomment-1925683965 Also the owner / head / lead developer of the Inventory System (feels like Minecraft) hearted this little comment so like there seems to be really good will in the community for things to go well:-D. https://github.com/expressobits/inventory-system/issues/104


Can it work with zygisk module imgui on emulator  i try it crash

my code some like this
void *hack_thread(void *arg) {
    do {
        sleep(1);
        g_il2cppBaseMap = KittyMemory::getLibraryBaseMap("libil2cpp.so");
    } while (!g_il2cppBaseMap.isValid());
    LOGI("il2cpp base: %p", (void*)(g_il2cppBaseMap.startAddress));

    BNM::Loading::AllowedLateInitHook();
    BNM::Loading::TryLoadByDlfcnHandle((void*)g_il2cppBaseMap.startAddress);
    BNM::Loading::AddOnLoadedEvent(MyHook);
}

Read this and then this and after that ask questions if you still can't understand.

please post the solution if you can

please post the solution if you can

Examples already contains solution.

you can try get java vms by making pointer to JNI_GetCreatedJavaVMS and call JNI_OnLoad


Improvements for ContentWorker methods and view-entities (OFBIZ-12829)

Improved: Adds additional methods to ContentWorker for finding content with alternate locales and changes view-entities for content to better include associated content of different locales. (OFBIZ-12829)

Looks good to me, any objections to merge?


add wechat pay

add wechat pay

@yorkie , I Have already submitted.

All changes looks good to me, and I will keep this still open for 48 hours, and will merge and release if there are no any objection :)


[ExtID User Insights] add conditional access workbook template

Deploy button:

Check this last chart

@Kingjuli that requires an item in the previous table to be clicked in order to set the correlation id.
Here's how it looks when clicked:


Feature Request : Allow specific commands to run so that we can define what metrics to be fetched

Hi,
This works great, thank you for providing this here,
One feature i think which would help is to allow specific commands to run on AOS so that we have more control on what metrics are exported

Can you provide examples of what you're looking for?
It does run specific commands, for example for interface stats on a non-CX switch...
https://github.com/slashdoom/aruba_exporter/blob/main/interfaces/interface_collector.go#L115
it runs both "show interfaces ethernet all" and "display interface".
But the hard part is parsing.  Once run, its has to so all of this to parse those outputs into metrics...
https://github.com/slashdoom/aruba_exporter/blob/main/interfaces/parser.go#L314-L507

Yes, I understand; thank you for responding.
The point I make here is that we don't always want to export all of the metrics. For example, let's say we have 2000+ apps and simply want to capture up status and connected client count (ignoring RF). As it is a waste of infra resources to repeatedly pull RF data that is never utilized, could you suggest a means for us to configure which metrics to export even within a category (wireless)?
I do understand this is not a common use case.