donejs add app  slow

Explore solutions to making donejs add app faster such as:

[x] - dependency audit (after deciding https://github.com/donejs/donejs/issues/705)
[x] - yarn
[x] - caching npm modules from https://github.com/donejs/generator-donejs/issues/128
[x] - progressively adding heavy features

[x] - https://github.com/donejs/donejs/issues/540
[x] - https://github.com/donejs/cli/issues/63

Original comment:

The Command add app instalsl to long it trys to download donejs-cli that is included already global else the command wouldn't run the step needs to be bypassed

It needs a local copy of the DoneJS-cli, but we definitely need to implement a caching mechanism.  We have talked about setting it up so that it caches the packages during the first install, then you could do 'donejs add app -c' or something like that to tell it to use the cached modules.  I definitely agree with you, though.  It is the worst part of the current user experience to wait for all of the packages to install.

To expand on what Marshall said, I think that global clis are an anti pattern. If you've ever had two projects on two different grunt versions on the same computer, you'll know what I mean.
This means creating a new project is expensive, but it also means multiple DoneJS project versions can exist on the same computer.
Sent from my iPhone

On Sep 10, 2016, at 9:16 AM, Marshall Thompson<EMAIL_ADDRESS>wrote:
It needs a local copy of the DoneJS-cli, but we definitely need to implement a caching mechanism. We have talked about setting it up so that it caches the packages during the first install, then you could do 'donejs add app -c' or something like that to tell it to use the cached modules. I definitely agree with you, though. It is the worst part of the current user experience to wait for all of the packages to install.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

i say we should simply add a donejs create app --link parameter that will allow npm link the current global donejs-cli
thats just my 5 cents.

on systems with a slow network or unstable network connection doneJS isn't even useable that can't be by design the goal. I packed it now up and simply edit the JSON and other Files via Search replace

@frank-dspeed I know exactly what you mean.  I swear my house has the only reliable internet connection within a two hour drive, so when I go anywhere else it really hurts to either start a new project or do generator work in general.

I have a good idea how about simply publish done-cli with all its modules to github and then we download simply the tar on done-cli install? this way we could cache the tar if needed we could download the tar to a place like ~/.donejs

We'd have to build that tarball everytime a dependency changed. Building this is doable but the problem with this idea is it wouldn't install dependencies based on the current user's npm.
Sent from my iPhone

On Oct 13, 2016, at 6:05 AM, Frank Lemanschik<EMAIL_ADDRESS>wrote:
I have a good idea how about simply publish done-cli with all its modules to github and then we download simply the tar on done-cli install? this way we could cache the tar if needed we could download the tar to a place like ~/.donejs
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

hm ok then we need to code something to create the tar based on the system once and then use that ?

Maybe something like on first done-cli install look into ~/.donejs whats in it if nothing we create a tar if there is something and no option (Version) Specificated if version is specificated we could look if that tar exists elese build it

Could you list dependencys that would need rebuild or else as far as i know and saw there shouldn't be something in that needs custom build.

My Final result is we should drop the npm install from the /generator used by donejs add app and simply create only the skeletton dir with the right package.json and yarn.lock file so the User is free to use what he has and whants to Install the generated app. via yarn install --flat, yarn install, npm install
If all agree with that i will make a pull request!

I ran slow-deps on a new DoneJS 1.0 app. I think this can provide some useful info as we decide what to break out of the default app generator:
$ slow-deps
Analyzing 24 dependencies...
[====================] 100% 0.0s
-------------------------------------------------
| Dependency          | Time  | Size   | # Deps |
-------------------------------------------------
| documentjs          | 35.7s | 108 MB | 323    |
| testee              | 29.4s | 30 MB  | 309    |
| steal-tools         | 28s   | 42 MB  | 346    |
| generator-donejs    | 27.4s | 27 MB  | 342    |
| donejs-cli          | 25.8s | 22 MB  | 345    |
| donejs-deploy       | 19.4s | 35 MB  | 262    |
| done-serve          | 14.4s | 24 MB  | 140    |
| steal-less          | 7s    | 5.9 MB | 75     |
| steal               | 5.6s  | 17 MB  | 59     |
| can-fixture         | 3.3s  | 3.9 MB | 27     |
| done-component      | 3.2s  | 1.8 MB | 23     |
| done-autorender     | 2.9s  | 3.3 MB | 25     |
| can-connect         | 2.8s  | 3.8 MB | 26     |
| can-component       | 2.7s  | 1.8 MB | 22     |
| steal-stache        | 2.6s  | 2.9 MB | 23     |
| funcunit            | 2.3s  | 8.2 MB | 3      |
| can-stache          | 2.2s  | 1.4 MB | 18     |
| can-view-autorender | 1.9s  | 544 KB | 9      |
| can-route-pushstate | 1.8s  | 723 KB | 10     |
| can-route           | 1.6s  | 682 KB | 9      |
| can-define          | 1.4s  | 791 KB | 8      |
| steal-qunit         | 1.3s  | 569 KB | 2      |
| done-css            | 1.1s  | 456 KB | 1      |
| can-zone            | 848ms | 86 KB  | 0      |
-------------------------------------------------
Total time (non-deduped): 3m 44.6s
Total size (non-deduped): 343 MB

Could you run this on the top 5 and post the results:
| documentjs          | 35.7s | 108 MB | 323    |
| testee              | 29.4s | 30 MB  | 309    |
| steal-tools         | 28s   | 42 MB  | 346    |
| generator-donejs    | 27.4s | 27 MB  | 342    |
| donejs-cli          | 25.8s | 22 MB  | 345

documentjs:
--------------------------------------------------------
| Dependency                 | Time  | Size   | # Deps |
--------------------------------------------------------
| steal-tools                | 23.7s | 71 MB  | 301    |
| chokidar                   | 6.2s  | 5.6 MB | 56     |
| steal                      | 6.2s  | 22 MB  | 76     |
| connect                    | 5s    | 2.4 MB | 68     |
| less                       | 3.6s  | 15 MB  | 35     |
| mocha                      | 2.7s  | 1.2 MB | 34     |
| can                        | 2.2s  | 11 MB  | 2      |
| documentjs-github-download | 2.1s  | 1.1 MB | 19     |
| fs-extra                   | 1.8s  | 294 KB | 15     |
| glob                       | 1.4s  | 146 KB | 9      |
| handlebars                 | 1.3s  | 1.7 MB | 4      |
| cross-spawn-async          | 1.2s  | 90 KB  | 6      |
| engine-dependencies        | 986ms | 66 KB  | 2      |
| jquery                     | 965ms | 1.3 MB | 0      |
| minimatch                  | 957ms | 113 KB | 2      |
| md5                        | 930ms | 36 KB  | 3      |
| qunit-mocha-ui             | 919ms | 58 KB  | 0      |
| rimraf                     | 918ms | 31 KB  | 1      |
| yargs                      | 911ms | 119 KB | 0      |
| lodash                     | 881ms | 975 KB | 0      |
| async                      | 839ms | 77 KB  | 0      |
| q                          | 828ms | 93 KB  | 0      |
| esprima                    | 797ms | 215 KB | 1      |
--------------------------------------------------------

testee:
-----------------------------------------------
| Dependency        | Time  | Size   | # Deps |
-----------------------------------------------
| launchpad         | 11.7s | 10 MB  | 78     |
| miner             | 7.1s  | 4.1 MB | 111    |
| istanbul          | 4.5s  | 6.5 MB | 54     |
| feathers          | 4.2s  | 4.0 MB | 51     |
| feathers-socketio | 3.7s  | 2.5 MB | 46     |
| jshint            | 3s    | 4.5 MB | 29     |
| mocha             | 2.7s  | 1.2 MB | 34     |
| testee-client     | 2.4s  | 2.4 MB | 28     |
| body-parser       | 2.2s  | 885 KB | 19     |
| del               | 2.1s  | 263 KB | 25     |
| async             | 1.6s  | 1.9 MB | 1      |
| lodash            | 1.4s  | 1.4 MB | 0      |
| feathers-memory   | 1.3s  | 251 KB | 6      |
| chai              | 1.2s  | 439 KB | 3      |
| connect-injector  | 1.2s  | 264 KB | 5      |
| feathers-rest     | 1.1s  | 314 KB | 5      |
| path              | 1s    | 90 KB  | 3      |
| http-proxy        | 959ms | 77 KB  | 2      |
| useragent         | 928ms | 252 KB | 1      |
| mime-types        | 921ms | 181 KB | 1      |
| debug             | 915ms | 51 KB  | 1      |
| commander         | 862ms | 50 KB  | 1      |
| q                 | 859ms | 124 KB | 0      |
| qunitjs           | 836ms | 178 KB | 0      |
-----------------------------------------------

steal-tools:
-------------------------------------------------
| Dependency          | Time  | Size   | # Deps |
-------------------------------------------------
| testee              | 27.3s | 29 MB  | 318    |
| transpile           | 11.5s | 11 MB  | 160    |
| browserify          | 8.7s  | 6.8 MB | 119    |
| chokidar            | 6.2s  | 5.6 MB | 56     |
| steal               | 5.4s  | 17 MB  | 59     |
| coveralls-send      | 5.2s  | 4.2 MB | 80     |
| bower               | 4.9s  | 17 MB  | 1      |
| istanbul            | 4.5s  | 6.5 MB | 54     |
| yargs               | 3.7s  | 803 KB | 45     |
| cssify              | 3.3s  | 2.1 MB | 46     |
| jshint              | 3.1s  | 4.5 MB | 29     |
| uglify-js           | 2.7s  | 1.7 MB | 18     |
| mocha               | 2.6s  | 1.2 MB | 34     |
| steal-bundler       | 2.2s  | 411 KB | 18     |
| traceur             | 2.2s  | 2.5 MB | 16     |
| serve-static        | 1.6s  | 311 KB | 19     |
| through2            | 1.6s  | 165 KB | 9      |
| rimraf              | 1.6s  | 182 KB | 12     |
| connect             | 1.5s  | 207 KB | 10     |
| lodash              | 1.4s  | 1.4 MB | 0      |
| glob                | 1.4s  | 165 KB | 10     |
| winston             | 1.2s  | 443 KB | 6      |
| moment              | 1.1s  | 2.2 MB | 0      |
| clean-css           | 1.1s  | 1.1 MB | 1      |
| tmp                 | 1.1s  | 29 KB  | 1      |
| mock-fs             | 1.1s  | 992 KB | 3      |
| steal-qunit         | 1s    | 569 KB | 2      |
| fs-extra            | 997ms | 176 KB | 3      |
| comparify           | 990ms | 11 KB  | 0      |
| jquery              | 980ms | 1.3 MB | 0      |
| ws                  | 938ms | 141 KB | 2      |
| engine-dependencies | 907ms | 66 KB  | 2      |
| bitovi-source-map   | 906ms | 154 KB | 1      |
| find-line-column    | 870ms | 5.1 KB | 0      |
| steal-css           | 854ms | 378 KB | 0      |
| steal-parse-amd     | 836ms | 31 KB  | 0      |
| steal-conditional   | 783ms | 54 KB  | 0      |
| pdenodeify          | 769ms | 4.0 KB | 0      |
| mockery             | 768ms | 52 KB  | 0      |
| tree-kill           | 768ms | 7.8 KB | 1      |
| mocha-lcov-reporter | 753ms | 9.8 KB | 0      |
| colors              | 752ms | 30 KB  | 0      |
| urix                | 744ms | 6.4 KB | 0      |
| is-appveyor         | 738ms | 5.2 KB | 0      |
-------------------------------------------------

generator-donejs:
-------------------------------------------------------
| Dependency                | Time  | Size   | # Deps |
-------------------------------------------------------
| yeoman-generator          | 24.2s | 27 MB  | 336    |
| donejs-cli                | 23.6s | 22 MB  | 345    |
| coveralls-send            | 4.9s  | 4.2 MB | 80     |
| istanbul                  | 4.6s  | 6.5 MB | 54     |
| mocha                     | 2.1s  | 1.2 MB | 17     |
| donejs                    | 1.9s  | 405 KB | 17     |
| fs-extra                  | 1.8s  | 336 KB | 16     |
| lodash                    | 1.2s  | 859 KB | 0      |
| mkdirp                    | 883ms | 48 KB  | 2      |
| validate-npm-package-name | 879ms | 17 KB  | 1      |
| q                         | 842ms | 124 KB | 0      |
| semver                    | 817ms | 55 KB  | 1      |
| lodash.upperfirst         | 780ms | 14 KB  | 0      |
| lodash-inflection         | 778ms | 36 KB  | 0      |
| mocha-lcov-reporter       | 756ms | 9.8 KB | 0      |
-------------------------------------------------------

donejs-cli:
-------------------------------------------------
| Dependency          | Time  | Size   | # Deps |
-------------------------------------------------
| documentjs          | 29.7s | 108 MB | 323    |
| yeoman-generator    | 25.1s | 26 MB  | 342    |
| yeoman-environment  | 5.8s  | 9.5 MB | 79     |
| coveralls-send      | 5.6s  | 4.2 MB | 80     |
| istanbul            | 4.7s  | 6.5 MB | 54     |
| jshint              | 3s    | 4.5 MB | 29     |
| mocha               | 2.1s  | 1.2 MB | 17     |
| rimraf              | 1.7s  | 182 KB | 12     |
| concat-stream       | 1.3s  | 178 KB | 9      |
| cross-spawn-async   | 1.2s  | 90 KB  | 6      |
| mkdirp              | 892ms | 48 KB  | 2      |
| engine-dependencies | 892ms | 66 KB  | 2      |
| commander           | 879ms | 50 KB  | 1      |
| debug               | 877ms | 51 KB  | 1      |
| is-ci               | 871ms | 16 KB  | 1      |
| q                   | 829ms | 124 KB | 0      |
| mockery             | 768ms | 52 KB  | 0      |
| steal-platform      | 756ms | 5.9 KB | 0      |
| mocha-lcov-reporter | 750ms | 9.8 KB | 0      |
-------------------------------------------------

We're those only dev dependencies? Why does steal-tools depend on testee? @matthewcp
Sent from my iPhone

On Jan 26, 2017, at 5:18 PM, Kevin Phillips<EMAIL_ADDRESS>wrote:
documentjs:

| Dependency                 | Time  | Size   | # Deps |
| steal-tools                | 23.7s | 71 MB  | 301    |
| chokidar                   | 6.2s  | 5.6 MB | 56     |
| steal                      | 6.2s  | 22 MB  | 76     |
| connect                    | 5s    | 2.4 MB | 68     |
| less                       | 3.6s  | 15 MB  | 35     |
| mocha                      | 2.7s  | 1.2 MB | 34     |
| can                        | 2.2s  | 11 MB  | 2      |
| documentjs-github-download | 2.1s  | 1.1 MB | 19     |
| fs-extra                   | 1.8s  | 294 KB | 15     |
| glob                       | 1.4s  | 146 KB | 9      |
| handlebars                 | 1.3s  | 1.7 MB | 4      |
| cross-spawn-async          | 1.2s  | 90 KB  | 6      |
| engine-dependencies        | 986ms | 66 KB  | 2      |
| jquery                     | 965ms | 1.3 MB | 0      |
| minimatch                  | 957ms | 113 KB | 2      |
| md5                        | 930ms | 36 KB  | 3      |
| qunit-mocha-ui             | 919ms | 58 KB  | 0      |
| rimraf                     | 918ms | 31 KB  | 1      |
| yargs                      | 911ms | 119 KB | 0      |
| lodash                     | 881ms | 975 KB | 0      |
| async                      | 839ms | 77 KB  | 0      |
| q                          | 828ms | 93 KB  | 0      |
| esprima                    | 797ms | 215 KB | 1      |
testee:

| Dependency        | Time  | Size   | # Deps |
| launchpad         | 11.7s | 10 MB  | 78     |
| miner             | 7.1s  | 4.1 MB | 111    |
| istanbul          | 4.5s  | 6.5 MB | 54     |
| feathers          | 4.2s  | 4.0 MB | 51     |
| feathers-socketio | 3.7s  | 2.5 MB | 46     |
| jshint            | 3s    | 4.5 MB | 29     |
| mocha             | 2.7s  | 1.2 MB | 34     |
| testee-client     | 2.4s  | 2.4 MB | 28     |
| body-parser       | 2.2s  | 885 KB | 19     |
| del               | 2.1s  | 263 KB | 25     |
| async             | 1.6s  | 1.9 MB | 1      |
| lodash            | 1.4s  | 1.4 MB | 0      |
| feathers-memory   | 1.3s  | 251 KB | 6      |
| chai              | 1.2s  | 439 KB | 3      |
| connect-injector  | 1.2s  | 264 KB | 5      |
| feathers-rest     | 1.1s  | 314 KB | 5      |
| path              | 1s    | 90 KB  | 3      |
| http-proxy        | 959ms | 77 KB  | 2      |
| useragent         | 928ms | 252 KB | 1      |
| mime-types        | 921ms | 181 KB | 1      |
| debug             | 915ms | 51 KB  | 1      |
| commander         | 862ms | 50 KB  | 1      |
| q                 | 859ms | 124 KB | 0      |
| qunitjs           | 836ms | 178 KB | 0      |
steal-tools:

| Dependency          | Time  | Size   | # Deps |
| testee              | 27.3s | 29 MB  | 318    |
| transpile           | 11.5s | 11 MB  | 160    |
| browserify          | 8.7s  | 6.8 MB | 119    |
| chokidar            | 6.2s  | 5.6 MB | 56     |
| steal               | 5.4s  | 17 MB  | 59     |
| coveralls-send      | 5.2s  | 4.2 MB | 80     |
| bower               | 4.9s  | 17 MB  | 1      |
| istanbul            | 4.5s  | 6.5 MB | 54     |
| yargs               | 3.7s  | 803 KB | 45     |
| cssify              | 3.3s  | 2.1 MB | 46     |
| jshint              | 3.1s  | 4.5 MB | 29     |
| uglify-js           | 2.7s  | 1.7 MB | 18     |
| mocha               | 2.6s  | 1.2 MB | 34     |
| steal-bundler       | 2.2s  | 411 KB | 18     |
| traceur             | 2.2s  | 2.5 MB | 16     |
| serve-static        | 1.6s  | 311 KB | 19     |
| through2            | 1.6s  | 165 KB | 9      |
| rimraf              | 1.6s  | 182 KB | 12     |
| connect             | 1.5s  | 207 KB | 10     |
| lodash              | 1.4s  | 1.4 MB | 0      |
| glob                | 1.4s  | 165 KB | 10     |
| winston             | 1.2s  | 443 KB | 6      |
| moment              | 1.1s  | 2.2 MB | 0      |
| clean-css           | 1.1s  | 1.1 MB | 1      |
| tmp                 | 1.1s  | 29 KB  | 1      |
| mock-fs             | 1.1s  | 992 KB | 3      |
| steal-qunit         | 1s    | 569 KB | 2      |
| fs-extra            | 997ms | 176 KB | 3      |
| comparify           | 990ms | 11 KB  | 0      |
| jquery              | 980ms | 1.3 MB | 0      |
| ws                  | 938ms | 141 KB | 2      |
| engine-dependencies | 907ms | 66 KB  | 2      |
| bitovi-source-map   | 906ms | 154 KB | 1      |
| find-line-column    | 870ms | 5.1 KB | 0      |
| steal-css           | 854ms | 378 KB | 0      |
| steal-parse-amd     | 836ms | 31 KB  | 0      |
| steal-conditional   | 783ms | 54 KB  | 0      |
| pdenodeify          | 769ms | 4.0 KB | 0      |
| mockery             | 768ms | 52 KB  | 0      |
| tree-kill           | 768ms | 7.8 KB | 1      |
| mocha-lcov-reporter | 753ms | 9.8 KB | 0      |
| colors              | 752ms | 30 KB  | 0      |
| urix                | 744ms | 6.4 KB | 0      |
| is-appveyor         | 738ms | 5.2 KB | 0      |
generator-donejs:

| Dependency                | Time  | Size   | # Deps |
| yeoman-generator          | 24.2s | 27 MB  | 336    |
| donejs-cli                | 23.6s | 22 MB  | 345    |
| coveralls-send            | 4.9s  | 4.2 MB | 80     |
| istanbul                  | 4.6s  | 6.5 MB | 54     |
| mocha                     | 2.1s  | 1.2 MB | 17     |
| donejs                    | 1.9s  | 405 KB | 17     |
| fs-extra                  | 1.8s  | 336 KB | 16     |
| lodash                    | 1.2s  | 859 KB | 0      |
| mkdirp                    | 883ms | 48 KB  | 2      |
| validate-npm-package-name | 879ms | 17 KB  | 1      |
| q                         | 842ms | 124 KB | 0      |
| semver                    | 817ms | 55 KB  | 1      |
| lodash.upperfirst         | 780ms | 14 KB  | 0      |
| lodash-inflection         | 778ms | 36 KB  | 0      |
| mocha-lcov-reporter       | 756ms | 9.8 KB | 0      |
donejs-cli:

| Dependency          | Time  | Size   | # Deps |
| documentjs          | 29.7s | 108 MB | 323    |
| yeoman-generator    | 25.1s | 26 MB  | 342    |
| yeoman-environment  | 5.8s  | 9.5 MB | 79     |
| coveralls-send      | 5.6s  | 4.2 MB | 80     |
| istanbul            | 4.7s  | 6.5 MB | 54     |
| jshint              | 3s    | 4.5 MB | 29     |
| mocha               | 2.1s  | 1.2 MB | 17     |
| rimraf              | 1.7s  | 182 KB | 12     |
| concat-stream       | 1.3s  | 178 KB | 9      |
| cross-spawn-async   | 1.2s  | 90 KB  | 6      |
| mkdirp              | 892ms | 48 KB  | 2      |
| engine-dependencies | 892ms | 66 KB  | 2      |
| commander           | 879ms | 50 KB  | 1      |
| debug               | 877ms | 51 KB  | 1      |
| is-ci               | 871ms | 16 KB  | 1      |
| q                   | 829ms | 124 KB | 0      |
| mockery             | 768ms | 52 KB  | 0      |
| steal-platform      | 756ms | 5.9 KB | 0      |
| mocha-lcov-reporter | 750ms | 9.8 KB | 0      |
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

It's dependencies and devDependencies.

I think in general this is one of the really big issues I was facing also I solved it via moving simply all can dependencies to peerDependencys that saves a lot of time also flat install algo and yarn work really great even a normal donejs installation utilizing yarn takes round about 15 sec on a normal desktop PC

donejs-cli can be droped complet and replaced by donejs global installed that does the function relativ to project dir.

Can you do it with just deps? Those are what are installed by the CLI.
Sent from my iPhone

On Jan 26, 2017, at 7:59 PM, Kevin Phillips<EMAIL_ADDRESS>wrote:
It's dependencies and devDependencies.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Hey @justinbmeyer, I think you may have meant @matthewp, not me! Thanks.

@justinbmeyer I updated https://github.com/donejs/generator-donejs/issues/145#issuecomment-275544828 to only have dependencies.

Going to move this into donejs/donejs and make it an epic.

Issue moved to donejs/donejs #783 via ZenHub


sub _build_posts does not sort a file list with both .md and .markdown correctly

This may be irrelevant, considering the list is later sorted by desired publication date, but in the posts builder, this line appears:
            sort { $a->basename cmp $b->basename }

In context, $a and $b are Path::Class::File objects and one might expect basename to return the filename without an extension here.  However, it does not.  The extension is still present.
Using the venerable File::Basename::basename routine allows the caller to provide a list extensions to be stripped out of the returned file name.  However, Path::Class::File::basename does not appear to take extensions as arguments to strip off, which is surprising.
Ultimately, the list of posts is sorted by the desired publication date, which Plerd::Post calculates.
Frankly, I would suggest removing the file sort as it appears do work that is ultimately thrown away.
Marking this as an enhancement because it does not really cause problems in the project.  This is sort of "it would be nice to fix for pendantry" issue.

Re-labeling as a bug, since if it's doing work that gets tossed, it might be unnecessarily slowing down publication.


Kubic is dead for Ubuntu 20.04

Describe the bug
A clear and concise description of what the bug is.
Issue Description
Can not install any package for Ubuntu 20.04 - missing Release file -
Expected Result
Packages installed correctly
How to Reproduce
root@controller-01:~# . /etc/os-release
root@controller-01:~# sudo sh -c "echo 'deb https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/testing/xUbuntu_${VERSION_ID}/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:testing.list"
root@controller-01:~# curl -L https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/testing/xUbuntu_${VERSION_ID}/Release.key | sudo apt-key add -
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed
100  1083    0  1083    0     0   5060      0 --:--:-- --:--:-- --:--:--  5060
gpg: no valid OpenPGP data found.
root@controller-01:~# sudo apt-get update -qq
E: The repository 'https://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/testing/xUbuntu_20.04  Release' does not have a Release file.

https://github.com/containers/buildah/issues/4012#issuecomment-1138618072

Closed by: #666


Spark generates very long module names causing compile errors on some systems

Describe the bug
Deeply nested DSLs create module names such as Elixir.Wayfarer.Dsl.Wayfarer.Config.Wayfarer.Targets.Targets.Wayfarer.Targets.Targets.Http.Wayfarer.Targets.Targets.HealthChecks.HealthChecks which will trigger enametoolong on some systems:
08:20:24.969 [error] Process #PID<0.153.0> raised an exception
** (File.Error) could not write to file "/home/james/Dev/harton.dev/james/wayfarer/_build/dev/lib/wayfarer/ebin/Elixir.Wayfarer.Dsl.Wayfarer.Config.Wayfarer.Targets.Targets.Wayfarer.Targets.Targets.Http.Wayfarer.Targets.Targets.HealthChecks.HealthChecks.beam": file name too long
    (elixir 1.17.1) lib/file.ex:1144: File.write!/3
    (elixir 1.17.1) lib/kernel/parallel_compiler.ex:334: anonymous fn/3 in Kernel.ParallelCompiler.write_module_binaries/3
    (elixir 1.17.1) lib/enum.ex:1268: anonymous fn/3 in Enum.flat_map/2
    (stdlib 6.0) maps.erl:860: :maps.fold_1/4
    (elixir 1.17.1) lib/enum.ex:2543: Enum.flat_map/2
    (elixir 1.17.1) lib/kernel/parallel_compiler.ex:261: Kernel.ParallelCompiler.spawn_workers/3
    (mix 1.17.1) lib/mix/compilers/elixir.ex:1018: anonymous fn/9 in Mix.Compilers.Elixir.compiler_loop/6

To be clear this an issue with BEAM and not Spark or Elixir and in response to a similar bug report against Elixir José's response boils down to "just use shorter module names". I think he's right. There are a couple of strategies I can think of;

Move generated modules out of the Elixir. namespace (I suggest Spark.).
Name modules by using a hash of their DSL path. I'd suggest :erlang.phash2 since it should always be available. It doesn't really matter if the modules are "discoverable" as they're only ever imported by Spark anyway. We can always add a flag to disable this behaviour while debugging.

To Reproduce
I triggered it by using eCryptfs on a portable Linux device because the effective file length limit is ~140 bytes. It is possible to reproduce on Linux & macOS (255 byte limit) by creating a DSL with very long entity names.
Expected behavior
The DSL extension should cleanly compile.
Runtime

Elixir version 1.17.1
Erlang version 27.0
OS Linux 5.10.17-v8+ aarch64. Raspberry Pi OS based on Debian 11 (bullseye).
Spark version 2.2.4
any related extension versions

Additional context
Add any other context about the problem here.

Open to any of these. The generated modules are hidden and any public use of them is incorrect. So honestly I'm down for "anything that works" 😅

@jimsynz if you've got some time to tackle this that would be great, got a lot on ye olde plate at the moment.

Yeah, I've added it to my list :)


Human readable dates and multiple file path support in the collate command

[x] Tick to sign-off your agreement to the Developer Certificate of Origin (DCO) 1.1

What

Make --start and --end options in collate accept humna readable dates, ie 2022-09-29 instead of 20220929
Enable collation of mulitple files with a single collate command by using , as a path seperator.

Why
The current --start and --end formats are hard for humans to read, which makes collating data to provide to auditors difficult, as conversion between date formats needs to be done by hand, and the number grouping makes it hard to ensure there have not been any typos etc
Being able to pull multiple files at once makes it easier to pull multiple files over the same date range when an auditor is requesting multiple files.
How

Replace all references to YYYYMMDD dates to YYYY-MM-DD dates
Split the file path string and iterate over the result calling collate functions multiple times.

Test

Updated tests for the new date format
Add a new test to pull multiple files.

Context

hmm the github action looks like is failing because of the python version is too old for the version of flake8.

@rhyshort I'm changing all the linting side of the project here #28

@cletomartin nice, I'll rebase this on top of #28 once merged.

Rebased on top of the changes from #28

Done

Thanks @cletomartin, I don't have write access so can you go ahead and merge please?

Merged - thanks Rhys!


AWS getting started doc is out of date

we need to update AWS getting started doc to request users to download Fannie Mae dataset.

close since #252 merged


feat(protocol): remove Taiko token dependency

This PR removes the dependency of Taiko's L1 contract on Taiko token:

All bonds are now paid in native ETH.
ETH bonds need to be pre-deposited via existing TaikoL1.depositBond function. They can be withdrawn using TaikoL1.withdrawBond.
ProverSet contract has been removed. It was used as a store of Taiko tokens and relayed block proving calls. It is no longer useful because the prover must deposit their ETH bonds by themselves in TaikoL1.
Airdrop, Vesting and other team related contracts have been removed.
Bond amounts have been changed to ETH values based on current TAIKO price. Eg: Liveness bond is changed from 125 TAIKO to 0.07 ETH.

Please double check changes in packages/taiko-client/bindings/gen*, packages/protocol/test/genesis/data/genesis* and packages/taiko-client/bindings/.githead as I skipped them because I lack the context

Will be done by @mikhailUshakoff

gen_* files are generated using ./scripts/gen_bindings.sh they are bindings to the changed contracts.


Add runtime template of vLLM ROCM

Jira : https://issues.redhat.com/browse/RHOAIENG-14712

Description
Add runtime template of vLLM ROCM
How Has This Been Tested?

Setup DataScienceCluster with below onfiguration.

apiVersion: datasciencecluster.opendatahub.io/v1
kind: DataScienceCluster
metadata:
  labels:
    app.kubernetes.io/created-by: rhods-operator
    app.kubernetes.io/instance: default-dsc
    app.kubernetes.io/managed-by: kustomize
    app.kubernetes.io/name: datasciencecluster
    app.kubernetes.io/part-of: rhods-operator
  name: default-dsc
spec:
  components:
    codeflare:
      managementState: Managed
    dashboard:
      managementState: Managed
    datasciencepipelines:
      managementState: Managed
    kserve:
      devFlags:
        manifests:
          - contextDir: config
            sourcePath: overlays/odh
            uri: 'https://github.com/opendatahub-io/kserve/tarball/master'
          - contextDir: config
            sourcePath: ''
            uri: 'https://github.com/vaibhavjainwiz/odh-model-controller/tarball/RHOAIENG-14712'
      serving:
        ingressGateway:
          certificate:
            type: OpenshiftDefaultIngress
        managementState: Managed
        name: knative-serving
      managementState: Managed
    kueue:
      managementState: Managed
    modelmeshserving:
      managementState: Removed
    ray:
      managementState: Managed
    trainingoperator:
      managementState: Removed
    trustyai:
      managementState: Removed
    workbenches:
      managementState: Managed

Verify new ServingRuntime with name vllm-rocm-runtime-template should be created in redhat-ods-applications namespace.
New ServingRuntime should be available is dashboard.
User should be able to deploy Model using new ServingRuntime.

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

/lgtm


update README.md

Summary by CodeRabbit

Documentation

Updated the Analysis method table in the README with enhanced formatting, hyperlinks to sequence diagrams, and revised summaries, pros, and cons for specific analysis methods.

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

Comparison is base (c7159d7) 71.83% compared to head (fb70875) 71.83%.
Report is 1 commits behind head on main.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main      #96   +/-   ##
=======================================
  Coverage   71.83%   71.83%
=======================================
  Files          20       20
  Lines         348      348
  Branches       37       37
=======================================
  Hits          250      250
  Misses         98       98

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


Add a license

I believe MIT license would be a good choice for this project.
https://choosealicense.com/licenses/mit/

Thanks for the suggestion.

From: digitalfrost @.>
Sent: Saturday, August 20, 2022 2:34 PM
To: BoysTownorg/chapro @.>
Cc: Subscribed @.***>
Subject: [BoysTownorg/chapro] Add a license (PR #9)
I believe MIT license would be a good choice for this project. https: //choosealicense. com/licenses/mit/ You can view, comment on, or merge this pull request online at: https: //github. com/BoysTownorg/chapro/pull/9 Commit Summary
I believe MIT license would be a good choice for this project.
https://choosealicense.com/licenses/mit/https://urldefense.com/v3/__https://choosealicense.com/licenses/mit/__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWSOhHE7U$

You can view, comment on, or merge this pull request online at:
https://github.com/BoysTownorg/chapro/pull/9https://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesW1-S_8yk$
Commit Summary

29b1b61https://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9/commits/29b1b6138c4e6f9f8035d75784c7537e1bbe92e7__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWCw3iirA$ Add a LICENSE
2bd50fehttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9/commits/2bd50fe61450f79ee9fae69e7233056b72e8a2bb__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWmRWOLyM$ Update README.md

File Changes
(2 fileshttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9/files__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWLD7b8k4$)

A LICENSEhttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9/files*diff-c693279643b8cd5d248172d9c22cb7cf4ed163a3c98c8a3f69c2717edd3eacb7__;Iw!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWyirTN8Y$ (21)
M README.mdhttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9/files*diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5__;Iw!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWO1V7HbY$ (2)

Patch Links:

https://github.com/BoysTownorg/chapro/pull/9.patchhttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9.patch__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesWob8Xuw0$
https://github.com/BoysTownorg/chapro/pull/9.diffhttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9.diff__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesW-HpZEA4$

—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/BoysTownorg/chapro/pull/9__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesW1-S_8yk$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ACOKKHJXMQMVYRX3KVRKA23V2EXK5ANCNFSM57DV7S2Q__;!!CEjAKCqGPSl6!roHns55ZUuejRZ71Pp3tmuPrnn7VCqznFqHnzLIK_1DK0Ibv6rT6vnGQnmVmx4B41caDdOTOT0dvbBqirgBPHesW9g_2tYE$.
You are receiving this because you are subscribed to this thread.Message ID: @.***>


tests: allow execution of selected pytests only

Allows execution of selected pytests via PYTESTARG environment variable. Example:
$ PYTESTARG=tests/test_version.py ./run-tests.sh --check-pytest

Closes reanahub/reana#755.

This PR is not really necessary because PYTEST_ADDOPTS works:
$ PYTEST_ADDOPTS=tests/test_version.py ./run-tests.sh --check-pytest


Updated to 1.18.x support version of spigot

Updated to 1.18 support, fully working just renamed methods

Thanks for the contribution. Apologies for not merging it sooner!


fix(TDI-49319): Upgrade org.ops4j.pax.url:pax-url-aether:2.6.(2,11) to 2.6.12

What is the current behavior? (You can also link to an open issue here)
https://jira.talendforge.org/browse/TDI-49319
What is the new behavior?
https://jira.talendforge.org/browse/TDI-49319
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[x] Other... Please describe: CVE

Does this PR introduce a breaking change?

[ ] Yes
[x] No

https://jenkins-connectors.datapwn.com/job/components/job/build/job/wwang-talend%252FTDI-49319/
seems tcompv0 jenkins only can run master branch now, can't run dev branch one


help: Links to anchor tags from left sidebar don't work. #6714

The reference from "status" in file sidebar.md is made explicitly to a newly created file "status-messages.md".
Fixes: 6714

Hi @psycho-valker Can you make the first line in your commit message be more descriptive?  You can see examples of commit messages by doing git log.

Thanks @psycho-valker. The issue is asking for a general fix; all the links to anchors from the left sidebar don't work, not just the one to status messages. Feel free to ask on chat.zulip.org if this doesn't make sense.

@rishig i think it is working now for all links except, under Streams and topic there is a section View your stream subscription, i think this is also not behaving properly.

Hello @showell  actually this was my first commit i was unaware of making my commits message descriptive, i will make descriptive commits from now on, Thank you!, and yes what i did in this commit is, i just created a new file named "status-messages.md" and linked it in "sidebar.md"

Sorry, I wasn't clear in my last message. What I mean is that we're hoping to solve the general problem of linking to the middle of a longer article from the left sidebar. In the future we will likely have more such links.

@rishig ok i got it, thanks. I ll try again.


Adjust keyword argument delegation

Due to the separation of positional and keyword arguments in Ruby 3.0, a small change is needed for this Gem to work with Ruby 3.0.
Compatibility with Ruby 2.7(.2) is given from what I could see while testing.
This fixes https://github.com/bharget/heroicon/issues/1

I just hit this, pasting the error for searchability:
wrong number of arguments (given 1, expected 0; required keywords: name, variant, options)

I just hit this, pasting the error for searchability:
wrong number of arguments (given 1, expected 0; required keywords: name, variant, options)


Second duplicated echo is ignored

Issue summary
It seems that if you echo the same string twice in a row, only one text is printed on the terminal.
Expected behavior
That everything is printed.
Actual behavior
Only one string is printed.
Steps to reproduce
term.echo('hello').echo('hello')

The problem was with cache, this also printed two strings:
term.echo('foo').echo('bar').echo('foo')

Having the same issue.
Reverting to version 2.25.0 fixes it till a new version is up.
<EMAIL_ADDRESS>Thank you.

Released in 2.27.0


Build Error

Hello,
I'm trying to use this in a project i'm working on but when I try to compile i get these errors
Severity	Code	Description	Project	File	Line	Suppression State
Error	C2664	'DWORD ChangeAppIDLaunchACL(LPTSTR,LPTSTR,BOOL,BOOL,DWORD)': cannot convert argument 1 from 'const TCHAR ' to 'LPTSTR'	WinRobotHost	c:\users****\documents\winrobot\jni\winrobothost\winrobothost.cpp	168
Severity	Code	Description	Project	File	Line	Suppression State
Error	C2664	'DWORD ChangeAppIDAccessACL(LPTSTR,LPTSTR,BOOL,BOOL,DWORD)': cannot convert argument 1 from 'const TCHAR ' to 'LPTSTR'	WinRobotHost	c:\users****\documents\winrobot\jni\winrobothost\winrobothost.cpp	172
This is on a machine running windows 10
Thanks in advance for your help

fixed


[Language] Trailing comments don't compile

//works
/// works
thing string // doesnt work

This was failing for comments between attributes


RIS input

See https://github.com/larsgw/citation.js/issues/184
Note the ambiguity of the RIS format, type-dependent mappings etc. Would love to have https://github.com/citation-js/extended-crosswalks ready for this, but that's probably not feasible.

Apparently there is a fairly unambiguous specification: https://web.archive.org/web/20120526103719/http://refman.com/support/risformat_intro.asp

Correction: there are two fairly unambiguous specifications: https://web.archive.org/web/20110930172154/http://www.refman.com/support/risformat_intro.asp
(Also, blogpost)

Closed in 1c49bcb


Update to Kotlin 1.2

Blockers
Jackson Kotlin Module
In order to use Kotlin 1.2, a patch to Jackson Kotlin Module 2.7 has to be performed, since a class has moved in Kotlin Reflect and Jackson Kotlin Module crashes at runtime with a ClassNotFoundError.
A fork of Jackson Kotlin Module exists here.

[x] Patch the library to use Kotlin & Kotlin Reflect 1.2
[x] Deploy artefact locally and test
[x] Create a PR to official Jackson repository for it

PR on official Jackson repo: https://github.com/FasterXML/jackson-module-kotlin/pull/112


[FLINK-23748][tests] Testing window TVF session window

What is the purpose of the change
Add the SESSION Window TVF followed by Window Aggregate test class
https://issues.apache.org/jira/browse/FLINK-23748
Brief change log
Add Session Windows test methods in WindowAggregateITCase, including GroupingSets, Cube, Rollup, etc
Verifying this change
This change added tests and can be verified as follows:
Does this pull request potentially affect one of the following parts:

Dependencies (does it add or upgrade a dependency): no
The public API, i.e., is any changed class annotated with @Public(Evolving): no
The serializers: no
The runtime per-record code paths (performance sensitive): no
Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: no
The S3 file system connector: no

Documentation

Does this pull request introduce a new feature? no
If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented)

@flinkbot run azure


Mattock harvest behavior

Odd thing happens when using the Mattock to break torches. It will break any blocks in a 3x3 area next to the torch. Not a problem but  just something to think about I guess.
Tool could use a warning in the tooltip. One reason I suggested an option to Nerf the durability.

Yeah, thats what it does.  Whenever you mine something it breaks a 3x3 area around it.  It is built to do that.
Not sure what you mean by "nerf the ability".  If you want to mine a 1x1 instead of 3x3 you can use a different tool?

I was speaking on my suggestion from before about the durability thing. I've been awake for a while. Don't mind me. I didn't know that the blocks breaking next to a torch was on purpose.


running two servers at once

I'm running two servers (one for theme development, the other is my own site using the theme).  I tried doing this by specifying two different ports.  However, it seems like there's a hardcoded WS server that prevents this from happening.  Here's the error:
Listening for changes in C:\Users\doomy\Documents\code\portfolio\themes\gutenberg-portfolio/{content, templates, config.toml, static, sass}
Web server is available at http://<IP_ADDRESS>:3000
Press Ctrl+C to stop

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: WS Error <Io(Os { code: 10048, kind:
AddrInUse, message: "Only one usage of each socket address (protocol/network address/port) is normally permitted." })>', libcore\result.rs:945:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I know this use-case isn't exactly typical so I won't be upset if this is a wontfix, but thought I might as well report.

The issue is that the WS port for live reload is static in the code so running 2 instances will clash.
 Ideally it would just find a free port but I'm not sure it's worth the effort.
I will happily take a PR for that though!


Error message appear while typing Badge syntax with preview window open

When typing badge syntax with the preview window open, I see errors appear as soon as I start typing the parameter.

@bbringhu could you attach a copy of the syntax-style-guide.md file?  I don't believe I have a raw copy, just the rendered version from the ExL site.

Here's the syntax-style-guide.md file:
syntax-style-guide.md

Let's close this and re-open if someone else runs into it. Edge issue at most...


Crash on startup M1 native mac 1.16.5 forge

I got crashed on startup, I have no clue to why i does. But I'm playing on 1.16.5 forge on native m1 specifically with the m1 multimc hack script, so could be because of of the rendering engine.
Here's the crash log, I tried running it without any mods installed
crash-2022-07-08_15.10.30-client.txt

Hm it can't find the renderShadow method. I think there was an alternative 1.16 release on CurseForge, try that. I can't do any fixes to 1.16 anymore.

oh okay, thanks. Version 2.0.1 seems to work fine

I think this is the same thing that now happened with Forge 1.19. They probably renamed/deleted/moved stuff during the version, breaking all/some mods in one go. Since there is a working version up too and this is just 1.16 Forge, I'll close the issue.


Crash when trying to unzip file

Hello, first of all thanks for the library.
When trying to unzip a zip file, it always crash for me on this step:
OZZipFile *unzipFile= [[OZZipFile alloc]<EMAIL_ADDRESS>mode:OZZipFileModeUnzip];

I double checked and the zip file is exist and can be unzipped correctly by OSX archiver. Zip file is created by OSX archiver.
It always crash on:
unzip.c > unzOpenInternal() line 577 unzGoToFirstFile((unzFile)s);
#0  0x00000001842bb7b8 in flockfile ()
#1  0x00000001842c7488 in fseek ()
#2  0x0000000100371ca0 in unzlocal_GetCurrentFileInfoInternal ()
#3  0x0000000100372d08 in unzGoToFirstFile ()
#4  0x000000010013a4bc in unzOpenInternal at /Users/Est/tiramisu/Pods/objective-zip/MiniZip/unzip.c:577
#5  0x000000010013a500 in unzOpen64 at /Users/Est/tiramisu/Pods/objective-zip/MiniZip/unzip.c:613
#6  0x0000000100130ff4 in -[OZZipFile initWithFileName:mode:legacy32BitMode:] at /Users/Est/tiramisu/Pods/objective-zip/Objective-Zip/OZZipFile.m:98
#7  0x0000000100130e20 in -[OZZipFile initWithFileName:mode:] at /Users/Est/tiramisu/Pods/objective-zip/Objective-Zip/OZZipFile.m:83
#8  0x0000000100131320 in -[OZZipFile initWithFileName:mode:error:] at /Users/Est/tiramisu/Pods/objective-zip/Objective-Zip/OZZipFile.m:134

Any idea why it crash when initializing the OZZipFile ? Thanks in advance.

Several possibilities, but one thought: You're not specifying a full path; try [[NSBundle mainBundle] pathForResource:@"test" ofType:@"zip"] if this file is in your bundle, or the full path if you've downloaded it.

Hello @evands, I made sure that the zip file is there.


System.Reflection.ReflectionTypeLoadException

I am getting, just started yesterday: "Send-TeamsMessage - Execute System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information." Any idea what has changed? Thanks.

I'm receiving the same error as well.

I was replying to the other e-mail about the critical issue logged, should I continue?
From: Albert<EMAIL_ADDRESS>Sent: Monday, October 7, 2019 11:04 AM
To: mhouston100/PSMicrosoftTeams<EMAIL_ADDRESS>Cc: Michailidis, Tony<EMAIL_ADDRESS>Author<EMAIL_ADDRESS>Subject: Re: [mhouston100/PSMicrosoftTeams] System.Reflection.ReflectionTypeLoadException (#8)
I'm receiving the same error as well.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mhouston100/PSMicrosoftTeams/issues/8?email_source=notifications&email_token=ALF3XMK5IPY2ZVYNIWVUBG3QNNFUVA5CNFSM4I5TO25KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAQVO6A#issuecomment-539055992, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ALF3XMPBDQ3U6WAIS4QCW43QNNFUVANCNFSM4I5TO25A.

I opened a ticket with azure support, lets see.

Was a long weekend here in Sydney, just getting to this now.
I have not experienced this at all in our environment, our notifications continued to come through over the weekend.
Is there anything specific regarding your environment that might be affecting it?

Nothing I can think of has changed. Actually it stopped working while I was testing a new runbook that is using it. Perhaps it is Teams related and data center specific? I assume by Sydney you mean down under? We are up north (waaay north lol). Will monitor it and see what comes up. Do you by any chance know anyone else in North America who is using this project or directly calling "Invoke-RestMethod -uri  -Method Post -body $body -ContentType 'application/json' ? Cheers - Tony.

Same problem here in The Netherlands currently. Looks like a rolling update of some kind which is causing this issue.

It appears to be working today, All: try again. Thanks - Tony.

Not yet working for me here in the Netherlands, but I'll give it some time.

Not yet working here in California either. And its not just this code, its something on Teams side. I wrote a very simple webhook for teams that was working Friday, and it stopped working as well.

It appears to be working again today in The Netherlands, so seems to have been a global issue.

Started working again last night in California.

I'm going to close this off as it was service related


Problem with Gaufrette 0.1.9

First of all, I cannot thank you enough for such a great bundle.
Secondly, I'm not sure if this is a Gaufrette's or an OneupUploaderBundle's bug. What I mean is that Gaufrette might have made a breaking change or that OneupUploaderBundle is misusing Gaufrette, so maybe that's the main question.
Now about the problem:
After updating a project to Gaufrette 0.1.9, upload stopped working. I noticed that the oneup_uploader.post_upload event was receiving a File pointing to the "chunked file" instead of the actual finished file.
After digging a bit I suspect the problem could be somewhere near Oneup\UploaderBundle\Uploader\Storage\GaufretteStorage at line 33:
$file->getFilesystem()->rename($file->getKey(), $path);

return new GaufretteFile($this->filesystem->get($path), $this->filesystem, $this->streamWrapperPrefix);

What happens is that after renaming the file on line 33 the new GaufretteFile of line 35 receives the previous, apparently cached, File instance from $this->filesystem->get($path), but I don't know if this is the expected behavior or not.

Hello,
I have same problem. After upload last chunk and Gaufrette rename file, new key isn't accessible. New key is in fileSystem->fileRegister but fileRegister is protected. How is possible i can access in final key in event oneup_uploader.post_upload.gallery

Thank you !


Support BR GPU

Thanks for your contribution and we appreciate it a lot. The following instructions would make your pull request more healthy and more easily get feedback. If you do not understand some items, don't worry, just make the pull request and seek help from maintainers.
Motivation and Context
This PR adds support for BR GPU
Description
This PR consists of,

add supa option for compile system
add device support for biren device.
add a new api for replacing storage requried by HW.
fix some typo in readme

Use cases (Optional)

BC-breaking (Optional)

Checklist
Before PR:

[ ] I have read and followed the workflow indicated in the Contributors.md to create this PR.
[ ] Pre-commit or linting tools indicated in Contributors.md are used to fix the potential lint issues.
[ ] Bug fixes are covered by unit tests, the case that causes the bug should be added in the unit tests.
[ ] New functionalities are covered by complete unit tests. If not, please add more unit test to ensure the correctness.
[ ] The documentation has been modified accordingly, including docstring or example tutorials.

After PR:

[ ] CLA has been signed and all committers have signed the CLA in this PR.

 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.


[Provider] Add support for Lepton AI

What Would You Like to See with the Gateway?
https://www.lepton.ai/docs
Context for your Request
No response
Your Twitter/LinkedIn
No response

@vrushankportkey  Please assign me this issue.

Hi @nikhil-kumar94 please go ahead!

@vrushankportkey assign to me

Please go ahead!

@PentesterPriyanshu are you working on this?


Typo in WWW-Authenticate

It seems from the example below and https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/WWW-Authenticate that it should be - and not _
It came out of me praising the HTTP responses in the docs on Twitter, btw, which I think are fantastic.
https://twitter.com/larsw/status/1722163225586704789

@DougKlopfenstein, @bezhan-msft
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

#sign-off


Allow for bash & zsh specific .programs.zsh.

Recently I seem to have trouble with the value of HISTFILE being the same for zsh/bash while the format of zsh history seems to have changed (not sure if it's because of my configuration or a zsh update, now it seems to prepend a timestamp):
:<PHONE_NUMBER>:0;git fetch -a channels && git rebase channels/nixpkgs-unstable
but even without that I prefer to have bash and zsh use different HISTFILE(s).
WOuld you be ok with a "variables" options specific to zsh or bash that write into .zshenv for instance. I can contribute.

I think it would be nice to have something like programs.zsh.sessionVariables, programs.bash.sessionVariables to put there variables specific to this shells and to use home.sessionVariables for more general stuff. My understanding is that if for example home.sesssionVariablesSetter == "zsh", then everything from home.sessionVariables will be merged into programs.zsh.sessionVariables and added to .zshenv file.
@rycee do you agree with that?

@uvNikita Yes, I think that is a good solution. I'm happy to add such an option for the bash module, I'll leave the zsh one for you :-)

That said. I don't see why the Zsh and Bash history files end up being the same. The bash module doesn't set HISTFILE so it should end up being the default ~/.bash_history. The zsh module seem to set HISTFILE to $dotDir/.zsh_history. So they should by definition keep separate histories… @teto Did you set HISTFILE yourself anywhere?

I also added the sessionVariables option in Bash so now it should be straightforward to set them independently. I still don't understand how Bash and Zsh ended up writing history to the same file in the first place, though.
@teto Please close this issue if you feel it has been resolved, if not please add a comment. I'll close the issue in a few days if nothing further is added to it.

Thanks for the job  uvNikita !
Sorry I was unclear the problem with HISTFILE didn't lie with home-manager in the first place, I had it as a sessionVariables in my configuration.nix and this was part of the reason of why I wanted to move some aliases to home-manager (it would also create problems when logged as root).
I have a bonus question/suggestion. I have ZDOTDIR set in my configuration.nix. Is there any way home-manager could pick it up ? I don't think it could run zsh and echo $ZDOTDIR as that might bring impurity but maybe it could pick it up from environment.sessionVariables ?

There is programs.zsh.dotDir configuration option in home-manager which might be suitable for your case:
https://github.com/rycee/home-manager/blob/12ebf21be523eaf6db1f19b5a6b9304e99540961/modules/programs/zsh.nix#L136
It sets ZDOTDIR variable for you and places all relevant to zsh configurations inside the specified directory. I don't think it is possible to reference values from the system configuration in home-manager at this point, but @rycee know better about this.

I know that one but it should be possible to bypass it. Also if one sets $XDG_CONFIG_HOME, there must be way for home-manager to get it otherwise it will generate files in unused locations. This is a problem I hit when I tried creating a notmuch module.

To access your system configuration you can use (import <nixpkgs/nixos> {}).config. For example,
home.file."nixoscodename".text = (import <nixpkgs/nixos> {}).config.system.nixosCodeName;

Also, right now Home Manager mostly assumes that your XDG variables are set to their default. E.g., that XDG_CONFIG_HOME is set to ~/.config.

I close this since the problem at hand is more generic.  Thanks for the interesting snippet.


[Languages] Building a Bookshelf Web Application with Django REST Framework and React.

Proposal Submission
How to build a bookshelf application with the Django REST Framework and React Js
Proposed title of article
Building a Bookshelf Web Application with the Django REST Framework and React.
Proposed article introduction
The Django web framework allows us to build web applications quickly with a lot of tools provided. It simplifies how applications interact with databases. It is very modular, scalable, and with its MVT pattern, you can deliver quickly.
However, as time goes by, people are getting used to the idea of a more interactive UI. Building the front-end part with only Django templates is not enough; hence, other frameworks like React Js are needed. React is a component-based JavaScript library that enables you to build your framework quickly and efficiently.
This article will cover much concerning both the Django and React Js frameworks and how to implement a bookshelf application using the Django Framework Rest APIs with React Js. We will use the REST API for retrieving, creating, deleting, and changing the state of books with the React framework, which is used for the front-end design. With this app, you can keep track of books that have been read and those that have not been finished yet.
Key takeaways
From this article, the reader will be able to:

Understand how Django works with the REST Framework API.
Understand how to build a Django rest API using the Django Rest Framework.
Get to know how to combine Django with React Js.
Be equipped with the knowledge of how Django Rest APIs and React combined can be used in implementing a Bookshelf Web Application for managing the books read and those yet to be finished.

Article quality
This article will be of high quality and be of great help to the reader. It will not only cover how Django and React can be used in web applications, but how we can integrate the Django REST Framework into building a bookshelf application. This application will help manage a high number of books to be read.
References
N/A
Templates to use as guides

How To Guide Template
Software Review Template
Tutorial Template

Good afternoon and thank you for submitting your topic to the EngEd program.
After some careful consideration it struck us that this topic may be a bit over saturated throughout other blog sites and official documentations. We typically refrain from publishing content that is covered widely on the net or other blogs. We're more interested in original, practitioner-focused content that takes a deeper dive into programming-centric concepts.
But in order to approve the topic it has to serve value to the larger developer community at large. Please feel free to suggest an alternate topic to explore. 🚀
An option and a great way to write this as an in-depth article and make it more add value to the greater developer community at large would be to walk the reader through the USE of methods and functions by building a unique, different, useful project.
If you believe your article is unique enough - please present your case to explain how it will be different from what is currently out there?
https://www.google.com/search?q=Bookshelf+Web+Application+with+Django+REST+Framework+and+React&rlz=1C1CHBF_enUS891US891&sourceid=chrome&ie=UTF-8


Adding DeletePipeline API call and test

Hi, I needed the DeletePipeline functionality and added it. Would be great to have it included upstream.

LGTM! Thanks @aha!

Thanks :+1:


Degree of Connectivity

Can you please add an option to "increase" degree of connectivity when ERD is generated for a table?
Currently I see only nearest "neighbors" are generated in ERD when a table is viewed (1st degree of relationship).
It would be very helpful to see tables that are further on the ERD graph (e.g 2nd degree, 3rd degree).
However, please leave default behavior as it is now, and have an option of extra connections only as needed.

@YuriDude Thank you for the suggestion


Module not found Error Occurs in nextJs14.0.3

Hi @OvidijusParsiunas thanks your deep-chat.
Description:
I'm using deep-chat on my website and I encounter Module not found Error when I bump next from 14.0.2 to 14.0.3.
plz tell me how to fix it.
import dynamic from 'next/dynamic';

interface BotButtonProps extends React.HTMLProps<HTMLElement> {
  t: TFunction;
}
const BotButton = ({ t }: BotButtonProps) => {
  const DeepChat = dynamic(
    () => import('deep-chat-react').then((mod) => mod.DeepChat),
    {
      ssr: false,
    },
  );

./src/components/BotButton.tsx
Module not found: ESM packages (deep-chat-react) need to be imported. Use 'import' to reference the package instead. https://nextjs.org/docs/messages/import-esm-externals

https://nextjs.org/docs/messages/module-not-found

Environment:

Browser: Chrome version 119.0.6045.200
nextjs version: 14.0.3
Node.js version: v19.1.0

Hi @humuhimi.
I tracked the recent issues in the Next repo and it appears that this is a bug that was introduced in the 14.0.3 release. Fortunately they have merged a fix for this yesterday in the following PR and it is now in the Canary branch which will be released in 14.0.4. I am personally not sure when this version will exactly be released, but it should be soon.
You can probably use the 14.0.4-canary.43 version instead - but keep note that this is experimental. You can check here for all other available versions.
Because this is an issue on the NextJs side it should be tracked in their resources and I will be closing this issue.
Thankyou for letting me know about this @humuhimi!

thank you! I will waiting for it!


Fix multiple python related issues

cwrapper generator to handle scenario when multiple
IDL files are using the same compound structures (list<...> etc.)
pycffiDynamicLibList attribute to properly expand required fields
for proper CFFI linkage
python code to be used with python3
support-lib related to python to use environment variable instead
of hardcode for getting "ffi" and "lib" attributes

Automated message from Dropbox CLA bot
@steweg, it looks like you've already signed the Dropbox CLA. Thanks!

Looks like there are conflicts to resolve (possibly with your other PR which I just merged).
Also, can you re-run the generators for the example and test-suite so I can see the results?  I'm guessing the changes here should have some visible effect, though if not I'd encourage you to add new test cases which demonstrate the fixes you're making here.  You should be able to run "make all" from the root dir, which will regenerate everything and run all the tests to validate everything works.
Note that I don't generally recommend committing generated files to source-control in most projects, but in the Djinni repo we commit generated files to GitHub because they ease the code-review process, and helps show the impact of a change to the generator.

Hi, I have rebased the patchset. I was trying to also regenerate the generated files, but unortunately I was not able to do so as "make all" or "make python" requires xcodebuild command, which I don't have on Debian (or any other Linux except MacOS). Can you suggest some idea how to do that?

Xcode is only required for the iOS portions of the build, so you should be able to run everything else, though there's no convenient make target for that.  Since you're working on changes which only affect Python you should be able to do something like this:
make example_python
make -C test-suite python

Unrelatedly, I started glancing through the code, and would like to hear more about the rationale behind the new environment variable.  I'm not comfortable with the support library requiring an environment-variable to be set in order to be funcitonal, since that seems very fragile.  It seems like there should at least be a fallback option if the variable is not set.  But I'd like to understand better what use case the variable is for so I can consider whether there's an alternative I might suggest.

Hi,
make example_python requires xcodebuild (very strange dependency from my point of view): Relevant snippet from Makefile:
./build_py/cffi/libtextsort_py.dylib: ./build_py/example/libtextsort.py.xcodeproj/project.pbxproj
        xcodebuild -project ./build_py/example/libtextsort.py.xcodeproj \
           -target libtextsort_py \
           -configuration 'Debug' \
           ONLY_ACTIVE_ARCH=NO
        mkdir -p ./build_py/cffi
        cp example/build/Debug/libtextsort_py.dylib ./build_py/cffi/libtextsort_py.dylib

example_python2: ./build_py/cffi/libtextsort_py.dylib
        ./example/run_py_example.sh python

example_python3: ./build_py/cffi/libtextsort_py.dylib
        ./example/run_py_example.sh python3

example_python: example_python2 example_python3

The other command ended up in the similar situation, when in file test-suite/PyCFFI.mk, it is expected to use "-arch" and "-dynamiclib", all of them are related to building of C/C++ for OSX. These options are not recognized on linux platforms (I am using gcc version 4.9.2 (Debian 4.9.2-10))
So the testing scripts are written in a way that I am not able to test them at all (without major rewrite and as such breaking the whole point of testing). This might need to be done in by someone who understood better than I do, how to the whole testing part should work.
Now back to the environment variable. The whole problems are the lines of hardcoded code within pport-lib/py/djinni/exception.py and support-lib/py/djinni/pycffi_marshal.py files. They simply expect that there will be python library with name PyCFFIlib_cffi (in the file system this is PyCFFIlib_cffi.so). This library is actually result of command from example/run_py_example.sh :
$python_cmd" $cffi_out/pycffi_lib_build.py $wrapper_marshal ${cffi_dep[*]}
The problem with that is that particular command creates as SO file, but named based on "--pycffi-package-name" attribute. In your tests this attribute is always set to PyCFFIlib (see file example/run_djinni.sh), so in your particular case it works without any error. If you change that attribute, you will see that it will fail.
As removing such include/imports is not an option, to solve this problem, we could either adjust the support-lib files to use environment variable, which will point the include to the right places (as I did in current patchset) or move those two files to not be part of hardcoded support-lib and rather add them as auto-generated files (this seems to me to be much more complicated solution, but from long-term solution might be more suitable).

Oops, sorry for misleading you on the tests.  I forgot some of the shortcuts which were taken to finish Python support for CppCon last year, one of which was building in the most expedient way for Mac only.  That shouldn't keep you from being able to do the generation phase, though, which should run on Linux (there are other Linux users of non-Python languages who have done so).  Try these commands:
make run_example_djinni
cd test-suite && ./run_py_djinni.sh

That should allow us to see the impact of your changes on the code generated by the example and the test suite.  However, if you plan to contribute significant changes to Djinni I'd encourage you put some time into making sure you can run the test suite on your platform, since otherwise it'll be hard to add new tests to validate your changes, as well as check for regressions.  The test suite's python build is done with a Makefile (not xcbuild) so it you shouldn't have to change the overall structure, but you'll have to add some conditionals for arguments, replace the dylib with a .so, etc.  I don't actually know the behavior and requirements of CFFI for loading libraries on Linux, which is why we didn't take a stab at it earlier.  But since you're clearly working on that, you're in a good position to figure it out. :)
I'll respond separately to the discussion of the environment variable.

Okay, I understand the issue behind the env var too.  Another shortcut taken, and not caught since in the initial release we didn't have more than one use case.  The ability to customize the ffi and lib objects is something we had on our backlog, though we were thinking of it as a way to support more than one Djinni-generated module in the same process, rather than the issue you discovered.
I don't like the environment variable as a solution in particular, because it's a process-wide global state, which both requires very global knowledge for users of the app which includes a Djinni library, and also won't scale well if we do get to the point of supporting multiple Djinni-generated modules in the same Python process.  Turning these support-lib helpers into generated code would fix it, and the complexity might be limited if the generation was a simple case of reading a template file and replacing some variables.   However a simpler solution would be better for your immediate needs.  An ideal solution might be to pass around the ffi and lib variables from generated code as extra arguments, but that might also require a lot of changes.
One idea: Consider placing the ffi and lib variables into globals which generated files could pre-populate as they're loading.  Imagine if the generated python files had something like this at the top:
from WhateverPyCFFIlib_cffi import cffi, lib # This line can use the configured name from generation
from djinni.cffi_lib import init_cffi_lib
init_cffi_lib(ffi, lib) # The first call to this stores the variables in globals for later use.
from djinni.support import pycffi_marshal

Then the support lib would simply import from an alternate location:
from cffi_lib import ffi, lib

It's still a global approach, but it's within Python not a hidden thing at the OS level, and easier to tweak later to support different options.  What do you think?

Sorry for late reply, I agree with your last proposal, I will test it and possibly adjust the patchset

Sorry for late reply, I am currently completely overwhelmed by other work, so I will test it as soon as possible (hopefully in Feb 2017)

I am cancelling this PR, as in the end we end up in situation that even with proposed patch, the generated files were not suitable for our purposes. To explain why:

the CFFI generated python script is targeting to create SO file, which needs to be linked with already existing C++ SO that provides implementations of given djinni interfaces
the CFFI generated python script also expects that the name of CFFI wrapper will be already known during generation of djinni files

What we need is actually the exact opposite:

We need CFFI python file to generate STATIC library, that can be bundled with our C++ SO library and being shipped easily within the same package.
We need to define the CFFI wrapper name based on definitions that are coming during building phase of our C++library (we have about 5 different products coming from the same set of sources)

Achieving the static library is not possible to be done within python CFFI, therefore we are still using the CFFI generated python script to generate the wrapper source files, but we are not linking it by python, but rather directly g++/ld tools. To achieve the correct CFFI wrapper name, we are simply replacing the predefined string within the files with correct one using sed command
Anyway I opened another one, which is still valid for python part for any kind of usage

Understood.  The build/packaging part of the Python prototype was something we knew needed some more work and had some assumptions in it.  It sounds like if/when that's tackled it should be made to be more generic, generating code but then leaving the details of compiling/linking that code up to the developer, which is more similar to what we do for other languages.  Sounds like you've found a way to make it work, though, so I'm glad of that.  I'll take a look at your new PR.


Google+ will be deprecated on March 7, 2019

See announcement on https://developers.google.com/+/api-shutdown

On March 7, 2019, all Google+ APIs will be shut down. This will be a progressive shutdown beginning in late January, with calls to these APIs starting to intermittently fail as early as January 28, 2019.

This project is using the plus.login scope which will fail after March 7, 2019

I'm about to use this library on a new project, so just open this PR https://github.com/simmatrix/vue-google-auth/pull/20 addressing this issue.
Tested on my new project and everything continue working as expected.

For those looking for an alternative, I've switched to https://github.com/rmartide/vue-google-login with success


✨Merge Sorted Lists in C++

hi @strivedi4u ,
I would like to implement cpp solution of this below leetcode question.

21. Merge Two Sorted Lists
https://leetcode.com/problems/merge-two-sorted-lists/description/

Problem Description
You are given the heads of two sorted linked lists list1 and list2.
Merge the two lists into one sorted list. The list should be made by splicing together the nodes of the first two lists.
Return the head of the merged linked list.
Please assign this issue to me under Hacktoberfest-2024. Thank you!

I would like to solve this problem....

🚀 Follow me, 💬 Join the WhatsApp Group, and ⭐ Star the Repo to support our journey together!

Can i contribute to this


[Compatibility Request] Exclude Chat Portrait avatar from /as messages

I believe it can be pretty distracting to have an unrelated player avatar next to in-character messages, so I suggest giving /as messages the same treatment as /desc
Example of what /as messages look like right now:

What it would ideally look like with this change implemented:

Latest versions of Foundry, dnd5e system, libwrapper, Chat Portrait and CGMP used for testing.

a8d64d3607f6445e0374af4707b89fab6f92b6d3


REST API: Artifact versions are ordered by name, not by release date

What are you trying to do?
Get the latest version of an artifact using the REST API https://search.maven.org/solrsearch
It appears that artifact versions are ordered by name, not by release date. E.g. commons-io:commons-io has a version 20030203.000550 released in 2005, the latest version is currently 2.8.0 released in 2020.
While 20030203.000550 is a higher version according to the Maven Version Order Specification, it does not indicate anything about the release date.
Yet the API documentation at https://search.maven.org/classic/#api says "most recent version released", similarly the API response field is called latestVersion. However it actually returns the highest version, e.g. for commons-io that is 20030203.000550.
Example API requests:

https://search.maven.org/solrsearch/select?q=commons-io&rows=30&wt=json
https://search.maven.org/solrsearch/select?q=g:"commons-io"&rows=20&wt=json

Interestingly https://search.maven.org/solrsearch/select?q=g:"commons-io"+AND+a:"commons-io"&core=gav&rows=25&wt=json does sort by release date and not version name (though this is not clearly documented).
How could we solve this issue? (Not knowing is okay!)
There are probably multiple ways to solve this:

Return the latest released version instead of the highest version.
Maybe there are projects where this is not desired, e.g. when there are multiple release branches 2.x and 3.x but the application would always like the 3.x artifact be returned as latest, even if a 2.x artifact was published more recently.
Keep the current behavior, adjust the documentation, but add a URI parameter for determining the sort order.
(Note: The API response already shows a sort field, but I was not able to overwrite that.)

Anything else?
Other projects depending on the API might have to be updated, e.g.: https://github.com/softwaremill/maven-badges

Hi @Marcono1234 check out https://github.com/sonatype-nexus-community/search-maven-org/issues/149 it is related. You should be able to sort on the following fields score desc,timestamp desc,g asc,a asc,v desc but I don't think you can.
The solr documentation provides more information.


Incorrect user input should not cause exceptions

Invalid user inputs are not exceptional situations, and should not cause exceptions.
Also, it is preferred not to throw exceptions from constructors.

Closing. We've decided it is ok to use exception to indicate user errors.


Would you mind adding a copyright / license header to index.ts?

Thank you for authoring this library! I'd like to start using it in my work but want to make sure that we're attributing it correctly.
Can you please add a short copyright notice to the index.ts file?

Some examples:
// Copyright 2022 [name of copyright owner]

/**
 * Copyright 2022 [name of copyright owner]
 * @license Apache-2.0
 */

Sorry, my reply to this didn't seem to get sent. I don't have any particular objection to this, but do you have an article/blog post explaining why this would be needed? I'd have thought the Apache license would be sufficient, and from a quick look at a random selection of other OSS repos, most don't have one baked into the actual code. Is there a tool you use that scans code for headers like this for an attribution page, or something?

Yeah I agree with you. Most OSS does not do this.
When pulling in open source projects into my employer's codebase, we have a policy to add a @license block to the JS/TS files via some automation. We also specify the copyright in these comments. I didn't see any copyright for this project though so wanted to clarify on the status there.
At this point, I don't think this matters a ton for our particular usage of expect-type.

I don't think I'll do this in that case!


[[CHORE]] Remove commented out code from scope manager

spotted this reviewing your PR @jugglinmike

Merged at 16f5779c04204f5127a3f1f85d6031f01dcabc00 . Thanks!


ImportError: cannot import name 'get_local_rank'

🐛 Describe the bug
When importing super_gradients, an error occurs: “ImportError: cannot import name ‘get_local_rank’ from ‘super_gradients.common.environment.ddp_utils’”.
Versions

Hi @gufeng745
Could you please share the version of super_gradients that you are using?
Besides, it would help if you could also show

how to reproduce (minimal snippet of code that you run and that leads to this crash)
Full error traceback (not just the line with ImportError). If you can copy/paste the code inside "```" it would increase readability :)

Thanks

super-gradients==3.2.1

Updating SG to 3.3.1 should fix the issue


my_init one-shot command exits with OOMKill, but container still reports successful execution

Application Base Image: phusion/passenger-customizable:0.9.35
Image digest: d1d611f7ba99
The baseimage-docker documentation for running "one-shot" commands indicates that one should probably use the /sbin/my_init -- COMMAND ARGUMENTS form to run one-shot commands to ensure that "important daemons such as cron and syslog" are running and to avoid orphaning child processes.
We use this form to execute "one-shot" commands during our deployment process. Specifically we have a Rails application on which we run database migrations and data transformations as a pre-deployment step. The application shipped a faulty migration which caused the container's bin/rails db:migrate process to be OOMKilled. The bin/rails db:migrate process exits with status 137 (OOMKilled), however the container exits with status 0 (Succeeded). This creates a confusing scenario where the container fails to run the application process it was asked to perform, but the container reports that it was successful. In our case, this causes deployments report as being "successful" even though they should have been "failed" and halted because the migration process was OOMKilled. This resulted in the deployment of application state for which the database schema was NOT present.
For context, I've found this potentially related - seemingly stale - issue which seem to fit what I see as the general pattern - some one-shot container runs a process managed by my_init fails, but my_init reports a "Succeeded" status code:

https://github.com/phusion/baseimage-docker/issues/420

You should be able to catch the failure in your script and then kill PID1 to cause a non-zero exit code.

@Theaxiom , thanks for the reply.
The above example, I'm using the "one-shot" command form as documented in the README: /sbin/my_init -- COMMAND ARGUMENTS. I've been using this to run one-shot commands / scripts which I do not own, such as bin/rails, yarn, etc. I believe the suggestion "You should be able to catch the failure in your script" infers my_init assumes that COMMAND is always some script which I own if I want to make sure my_init will have an appropriate exit status?
 This assumes that I only ever run said COMMAND / script in an environment where my_init is PID 1 - essentially the COMMAND / script needs to KNOW that it's ok to kill the init sytem. At the very least, this limits the usefulness / reusability of such "scripts", and at worst could prove harmful if such a script is run in a context where my_init is NOT PID 1. Does that make sense?
The above concerns aside, it seems like the issues described in https://github.com/phusion/baseimage-docker/issues/420 would STILL present a problem, no?


multiple kourier installations in same cluster?

I do have use-case that I would like to install two isolated kourier installations to same cluster. One kourier for internal network stuff and one kourier to external network stuff. It seems that its possible to define ingress class to knative service with networking.knative.dev/ingress-class. However, is there somekind of way to define kourier which ingress class its going to listen?  So basically I am trying to do something similar than in nginx https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/

seems that this is hardcoded https://github.com/knative-extensions/net-kourier/blob/ae3d06f806e041907edf15002686d3b6597e1523/pkg/config/config.go#L62 ? Is there some blockers to make that editable?

looks like working:
% curl http://knativetest.domain.com
Hello hello internal!
% curl http://knativetestext.domain.com
Hello hello external!
% host knativetest.domain.com
knativetest.domain.com has address 10.x.x.x
% host knativetestext.csf.elisa.fi
knativetestext.domain.com has address 193.x.x.x

https://gist.github.com/zetaab/b45dfada89e7fa82970d554b24fe4968
internal kourier:
https://gist.github.com/zetaab/01afc94a2128bb7ca46d37b66e2edc96
external kourier:
https://gist.github.com/zetaab/5348d4f7f3128494c9e27a1cf97bd438

Knative ingress classes are a bit different from K8s. You use this setting to select between using istio, contour or kourier. So there is really no need to override an ingress class in kourier.
This is also why this is hardcoded. Knative uses the constant at various places to select the correct ingress solution to configure.

@ReToCode  but my use case is to support two different incoming loadbalancer networks. So basically it means that I can run kourier only to external or internal network not both. So I need to then use istio or contour to another network. For me this sounds interesting. Or is there way to support kourier from two different loadbalancers?

seems that knative itself cannot quite easily support multiple "ingress-class". So we cannot basically have 2 different networks in same cluster.


Fix for import order for ticket #61 to fix running tests

Moves the adding of the parent directory to the python path to above the import of oauth2 module.
Means tests can be run against the module without installation. This closes ticket #61

@bassdread thanks for the PR. Tests should run now via py.test. We're using Travis-CI now as well. Tests are humming along over there.


Tracer to depict addition of nodes in binary search tree

Added trace steps to show addition of nodes and how tree is traversed while adding a new node. This will help in resolving issue #213 in my opinion. Please review and let me know your feedback.
Thanks,
Raj

Brilliant idea and implementation.
I appreciate your contribution.

Thanks :)


bugfix: fix overflow for rate limit

Ⅰ. Describe what this PR did
fix the overflow for rate limit
when use the function createTokens it may return negative number because of the overflow
The problem code is here diff/(rl.window*time.Millisecond.Nanoseconds()) * rl.ratePerWindow.
When createTokens return negative number it may cause sleep and it will make p2p download failed.
use int64 instead of int32 can solve this problem
Ⅱ. Does this pull request fix one issue?

Ⅲ. Why don't you add test cases (unit test/integration test)? (你真的觉得不需要加测试吗？)
Ⅳ. Describe how to verify it
Ⅴ. Special notes for reviews

Codecov Report

Merging #724 into master will not change coverage.
The diff coverage is 72.22%.

@@           Coverage Diff           @@
##           master     #724   +/-   ##
=======================================
  Coverage   47.38%   47.38%
=======================================
  Files         109      109
  Lines        6293     6293
=======================================
  Hits         2982     2982
  Misses       3077     3077
  Partials      234      234

Impacted Files
Coverage Δ

...t/core/downloader/p2p_downloader/p2p_downloader.go
0% <0%> (ø)
:arrow_up:

dfget/core/uploader/peer_server.go
86.84% <0%> (ø)
:arrow_up:

common/util/limit_reader.go
0% <0%> (ø)
:arrow_up:

common/util/assert.go
97.43% <100%> (ø)
:arrow_up:

common/util/rate_limiter.go
89.85% <84.61%> (ø)
:arrow_up:

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 7eb39ea...8526900. Read the comment docs.

Thanks a lot for your great work. Does this pull request fix issue https://github.com/dragonflyoss/Dragonfly/issues/704? @wybzju

@allencloud  I don't think so. I have encountered this issue #704, and when I retry, it can be fixed. And in other test case, I meet the same problem, for example TestQueue_infiniteQueue.
I think this issue is because the time error is only 10ms, and sometimes if the machine is high load, the issue may be reproduced. If we change 10ms to 20ms for example, the probability of reproducing this issue will be much lower.  But, I don't think this is a bug.

LGTM.