aseprite: 1.3.6 -> 1.3.7

Description of changes

Update version
Update dependencies: tinyxml -> tinyxml-2, pcre -> pcre2
Add patch to use the shared fmt library
Add translations
Use clang as it's recommended and better supported by upstream (and seems to compile faster)

Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

error: hash mismatch in fixed-output derivation '/nix/store/z99v2pjxv92y0bm27wiyrhqqycqwjwdv-source.drv':
         specified: sha256-75kYJXmyags0cW2D5Ksq1uUrFSCAkFOdmn7Ya/6jLXc=
            got:    sha256-vbPrH2MXU95DAKv5w64N5vdsBPpeNu657VrXCwhUDf8=

@pbsds oops. Try now

Would you be willing to adopt this package?

I am very impressed with your changes, would you be willing to adopt this package?

Sure!

Then please add yourself in maintainer-list.nix with a commit titled maintainers: add <user> which preceeds the version bump, then add yourself to meta.maintainers and squash the package commits

Suggestions:

use nixfmt formatter (named nixfmt-rfc-style in unstable)
move package to pkgs/by-name/as/aseprite/ (requires removing reference from pkgs/top-level/all-packages.nix)

I actually made most of those changes at first but didn't want to produce a huge diff. But if I have your OK for it then I'll move forward with those.
Also, it seems that aseprite's skia isn't in the binary cache, is it? If so, what'd be the way to enable caching for it?

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

1 package failed to build:

aseprite

I actually made most of those changes at first but didn't want to produce a huge diff. But if I have your OK for it then I'll move forward with those.

Please go ahead with changes I listed. Such as, ordering by phases order is the usual way to organize the derivation.

Also, it seems that aseprite's skia isn't in the binary cache, is it? If so, what'd be the best way to enable caching for it? Make it a separate package?

Packages from top-level are cached by default. Likely Skia needs to be packaged in separate (and shared by many packages). Several packages/applications use Skia, but it seems, each one uses it's own skia version. I don't know why this needs to be like that and can't be packaged globally.

Is it failing build for you too?

Seems this is because I disabled fetchSubmodules, and the patch is applied to a submodule. But just enabling fetchSubmodules clones a lot of unnecessary stuff that isn't used. Is it possible to fetch only that submodule?

Is it failing build for you too?

Seems this is because I disabled fetchSubmodules, and the patch is applied to a submodule. But just enabling fetchSubmodules clones a lot of unnecessary stuff that isn't used. Is it possible to fetch only that submodule?

Disabling fetchSubmodules is good. Check if dependency doesn't exist already in nixpkgs. On existence, if necessary, override patch there. If doesn't exist, it's possible to package it as a Nix package.
Also, consider adding skia to passthru. Such that, you can build/test in isolation.

I think the cleanest way forward is prob to make skia-aseprite and laf into separate packages. Can I do it all in this PR or is it more idiomatic to open separate PRs?

I think the cleanest way forward is to make skia-aseprite and laf into separate top-level packages. Can I do it all in this PR or is it more idiomatic to open separate PRs?

Feel free to do it in this PR, in different commits though.
On commit order, order dependencies first, downstream packages at last.

Turns out there's way too much vendoring going on, so I'll leave the submodules alone for now. It's doable to make them behave but too tedious

Turns out there's way too much vendoring going on, so I'll leave the submodules alone for now. It's doable to make them behave but too tedious

No problem. You have made a lot of progress here already.

CI errors as:

pkgs/by-name/as/aseprite: File package.nix at line 92 contains the path expression "./shared-skia-deps.patch" which cannot be resolved: No such file or directory (os error 2)

I've noticed Skia has only 8 commits ahead of upstream. It's possible to attempt to use upstream Skia and apply these 8 patches over it. I haven't looked into it. But this can unify Skia if it works.

nixpkgs-review errors as:

pkgs/by-name/as/aseprite/shared-skia-deps.patch': No such file or directory

Yeah sorry, the patch error is cause I forgot to add a file

Can the update-deps.sh script for skia-aseprite be made to run together with the gitUpdater?

Can the update-deps.sh script for skia-aseprite be made to run together with the gitUpdater?

I don't know the perfect solution. If you make a script triggering them both I expect it to work.

All suggestions applied

Can the update-deps.sh script for skia-aseprite be made to run together with the gitUpdater?

I have not tested. I suggest to use bash to execute the two different routines. For fetching dependencies.
This currently errors:

nix-shell maintainers/scripts/update.nix --argstr package skia-aseprite

This works:

nix-shell maintainers/scripts/update.nix --argstr package aseprite

Please verify skia-aseprite update script execution, I suggest to run:

nix-shell maintainers/scripts/update.nix --argstr package skia-aseprite

Reworked the script, it updates both the package and deps now, and this command works

I've done a few other tweaks like making update.sh update the hash as well. I think this is good to go now

Thank you for all the help!


Adding Unit tests to nsm-init

This PR adds unit tests to nsm-init code.
Signed-off-by: Serguei Bezverkhi<EMAIL_ADDRESS>

@mestery CI is green, please merge when you have a chance..


Speed limits: Allow lanes/roads to be clicked (not just icons)

Currently, when changing speed limits, I have to click the icons to apply the change to a road/lane.
Would be great if I could just click the road side (direction mode) or lane (lanewise mode).

Agreeing with this, as it can make it much easier to set speed limits in a hurry. Perhaps this same feature could be applied to the lane connector in some form?
Example: You've selected a node, but rather than having to click the tiny dot you just have to click the lane that the dot is on.

Lane connector already has that feature ;)

Closing this as it's tracked in #1221


Fix broken build in generator

Add -fcoroutines compiler option for generator target.
I guess that it works without this flag on your system, but this fix might be helpful for the majority of students. If there is a replacement for target_compile_options in ntc, I can use it (I guess that _ntc_try_append_cxx_flag is not applicable here because we need to specify a flag for a particular target).

Unconditionally adding -fcoroutines will break everything except GCC, which is not acceptable.
This is a general issue with gcc, not specific to this project, I've dealt with this in palebedev/ntc-cmake@4b01dd2933dbf609c3890964515b4423cf463a4e.

Unconditionally adding -fcoroutines will break everything except GCC, which is not acceptable.
This is a general issue with gcc, not specific to this project, I've dealt with this in palebedev/ntc-cmake@4b01dd2933dbf609c3890964515b4423cf463a4e.

Thank you!

Thank you!


Lucid Settings Page's Sub-Category Labels Overlapping with Border Lines

Do you have the latest versions of Spicetify, Spotify and Lucid?

[X] I'm using the latest versions of Spicetify, Spotify and Lucid

Is there already an issue for your problem?

[X] I have checked older issues, open and closed

Is your problem definitely caused by the theme?

[X] I have checked the app behavior without the theme and it is different

Environment & Computer Info
- Spotify version: Spotify for Windows (64 bit) <IP_ADDRESS>2.g01893f92
- Installed from: Spotify site
- Spicetify version: v2.38.5
- Color scheme: Dark
- Extensions: adblock.js, playOnYouTube.js, romaja_lyrics.js, romaji_lyrics.js, full-queue-clear.js, seekonscroll.js, keyboardShortcut.js, shuffle+.js, scannables.js, volumePercentage.js, playback-bar-waveform.js, beautiful-lyrics.mjs, theme.js
- Custom apps: marketplace
- Lucid installation method: Spicetify Marketplace
- Font: JetBrains Mono

Description
Sub-Category labels like Styles, Custom Background, Pages Setting, Border Settings texts are overlapping with other category's border lines ( I understand that overlapping with own border is a design choice, and that's not a problem ).
I guess it's related to parent elements' margin / padding.
Screenshots

i think this looks good

Yes, perfect 👌


Failed to load plugin flow: Cannot find module eslint-plugin-flow

I am having an issue where eslint doesn't appear to be using my local eslint in node_modules.
I'm trying to run JS Standard with Flow.
Please see screenshot.

When I try to run eslint via command line, it works as expected, see output:

...// appropriate linting errors here

✖ 6 problems (6 errors, 0 warnings)

I am using a local settings.json file:
{
  "javascript.validate.enable": false,
  "eslint.enable": true,
  "eslint.nodePath": "node_modules",
  "eslint.path": "./node_modules/.bin/eslint",
  "eslint.options" : {
    "extends": [
      "eslint:recommended",
      "standard",
      "standard-flow"
     ],
    "plugins": [
        "flowtype"
    ],
    "parserOptions": {
      "sourceType": "module"
    }
  },
  "standard.enable" : true,
  "standard.path": "./node_modules/.bin/standard",
  "standard.nodePath": "node_modules",
  "standard.options": {
    "parser": "babel-eslint",
    "plugins": [
      "flow"
    ]
  },
  "flow.enabled": true,
  "flow.path": "./node_modules/.bin/flow",
  "flow.pathToFlow": "./node_modules/.bin/flow"
}

with a local eslintrc.json file:
{
  "extends": [
      "eslint:recommended",
      "standard",
      "standard-flow"
     ],
  "plugins": [
      "flowtype"
  ],
  "parserOptions": {
    "sourceType": "module"
  },
  "parser": "babel-eslint",
  "rules": {
    "flowtype/boolean-style": [
      2,
      "boolean"
    ],
    "flowtype/define-flow-type": 1,
    "flowtype/delimiter-dangle": [
      2,
      "never"
    ],
    "flowtype/generic-spacing": [
      2,
      "never"
    ],
    "flowtype/no-primitive-constructor-types": 2,
    "flowtype/no-weak-types": 2,
    "flowtype/object-type-delimiter": [
      2,
      "comma"
    ],
    "flowtype/require-parameter-type": 2,
    "flowtype/require-return-type": [
      2,
      "always",
      {
        "annotateUndefined": "never"
      }
    ],
    "flowtype/require-valid-file-annotation": 2,
    "flowtype/semi": [
      2,
      "always"
    ],
    "flowtype/space-after-type-colon": [
      2,
      "always"
    ],
    "flowtype/space-before-generic-bracket": [
      2,
      "never"
    ],
    "flowtype/space-before-type-colon": [
      2,
      "never"
    ],
    "flowtype/type-id-match": [
      2,
      "^([A-Z][a-z0-9]+)+Type$"
    ],
    "flowtype/union-intersection-spacing": [
      2,
      "always"
    ],
    "flowtype/use-flow-type": 1,
    "flowtype/valid-syntax": 1
  },
  "settings": {
    "flowtype": {
      "onlyFilesWithFlowAnnotation": false
    }
  }
}

I am also using an empty flowconfig file with the vscode-flow link extension.

Closing this. I think eslint-config-standard is not supposed to be run with both JS Standard and ESLint, just ESlint.


Add Empty/Never

I believe Publishers.Empty handles these cases.

Hey Stephen, Thanks :)
Could you run ./generate.rb please?

Ah I don't have the repo checked out :) Editing on my phone. Also just added Timer.publish.

Ok, don't worry about it :) I'll merge and add it on my end.

I don't have the latest beta but is Timer.publish actually interval, or timer? Does it start emitting immediately, or only after the first timespan ?

I had a friend try the following code and it emits nothing:
Timer.publish(every: 0.1, on: .main, in: .default)
     .print()
     .sink { _ in }

Might be related to backpressure but I don't know much about it in Combine, yet. Have you tried Timer.publish ?


Add read transactions for leveldb

Note that this branch includes the change from:
https://perkeep-review.googlesource.com/c/perkeep/+/19266
Which says it's been merged, but hasn't hit GitHub (@bradfitz mentioned that the auto-sync had been turned off). Once that lands I'll rebase, but for now only the second commit is relevant.

The CI failures look like they're unrelated to this change.

Rebased.


Proposal for supporting subscription in graphql:Client

Description:
sub task of #3400
Describe your task(s)
Related Issues (optional):

Suggested Labels (optional):

Suggested Assignees (optional):

Proposal : #3560

Since this is moved to done in https://github.com/ballerina-platform/ballerina-standard-library/projects/139 can we close this issue? Pls create a different issue or update the title/description accordingly if there are remaining parts.
@shafreenAnfar / @MohamedSabthar


[question] Docker dev tag

Dev tag seems to be behind by a few days. It used to be cut daily so I'm just wondering if there was a change of plans.
Thanks for all your hard work.
Currently:
dev tag - App version 1.4.0, Zwavejs Version 6.5.0 and Zwavejs-server Version 1.0.0
and
latest tag - App version 2.0.1, Zwavejs Version 6.5.1 and Zwavejs-server Version 1.1.0

@towerhand Dev tag is died in favour of master tag, I wrote a post about this in slack channel :)

Ok, thanks. I’m not on slack.

Yep not everyone is there, hope that next ones will see this issue :)


Hide status bar for floating windows

At least the info shown in the status bar of floating windows is reduced:

But as I commonly use them just for consulting less relevant files, I would prefer the option to have no status bar at all for floating windows.

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

This feature request has not yet received the 20 community upvotes it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our documentation.
Happy Coding!

:slightly_frowning_face: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our documentation.
Happy Coding!


[Feature] Move excludeAttachmentsSet to ContextFilter

Pre-check

[X] I am sure that all the content I provide is in English.

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Apache Dubbo Component
Java SDK (apache/dubbo)
Descriptions

Support get these header in attachment
Related issues
No response
Are you willing to submit a pull request to fix on your own?

[ ] Yes I am willing to submit a pull request on my own!

Code of Conduct

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

Please assign it to me

The global configuration above needs to be keeping.

https://github.com/apache/dubbo/pull/14644


update script directory names

@chezou please review.

Ah wait, this is a dupe of #161. Please ignore.


pdf embed/link is not uniform

Making a link to a pdf file no longer requires @pdf to link. Adding @pdf to a link will make it not work.
Embedding a pdf file does still require @pdf. Not adding @pdf will make it not work.
eg.
*without @pdf
link works
 doesn't work and makes changes not compile
with @pdf
link doesn't work
 does work
So required features are available, just a bit weird that one requires the @pdf while the other doesn't.

This was explicitely designed as mentioned. An external pdf link is indeed just a link (like any other URL) and doesn't require the @pdf tag. However, a pdf file that needs to be embedded requires the @pdf tag to make sure it will be passed to the pdf processor. The same logic applies to other kinds of recourses that can be referred to as a link and as an embedded object.

Ideally, local pdf documents should be added as a learning object and added in markdown using the @ learning-object syntax.


add wiki reviewers secret

closes #132

@evgenydmitriev if statement doesn't support env and secrets, so i've performed that way

@alxarno thanks!


Error Page Handler not resolving the correct "Page" resource

Requesting a page and on the head.jsp throw a slingResponse.sendError(500)
When it reaches ACS default.jsp, the current resource becomes jcr:content and it is existent so the resulting page for 500 response comes out to be null
in this case the request URL is still page.html but but it does not go to the 500 page

@apoorv81 please feel free to add/color details to the issue

Thanks @davidjgonzalez
The use case is as follows
Content Structure

Home Page - /content/my-site/index
Errors Page - /content/my-site/errors
500 Page - /content/my-site/errors/500

Home page is setup to have errorPages="/content/my-site/errors"
Steps

User requests /content/my-site/index.html.
The head.jsp breaks and results in 500 error.

Expected: User is shown the 500 page in disabled or publish mode.
Actual: The error handler is not able to find the errors page and thus does not show the intended 500 page.
Some analysis that may help
When the control reaches ACS Commons default.jsp it tries to find the error page for the "current resource". In this use case it is jcr:content of the index.html.
It uses ErrorPageHandlerImpl.findErrorPage method.
At line 269 in ErrorPageHandlerImpl, code uses findFirstRealParentOrSelf method which results in returning jcr:content.
At line 272 the pageContentResource becomes null as the code is assuming the parent to be a page and thus tries to findjcr:content below it.
This is then returned back and thus 500 page is not shown.
Possible Resolution
Before trying to find the errorPages check if the parent resource is not a page and then find containingPage. Use the containing page to do the same logic as currently is.
I hope this helps.
ta,
Apoorv

Perfect! i wish all GH issues were as thorough as this :)

seems, issue not resolved with the release 2.0.2 yet. I am getting the following error:
it still not able to find the 500 page.

following is the configuration I used:
src\main\content\jcr_root\apps\dhl\config.author/com.adobe.acs.commons.errorpagehandler.impl.ErrorPageHandlerImpl.xml.xml

<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0" xmlns:cq="http://www.day.com/jcr/cq/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0"
jcr:primaryType="sling:OsgiConfig"
enabled="{Boolean}true"
cache.serve-authenticated="{Boolean}true"
error-page.fallback-name="500"
cache.ttl="{Long}300"
error-page.system-path="/content/dhl/master/en/home/error/500"
paths="/content/dhl/master/en/home/error"/>

For me, #1490 works


Fix atlas vector search configurations

Description

Related Issues

Checklist

[ ] Is this code covered by new or existing unit tests or integration tests?
[ ] Did you run make test successfully?
[ ] Do new classes, functions, methods and parameters all have docstrings?
[ ] Were existing docstrings updated, if necessary?
[ ] Was external documentation updated, if necessary?

Additional Notes or Comments

Codecov Report
Attention: 4 lines in your changes are missing coverage. Please review.

Comparison is base (2602049) 78.23% compared to head (572baff) 78.25%.
Report is 7 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #1029      +/-   ##
==========================================
+ Coverage   78.23%   78.25%   +0.02%
==========================================
  Files         101      101
  Lines        6331     6351      +20
==========================================
+ Hits         4953     4970      +17
- Misses       1378     1381       +3

Files
Coverage Δ

superduperdb/container/document.py
94.25% <ø> (+0.99%)
:arrow_up:

superduperdb/container/vector_index.py
85.49% <100.00%> (ø)

superduperdb/db/base/build.py
72.72% <100.00%> (+0.85%)
:arrow_up:

superduperdb/db/base/query.py
74.60% <ø> (ø)

superduperdb/db/ibis/query.py
87.82% <ø> (ø)

superduperdb/ext/openai/model.py
49.30% <100.00%> (+0.17%)
:arrow_up:

superduperdb/container/model.py
84.17% <96.66%> (+0.17%)
:arrow_up:

superduperdb/db/mongodb/query.py
81.38% <85.71%> (+0.03%)
:arrow_up:

... and 1 file with indirect coverage changes

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


Explore SQL for warm exploration

Can we use SQL for storing the entire event stream and enabling ad-hoc querying of recent/warm events?
We're interested in throughput limits.
This relates to #86.

Azure SQL DB perf limits:
https://msdn.microsoft.com/en-us/library/azure/dn741336.aspx
The highest service tier is Premium/P3:
1000 DTU, 500 GB max DB size, 735 transactions per second.

Based on the perf limits above, it doesn't look like Azure SQL DB is a good fit for our "Warm Exploration" scenario where we need to persist our full stream of raw data (2k events per second, minimum).


How to install Shuup-Graphql

Instructions skip over how to install plugin using pip. I have tried shuup-graphql and shuup_graphql and both return:
ERROR: Could not find a version that satisfies the requirement shuup_graphql (from versions: none)
ERROR: No matching distribution found for shuup_graphql
ERROR: Could not find a version that satisfies the requirement shuup-graphql (from versions: none)
ERROR: No matching distribution found for shuup-graphql
Is this plugin no longer available.

@bastianhilton I am currently working on this repo in a fork at https://github.com/jyoost/shuup-graphql if you are a developer you can simply copy the shuup_graphql directory to the root directory of your django project. If you are not a developer, I can create an installation method for you.
Let me know.

i would like some an installation method please, is this package not able to be installed via pip install "package-name"?

You can use pip install after I create a package file.  I do not work for Shuup.  It will take a little while for me to get you an installation package.

@bastianhilton if you would like to follow along on my work on an open source version of shuup, you can take a look at https://github.com/openshuup/openshuup

@bastianhilton you can now install with pip install shuup-graphql

Instructions skip over how to install plugin using pip. I have tried shuup-graphql and shuup_graphql and both return:
ERROR: Could not find a version that satisfies the requirement shuup_graphql (from versions: none)
ERROR: No matching distribution found for shuup_graphql
ERROR: Could not find a version that satisfies the requirement shuup-graphql (from versions: none)
ERROR: No matching distribution found for shuup-graphql
Is this plugin no longer available.

Sorry, I have no time to maintain and finish this addon, it is not even close to functional.

It functions fine with the included queries and mutations.
I am in the process of adding to the project and plan on making it totally functional for conversion systems. I have no intention of making it capable of being a gql API for someone to write a react front end to shuup.
I have a fork at jyoost/shuup-graphql.


Update Composer dependencies (2024-12-05-00-14)

Visual regression test passed!
View the visual regression test report


Issue #278 Add wait-retry function

Add a funciton to retry failed API calls after waiting. This function is added into the third block of this notebook for now.

Thanks @yuzhoux! :clap: :clap:

Codecov Report

Merging #283 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #283   +/-   ##
=======================================
  Coverage   22.89%   22.89%
=======================================
  Files          21       21
  Lines         760      760
=======================================
  Hits          174      174
  Misses        586      586

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 01e1aa6...7445750. Read the comment docs.


differentiate which event is currently active

it would be better to visually differentiate between different event types:

currently during login stage
rooms are available (event has been startet)
"old" events

currently it is not directly clear where to click on

should as a admin also look like as a "user"


[7.x] [kibana] use bash for readiness script (#1530)

Backports the following commits to 7.x:

[kibana] use bash for readiness script (#1530)

jenkins test this please


Fix typo in user color array variable at /docs/rooms/authentication/access-token-permissions/nextjs page

Issue
Currently, there is an error in the code when attempting to access the colorArray property from the users object. This results in unexpected behavior and may cause the application to malfunction.
Proposed Changes
To resolve this issue, I propose modifying the colors field in the prepareSession function call to correctly access the colorArray property from the user object.
Details
In the original code:
// Get the current user from your database
const user = __getUserFromDB__(request);

// Start an auth session inside your endpoint
const session = liveblocks.prepareSession(
  user.id,
  {
    userInfo: {
      name: user.name,
      avatar: user.avatarUrl,
      colors: users.colorArray,
    }
  }
);

users seems to be a typo or a mistaken reference, as the user object is already retrieved from the database and assigned to the variable user. To fix this, I suggest replacing users with user to access the colorArray property of the current user.
Proposed modification:
// Get the current user from your database
const user = __getUserFromDB__(request);

// Start an auth session inside your endpoint
const session = liveblocks.prepareSession(
  user.id,
  {
    userInfo: {
      name: user.name,
      avatar: user.avatarUrl,
      colors: user.colorArray,
    }
  }
);

You can find more information about the prepareSession function and its usage in the Liveblocks documentation, specifically at the following URL:
Liveblocks Authentication Access Token Permissions - Next.js
Testing
I have tested this change locally and confirmed that it resolves the error and provides the expected behavior. Additionally, I've ensured that it does not introduce any new issues or regressions.

Thanks for the fix! We've cherry-picked it over here and merged it:

https://github.com/liveblocks/liveblocks/pull/1509


better-output

Adds better output file format in HDF5, with more info in it.

OK, I think I did all the things you recommended. Thanks for the great recommendations!

Awesome. Code cov seems convinced you're not covering two lines though! how much are we concerned?

Might as well keep up the coverage. I'll write a test.


User logout

Hello et thx for your module,
when I use your module for encrypt my user identifier (his email) and I update my user, this user is automatically disconnected.
Have you a solution for that ?
thx a lot.

Hello,
The bundle does not interfere with any authentication nor authorisation, sorry I can't help you here.


Network vis

This PR adds a toggle switch to the Options panel for any dataset where network=True.
When enabled, the normal layer is hidden and a new layer with the network representation is created (or shown if it already exists). For now, this visualization is static and does not have special interaction options (such as marking nodes as inactive). It does have the tooltip interaction to view the details of a node.

That looks great. I hadn't thought about this before, but is it straightforward to apply the same color scheme to the lines and stations that you use for the GIS data?

That looks great. I hadn't thought about this before, but is it straightforward to apply the same color scheme to the lines and stations that you use for the GIS data?

Yes, we can actually use the same createStyle function. I had just gone with b/w to visually distinguish between the modes. But either way works.


Rubocop 0.80.0 outputs warnings about newly introduced cops

When providing a configuration file to Rubocop 0.80.0, I see three warnings related to

Style/HashEachMethods
Style/HashTransformKeys
Style/HashTransformValues

Does not happen with RuboCop 0.79.0
I'm testing the current master branch

Expected behavior
Do not see warnings
Actual behavior
$ rubocop -V
0.80.0 (using Parser <IP_ADDRESS>, running on ruby 2.7.0 x86_64-darwin19)
$ rubocop
The following cops were added to RuboCop, but are not configured. Please set Enabled to either `true` or `false` in your `.rubocop.yml` file:
 - Style/HashEachMethods
 - Style/HashTransformKeys
 - Style/HashTransformValues

Steps to reproduce the problem
$ touch test.rb
$ touch .rubocop.yml
$ rubocop

RuboCop version
0.80.0 (using Parser <IP_ADDRESS>, running on ruby 2.7.0 x86_64-darwin19)
Include the output of rubocop -V or bundle exec rubocop -V if using Bundler. Here's an example:
$ [bundle exec] rubocop -V
0.80.0 (using Parser <IP_ADDRESS>, running on ruby 2.7.0 x86_64-darwin19)

Also this broke overcommit integration

Ref:

https://github.com/rubocop-hq/rubocop/blob/master/config/default.yml#L2793
https://github.com/rubocop-hq/rubocop/blob/master/config/default.yml#L2822
https://github.com/rubocop-hq/rubocop/blob/master/config/default.yml#L2827

That's a feature. :-) As many users were complaining that when new cops were introduced this caused CI failures and extra code fixing work, we decided to just list the new cops that were added and leave it to the users to enable/disable them.
Note that those are not warnings - just informative messages.

See https://github.com/rubocop-hq/rubocop/pull/7567 and https://github.com/rubocop-hq/rubocop/issues/5979 for more details.

But I don't think broken overcommit integration is look like a feature, or is this better to discuss with overcommit team?

But I don't think broken overcommit integration is look like a feature

I was referring to the description of the issue.

or is this better to discuss with overcommit team?

I think that'd be best. I'm sorry to hear the change caused a breakage, but I've never used the tool, so I'm not sure what this integration looks like. We're always willing to help 3rd party tools that want to leverage RuboCop.

@bbatsov Ok, thanks. Created an issue at overcommit - https://github.com/sds/overcommit/issues/704

That's a feature. :-) As many users were complaining that when new cops were introduced this caused CI failures and extra code fixing work, we decided to just list the new cops that were added and leave it to the users to enable/disable them.

Hi @bbatsov , thanks for the clarification!
So every new cop will have "Enabled: pending" and we should decide if we want them or not in our own  rubocop.yml?

Yes. RuboCop will update the pending status to enabled/disable only for major releases (similar to what ESLint does).
We'll likely cut RuboCop 1.0 is the next couple of months.

@bbatsov is there any command line options to enable by default the newly introduced cops?
Use case:

I have a folder with just a ruby file
I run rubocop -a
I want all cops to be run against that file, without having to create a .rubocop.yml file


SFTPSensorAsync not working exactly in the same way as SFTPSensor

Describe the bug
If a user authenticates to SFTP with login and password, SFTPSensorAsync throws an error:
Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/astronomer/providers/sftp/sensors/sftp.py", line 67, in execute_complete
    raise AirflowException(event["message"])
airflow.exceptions.AirflowException: [Errno 2] No such file or directory: '"~/.ssh/known_hosts"'

To Reproduce
Steps to reproduce the behavior:

Create a local SFTP server (like shown here)
Create an Airflow connection:

conn id: sftp_default
conn type: SFTP
host: host.docker.internal
username: foo
password: pass
port: 2222

Upload a test file to SFTP /upload/test.txt
Create a DAG:

import pendulum
from airflow import DAG
from astronomer.providers.sftp.sensors.sftp import SFTPSensorAsync

with DAG(
    dag_id="sftp_test",
    start_date=pendulum.datetime(2023, 2, 1, tz="UTC"),
    schedule="@once",
):

    wait_for_file = SFTPSensorAsync(
        task_id="wait_for_file",
        sftp_conn_id="sftp_default",
        path="/upload/test.txt",
        poke_interval=15,
        timeout=60 * 10,
    )

See error

Expected behavior
SFTPSensorAsync should work in the same way as SFTPSensor. Now it only works after adding {"known_hosts": "none"} to the Extra field.

Currently, default value for known_hosts has been set to "~/.ssh/known_hosts" instead of which user explicitly sends known_hosts from the connection consider it or else consider the default value to be None


Chrome will stop using User-Agents

Need to look into this...
https://web.dev/user-agent-client-hints/

Related
https://github.com/serbanghita/Mobile-Detect/issues/824
https://github.com/jenssegers/agent/issues/165

Doesn't seem to have any effect on this script...
https://blog.chromium.org/2021/05/update-on-user-agent-string-reduction.html:

Our plan was designed with backwards compatibility in mind, and while any changes to the User Agent string need to be managed carefully, we expect minimal friction for developers as we roll this out (i.e., existing parsers should continue to operate as expected).

If your site, service, library or application relies on certain bits of information being present in the User Agent string such as Chrome minor version, OS version number, or Android device model, you will need to begin the migration to use the User Agent Client Hints API instead.

If you don’t require any of these, then no changes are required and things should continue to operate as they have to date.

In some ways Chrome is playing catch up on this front: Safari was the first to cap the macOS version number in the UA string and Firefox has followed suit. Firefox has also capped the Windows version number to 10.

So they are not stopping sending User-Agents... They are just more general in version numbering to make it less unique.
From:
Mozilla/5.0 (Linux; Android <androidVersion>; <deviceModel>) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<majorVersion>.<minorVersion> <deviceCompat> Safari/537.36
To:
Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<majorVersion>.0.0.0 <deviceCompat> Safari/537.36

#542


Anemo Ability Elemental Absorptions Are All Incorrect And Need Control Parameters

They apparently pick up auras in a way too big radius, so they often incorrectly pick up self-elements, such as Sucrose Q.
Furthermore, due to some absorptions being fairly unreliable in game (e.g., Sucrose), we need to add a parameter to some abilities to control whether they pick up an absorption or not (or even control the exact element absorbed?). The biggest factor for this currently is probably just Sucrose Q?

https://github.com/genshinsim/gcsim/pull/427 adds a collision check for sucrose (and several other anemo)

fixed in #427
will open separate issue for forced infusion if enough requests


Fix plugin ordering

Just realised that my plugin ordering changes in https://github.com/baudehlo/Haraka/commit/24d15b6006789b630392eac4343ba5100ec25483 incorrectly cased the object ordering to change even when no priorities are set.
This patch fixes that and retains the original order as per the ordering in config/plugins when no priorities are set.

Seems like an easy thing to add test coverage for.

Easy for you maybe, but I can assure you it would take me far longer to work out how to test this than I did to find the issue and fix it.

Since this is a 2.7 blocker I'm going to merge and add a ticket for tests.


Changed the description of "firebase" topic

Thank you for contributing! Please confirm this pull request meets the following requirements:

[X] I followed the contributing guidelines: https://github.com/github/explore/blob/master/CONTRIBUTING.md
[x] I have no affiliation with the project I am suggesting (as a maintainer, creator, contractor, or employee).

Which change are you proposing?

[x] Suggesting edits to an existing topic or collection
[ ] Curating a new topic or collection
[ ] Something that does not neatly fit into the binary options above

Editing an existing topic or collection
I'm suggesting these edits to an existing topic or collection:

[ ] Image (and my file is *.png, square, dimensions 288x288)
[x] Content (and my changes are in index.md)

Why this change ?
The existing information is outdated as Firebase expanded their services also for web developers. I changed the description with the latest information and also added information about their services in brief. Kindly review it & let me know if any changes are required.

Why isn't my pull request neither reviewed nor merged :/ ?

@deniseyu Hi, thanks for reviewing it. Could please let me know the reason ? I felt the old description is outdated as it mentioned firebase as a app development platform  which may mislead newcomers. Firebase now offers it's services also for web developers.


Prevent graph toolbar overlap with series tooltips

Could it be possible to prevent graph toolbar to overlap with series tooltips? Cometimes it's not possible to see values if they are too close to the graph toolbar:

I guess we can figure a way to hide the toolbar when the tooltip is displayed.

Fixed in 0.4-alpha.


Add regtest documentation

Here is an example of Pandacash calling BITBOX.Address.toCashAddress() to generate a regex address. This regex functionality needs to be added to the BITBOX documentation.
https://github.com/panda-suite/pandacash-explorer/blob/efa1afd202e71a30280cab3bec3cc68bcafe3239/src/components/Account.js#L37

This is resolved here https://github.com/Bitcoin-com/developer.bitcoin.com/pull/83


In-app button for selecting image

I know that I can drag an image into the window to use it, but I think there should be a more intuitive way to do it. The "Configure Languages" button could be moved into the hamburger menu and replaced with a button for selecting a file.

Hey @bragefuglseth ! Thanks for the idea, sounds good. I will experiment with it :)


[Snyk] Upgrade @types/find-config from 1.0.2 to 1.0.4

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade @types/find-config from 1.0.2 to 1.0.4.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 2 versions ahead of your current version.
The recommended version was released 23 days ago, on 2023-11-07.

Release notes

Package name: @types/find-config

1.0.4 - 2023-11-07

1.0.3 - 2023-10-18

1.0.2 - 2023-09-14

    from @types/find-config GitHub release notes

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

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

Comparison is base (28f5f59) 78.04% compared to head (223f0dd) 78.04%.
 Consider uploading reports for the commit dc17c60 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #1939   +/-   ##
=======================================
  Coverage   78.04%   78.04%
=======================================
  Files          39       39
  Lines        3061     3061
  Branches      616      616
=======================================
  Hits         2389     2389
  Misses        481      481
  Partials      191      191

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


I have a question about using lora for fine-tuning

I have trained VITS model now and when I apply LORA to attention layer, fine-tuning is not working properly, could you please tell me which layer you applied to fine-tune VITS model with LORA and what values you used for rank and alpha ?

there has no vits, just a bigvgan, after upsample layers use speaker info to change x with weights and biases.

Thanks for your reply. Can I ask one more thing?
While i'm checking your repo, i noticed that you set the conv_post, activation and speaker_adaptor to be trainable.
As i know, LoRA is something like attaching linear layers to adapt other weights, but your repo seems like fine-tuning part of the model.
Is it some other adaptation of LoRA?

Thanks for your reply. Can I ask one more thing?
While i'm checking your repo, i noticed that you set the conv_post, activation and speaker_adaptor to be trainable.
As i know, LoRA is something like attaching linear layers to adapt other weights, but your repo seems like fine-tuning part of the model.
Is it some other adaptation of LoRA?

lora is low rank adapter, here is another adapter from micsoft AdaSpeech: Adaptive Text to Speech for Custom Voice or Adapter-Based Extension of Multi-Speaker Text-to-Speech Model for New Speakers

lora_svc is not real lora, use this name is just want svc developers to think about lora.


Update Skiko 0.7.88

It needs to fix Issue with Font crash https://github.com/JetBrains/compose-multiplatform/issues/3822

We need to merge it jb main first, and cherry pick to the release

To fix the tests, I'll cherry-pick another commit


Poor UX re. the VCS context menu: Stage/Stash Changes entries are hard to tell apart

Issue Type: Bug
The VCS context menu has the barely distinguishable "Stage Changes" and "Stash Changes" next to each other:

VS Code version: Code 1.54.3 (2b9aebd5354a3629c3aba0a5f5df49f43d6689f8, 2021-03-15T10:55:24.277Z)
OS version: Linux x64 4.15.0-139-generic

GitLens adds this menu item. You can turn it off: https://github.com/eamodio/vscode-gitlens#menus--toolbars-


Pin localstack to 0.12.8

It seems that our build is afflicted by https://github.com/localstack/localstack/issues/3816
Localstack builds >=0.12.9 seem to have this issue, so pinning our test dependency to 0.12.8 for now.

/azp run

Added a commit to use DockerClient to tag images rather than execing docker tag. As part of this I've also tidied up the test a little.
Note that I think we can further tidy this test - we should really aim to cut a lot of the execution time down by testing the LocalStackContainer.shouldRunInLegacyMode method directly, rather than having an integration test for so many different permutations. I think that should be done separately, though.


Cannot view more than 50 songs in an album

Describe the bug
Scrolling is limited to 50 songs in an album.
To Reproduce
Steps to reproduce the behavior:

Browse any album with more than 50 songs.
See that you can only scroll 50 songs.

Expected behavior
I should be able to see all the song sin the album.
Screenshots
If applicable, add screenshots to help explain your problem.
General information:

Distribution: EndeavourOS Linux x86_64
Installation method [e. g. built from source, installed from Flathub...]: built from source (AUR)
Version [e.g. 0.1.0]: 0.1.14
Device used [e. g. desktop, phone...]: desktop

Additional context
I'm using a premium account.

I feel dumb, we handled this issue with playlists before but did not think of albums! Thanks for the report!

Lol, didnt think 50 song albums existed

A number of Spotify albums for classical music have more than 50 songs, especially if it's an opera or a collection of a composer's works.


Mitosis mode behaviour with popup time-out

Hi
Not sure if it's a bug or expected behaviour, it was somewhat messy from begging - originally when implemented I believe it was spawning extra n of popups, every time a popup was closed manually. As far as I remember, if popup timeout was enabled, they'd fade eventually, and no new ones would be generated.
Now, what I've observed, every time a popup fades, it creates n more popus, which leads to quite quick overflow if not terminated.
What I would expect from this function would be something like a goonto's version of this, which is multliplicate popup when clicked, but deletion when uninterrupted. Is it default setting and I'm experiencing a bug, or is it implementation issue?

This is on purpose because in the old version if you only had one popup left and you let it fade out, no new popups would be created anymore and you would need to restart Edgeware. But making another fail-safe to spawn a popup when there are none left is also be possible to restore this old functionality.


Error: useResplitContext must be used within a ResplitRoot

Hello,
I'm currently exploring the usage of the react-resplit library in my application. In the README, the example provided demonstrates the use of useResplitContext within a component. However, the example requires wrapping the component with <Resplit.Root> in the parent component.
Here's a snippet of the provided example:
import { Resplit, useResplitContext } from 'react-resplit';

function App() {
  const { isPaneCollapsed } = useResplitContext({
    direction: 'horizontal',
  });

  const handleResize = () => {
    if (isPaneCollapsed(2)) {
      // Do something
    }
  };

  return (
    <Resplit.Root>
      <Resplit.Pane order={0} initialSize="0.5fr">
        Pane 1
      </Resplit.Pane>
      <Resplit.Splitter order={1} size="10px" />
      <Resplit.Pane order={2} initialSize="0.5fr" onResize={handleResize}>
        Pane 2
      </Resplit.Pane>
    </Resplit.Root>
  );
}

Sandbox with error for reference
I'm interested in finding a solution where I can encapsulate the use of react-resplit within a single component without relying on a parent component to provide <Resplit.Root>. While one approach could be creating a Higher Order Component (HOC), I'm curious if there are alternative methods or patterns that could achieve this while maintaining the library's functionality.
Any insights or suggestions would be greatly appreciated.
Thank you for your assistance!

Thanks for submitting the issue @TopVV - the context documentation was out of date. I have updated it now.
At the moment, the only way to use those methods is to render another component inside Resplit.Root that accesses resplit context. Check out this example https://github.com/KenanYusuf/react-resplit/blob/main/src/examples/Context.tsx

Got it.
Thanks for the response


Support building multi-arch images after upgrading to istio 1.19.x

Why do you need it?
Now, we are upgrading the version of istio Higress relies on from 1.12.x to 1.19.x. When we are using istio 1.12.x, we have done a lot of patching on the upstream to support multi-arch image building. After upgrading to istio 1.19.x, we need to find a better way to archieve the same goal, building multi-arch docker images (amd64 + arm64) for controller, pilot and proxy with one command.
How could it be?
The upgrading work is now under-going in branch feat/istio-1.19.0.
The codebase already supports building docker images of the current arch (amd64 tested only, arm64 not tested yet), mainly utilizing the image building scripts provided by istio and envoy theirselves. We need to find a way to support multi-arch image building on top of it.
Local arch image building commands:

controller: make docker-build
pilot: make build-pilot-local
proxy: make build-gateway-local

For pilot and proxy, you may need to use sudo to get it done.
Other related information
@johnlanni , could you explain how the current multi-arch image building process works with istio 1.12.x?

I did some hack when use 1.12.x: https://github.com/alibaba/higress/blob/main/istio/1.12/patches/istio/20230815-multi-arch.patch
cc @rinfx


coordinates from key commands wrong when used with full-screen window

I noticed some very odd behavior (on a Mac, which may or may not be relevant).  If I am running a jupyter notebook from a full-screen window (not just filling the screen but in the "full-screen" mode Macs now support), and have ds9 on a regular desktop, all the imexam commands don't work.  Specifically, they report x/y positions different from where the cursor actually is.  I suspect this is some problem where the screen-offset coordinates aren't quite right because it's using the full-screen mappings instead of the regular desktop, but that's just a guess.
Steps to reproduce (only on a Mac):

Open up ds9 on a regular desktop
Start a jupyter notebook and run it in full-screen mode (the "green arrow" icon in the upper-left)
do imexam.connect('ds9').imexam()
use any key command (like "x", or "r") that cares where the cursor is and note the coordinate.  It will not match where the cursor actually is
If you un-full-screen the notebook, suddenly all works as expected

Wierd - a couple questions to help diagnose:

are you using ds9 Xquartz or native? How do you keep your ds9 from disappearing behind the full-screen window?
do you have multiple monitors?
are you using something other than the native aspect ratio? Do any of the resolutions work?
is your display scaled?
what browser are you using?

@eteq have you tried this lately?


Update blog landing page design

Update the design of the https://xmtp.org/blog landing page.
Here's some inspiration: https://github.com/crispgm/awesome-engineering-blogs and https://www.wearedevelopers.com/magazine/software-development-blogs. I share these resources because I think focusing on dev/eng blog designs vs marketing blog designs is important.
Just as input to the process, I'll just share that I've heard feedback from Peter that we like having the left nav as a way for devs to quickly scan for keywords to get an idea of what's available. We call it "information rich." Along these lines, Fabri reduced text size and line height as a way to get more text into a single view of a doc page for this reason. Perhaps we can take a cue from the React Native blog's treatment of their left nav: https://reactnative.dev/blog. they use Docusaurus blog as well.
I find it interesting that after looking through the example dev blogs, when devs have their own blogs - their landing pages look very different from corporate dev blogs:
https://martin.kleppmann.com/archive.html
http://www.paulgraham.com/articles.html
https://lethain.com/
Information rich - and I'm sure not due to lack of ability to provide a blog landing page with tiles and images. Are they building their landing pages in the likeness of what they want to use?
I think the current design (left nav and main content area) provides the best of both worlds in the sense that the left nav provides the condensed and information-rich view for those who want it - but should be made to be more scannable. And then we have the main content area, which provides a more visual way to browse through blog posts.
Also, I'll share this Plausible report that shows that blog posts have the highest time on page of all content on the site - so the overall IA seems to be working - but the design could be refined?
Do we want to enable people to subscribe to the blog? This is not available OOTB from Docusaurus - so we would have to build it ourselves. Perhaps we can do something with Holder?
Do we also want to make updates to the individual blog post page design?

Discussed with @darickdang and @daria-github and we decided to close this for now. We don't have signals that this is an urgent need. We can revisit in the context of a full site revamp that should be coming in the next half.


Update zh_cn.json

Deleted spaces and added missing strings.

gui.nochatreports.encryption_warning.contents中的值和原英文不一样，而且gui.nochatreports.encryption_warning.learn_more中的值是了解更多，所以应该是“了解更多”而不是“了解更多信息”

有的文本在"en_us.json"文件里已经被移除了,没必要再加回来
有的文本与"en_us.json"未保持一致

有的文本在"en_us.json"文件里已经被移除了,没必要再加回来
有的文本与"en_us.json"未保持一致
还有，你这个json文件格式是错误的，无法被正常加载
这些问题在我提交的那一版拉取请求已经被解决了，你除了去除空格和改进语法以外其他的操作都是没有意义的
我建议你用我提交的那版文件再改一次

@Aizistral I propose to withdraw the merge of this pull request

@Aizistral I propose to withdraw the merge of this pull request

Can you elaborate? I cannot audit this translation myself, but I am open to feedback.

Can you elaborate? I cannot audit this translation myself, but I am open to feedback.

The reason is above, if you don't mind, you can use Google Translate to view, of course, I can also provide you with English

@Aizistral What do you think?

Now, It seems to be error-free

@Aizistral It does have problems, some texts that have been translated are deleted by mistake, and some texts are useless (Text that no longer exists in "en_us.json") was added back. Some translations that had been corrected were reverted


Add clear documentation for users developing

We have a solidified how you can dev on pearai-app, pearai-submodule, and pearai-server.
We need a simple, readable guide on how to do this .
Nang can make :D

KK made


Missing link for Vertical-scaling in bare_metal_machine.md

Signed-off-by: Dipankar Das<EMAIL_ADDRESS>

@jihoon-seo, do you know why these checks are failing? It's only a new link

@CathPag I guess that there was a problem with Netlify for a while. I am going to close and reopen this PR to trigger another Netlify build. 😊

Thank you!!


WIP: Async and deferred loaders

Very WIP.
This PR introduces two new concepts to loaders:

A loader callback perform_on_wait that triggers whenever any batch loader promise starts waiting. This allows for async work to be triggered early in the lazy processing step (but still after the eager processing step has completed).
A loader method defer, which tells the executor to resolve other non-deferred loaders before the current one, to allow for non-async / non-concurrent loaders to run in a blocking manner while async loaders can wait to block for their result until the last minute.

See the examples/http_loader.rb file for how you'd do this. (I haven't tested that it works. Names not final).
This is inspired by https://graphql-ruby.org/dataloader/parallelism, which is a simpler solution, but based on fibers. Fibers are neat, but comes with other issues (e.g. around thread/fiber local state).
Before this PR, batch loaders could do concurrent operations within themselves. With this PR, batch loaders can do concurrent operations across all batch loaders.
(Actually, the http_loader example isn't great, since it's async/concurrent but not batching. It could start the futures in load, which is in the eager phase of resolution. This PR allows for batch loaders that are both async/concurrent and batching, and also concurrent with each other).

I won't have time to test this out before my last day at Shopify (tomorrow). Leaving it hanging here for someone to pick up or close.


add bitbucket server mode

with bitbucket server, you have to add anchor tags e.g.  for # This heading

I made a change in https://github.com/zhongxiao37/doctoc/commit/6d94c0d5543e49807b8c622b511ea6ef3f80aa18 and it worked in my local.


fmt has different limit on the width option compared to GNU coreutils

The gnu fmt command does not allow a value for width above 2500, and it will immediately return an error if one is given. for example with the GNU command you get
fmt -w 2501
fmt: invalid width: ‘2501’: Numerical result out of range

I'm not sure if this should be treated as an error in this implementation, it depends on the level of compatibility that is desired.
This causes a hang in the GNU tests, as the test runs fmt -w 32768 without any input and expect it to return an error. If this is not considered a problem then something will need to be done with the gnu tests.

@jaggededgedjustice do you want to fix it or should I?

@jaggededgedjustice do you want to fix it or should I?

It'd be great if you can take care of this, while I'm working out if there are any other hangs.

It'd be great if you can take care of this, while I'm working out if there are any other hangs.


Single consistent JSON technology rule file

Is your feature request related to a problem? Please describe.
We have been using just the JSON technology rule file for our detection but it breaks every time the JSON file moves or is renamed. It appears the file was split into alphabetical JSON files named by letter which has again broken our detection.
Describe the solution you'd like
I am requesting that there be one single JSON rules file in a location that will remain consistent so if developers are using their own library or language of choice they can choose to just parse the rules file. If a single file is not possible, splitting it into several files is acceptable as a solution for us but we are just requesting that this file structure (or directory location) remain consistent in the future.
Describe alternatives you've considered
In the past when the JSON file was renamed we just updated the file name on our end, but adding code to pull down JSON files for each letter of the alphabet, in addition to accounting for future changes that may happen unexpectedly, is not ideal or future-proof.
Additional context
We run a threat intelligence company that uses Wappalyzer's detection rules to detect technology running on malicious URLs. We love Wappalyzer so hopefully this is possible to implement so we can continue to use this beneficial technology without having to monitor updates to the detection rules.

The change was necessary because the file was getting so large it made editors struggle and it was no longer practical to view diffs on GitHub. The spec has remained largely unchanged for years but we'll continue to make improvements where it makes sense.
If you don't want unexpected changes you can use the technology definitions in a specific commit or release, or use our paid API. The master branch can change at any time.
I have been thinking of a way for me to announce breaking changes, I'm not sure what the best channel for this would be.

Thanks for the quick response, that makes sense.
We do the scanning ourselves and run our data against the rules so we wouldn't be a good match for the API. Plus we want updates on new rules so definitely want to retrieve the latest.
It is probably cumbersome but just to think out loud, an ideal solution for our use case would probably to be a dump of a single JSON file with all the rules compiled. But I think unless that is feasible and worth it from your end we will just notify ourselves of breaking changes like problems parsing and adjust as necessary.
If you have any thoughts let us know, otherwise feel free to close. 🙂

No worries. The current a-z file naming format is unlikely to change any time soon so you can update your scripts accordingly. Depending on your setup you may be able to use the NPM package instead the raw JSON files.
I think I'll open a GitHub discussion to announce any API changes so you'll be able to subscribe to that and get notified.
Thanks for being a sponsor! :)


Issue with ubuntu package 1.3.0-1.0.499.ubuntu1404

I am unable to use the latests ubuntu package because of a binary extraction error.
To recreate, obtain a clean 14.04 Ubuntu and:
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv E56151BF
. /etc/lsb-release
DISTRO=$(echo $DISTRIB_ID | tr '[:upper:]' '[:lower:]')
CODENAME=$(echo $DISTRIB_CODENAME)
# Add the repository
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME} main" | sudo tee /etc/apt/sources.list.d/mesosphere.list
echo "deb http://repos.mesosphere.io/${DISTRO} ${CODENAME}-testing main" | sudo tee -a /etc/apt/sources.list.d/mesosphere.list
sudo add-apt-repository -y ppa:openjdk-r/ppa
sudo apt-get -y update
# Install
sudo apt-get -y install openjdk-8-jre
sudo update-alternatives --config java
# Install mesos and marathon
sudo apt-get -y install mesos=1.0.0-2.0.89.ubuntu1404 marathon=1.3.0-1.0.499.ubuntu1404

The error:
aws_instance.mesos-master (remote-exec): Unpacking marathon (1.3.0-1.0.499.ubuntu1404) ...
aws_instance.mesos-master (remote-exec): dpkg-deb (subprocess): cannot copy archive member from '/var/cache/apt/archives/marathon_1.3.0-1.0.499.ubuntu1404_amd64.deb' to decompressor pipe: unexpected end of file or stream
aws_instance.mesos-master (remote-exec): dpkg-deb: error: subprocess paste returned error exit status 2
aws_instance.mesos-master (remote-exec): dpkg: error processing archive /var/cache/apt/archives/marathon_1.3.0-1.0.499.ubuntu1404_amd64.deb (--unpack):
aws_instance.mesos-master (remote-exec):  cannot copy extracted data for './usr/bin/marathon' to '/usr/bin/marathon.dpkg-new': unexpected end of file or stream

As a workaround, revert to an older version of marathon. E.g. 1.2.0-1.0.491.ubuntu1404

Our package system is broken for this last release. We are replacing the wrong packages. Please see #4182


Added a favicon for the webpage

Overview
This pull request implements the addition of a favicon to our web page, enhancing our branding and improving the user experience by displaying an icon in the browser tab.
Changes Made

Added favicon.png to the root directory of the project.
Updated the  section of the HTML document to link the favicon.

Files Modified

index.html (or the relevant HTML file)
favicon.png (favicon file)

Result

Yes Sir, for sure.


Plan status command does not work on master

What happened:
➜  kudo git:(master) ./bin/kubectl-kudo plan status --instance zk
Error: client Error: Namespace parameter required.

I think this is what broke it https://github.com/kudobuilder/kudo/pull/882


Update dependencies

 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.

It looks like the Travis build is using an older compiler version. The dependency updates should work with 0.12.2+.

Hmm yeah, for some reason the compiler version is fixed to 0.12.0 in the package.json, could you change that to ^0.12.3 too?

This is done (along with pulp and psa).

Um, not sure what happened here. Sorry!


Help for adding self made data

Hi,
I want to aggregate nmea0183 and possibly n2k data, but also some of my own data. It's all well and good to expand 0183 sentences and n2k sentences, but at some stage people will want to add custom data to the stream. I am looking for a simple way of adding data, type "select category, name the variable, update the data" in order to add the data into the right format and into the server stream. Am I on the right track?

I think the way to go about it would be to figure out a decent format for your data that it is line with the rest of the Signal K data model and then propose a schema change.
After all the point of the Signal K spec is to specify how a certain data item should be presented. If we resort to just stuffing arbitrary values into the messages then what's the point of a common model.
Am I answering your question at all?
Could you give a concrete example of something that you would like to represent in the Signal K model that is not there at the moment?

Hmm or are you looking for just a way to send data to the server, eg. make a custom Provider?
One easy way to do that would be to create an executable that outputs Signal K delta in json format, one message per line. Then you could create a settings file that could use the execute provider to launch your application.
execute provider is configured like in https://github.com/SignalK/signalk-server-node/blob/b7c8cedc6f72c863fe65980082c88ecc2954e2c2/settings/actisense-serial-n2kd-settings.json#L10. By using a somewhat similar provider pipeline (without n2k-signalk) you could have your application's output chopped to a message per line and the json parsed to delta objects that the server can digest.
If you need I can create a simple settings file that will echo a static delta message continuously to demonstrate the idea.

Thank you. You are making perfect sense. I agree to align and add to the schema and will do. And to your second comment, yes please!

Any progress on this? Do you still need help actively?

I have not come any further. I would like a pointer to how I can tell sk to add some data like polar speed and target speed from a Python script or similar
Sent from my iPhone

On 02 Nov 2015, at 21:40, Teppo Kurki<EMAIL_ADDRESS>wrote:
Any progress on this? Do you still need help actively?
—
Reply to this email directly or view it on GitHub.

Actually I just remembered that there has been a sample settings file that launches a shell script to inject dummy Signal K data. See https://github.com/SignalK/signalk-server-node/blob/master/settings/commandline-provider-settings.json


Feedback on pointer file spec

It doesn’t indicate if the pointer file contents is case-sensitive or not: I think it should not be, to follow established patterns with Git config files and CLI arguments which are only case-sensitive where it makes sense

Saying "The pointer file should be small (less than 200 bytes), and consist of only ASCII characters” doesn’t appear to add anything since it’s impossible not to comply considering the pointer file format, so it’s adding confusion IMO (implying this that something that cannot happen could happen)

"Libraries that generate this should write the file identically”: should -> MUST

The sample has "(ending \n)” at the end but the spec doesn’t say if required or not, so is it or not? IMO it should be, so each line is clearly {key} {value}\n

"Use properties "version", "oid", and "size" in that order.” seems a really bad idea for what is clearly a list of key-value pairs without any meaningful ordering: it’s adding constraints which are guaranteed to create issues in the future if/when new keys are added / deprecated / made optional

It doesn’t address how clients could add private key-value pairs to this file - related to 5

I think the version field should be like 1:https://git-lfs.github.com/spec/v1 as this makes parsing trivial (version = what’s before the column) and it avoids any ambiguity comparing URLs e.g. what if someone put in there http://git-lfs.github.com/spec/v1? Should you fail? pass? What kind of fuzzy logic is needed?

Considering the pointer files are clearly structured data vs just a list of one SHA1 per line for instance, I’m curious as to why the decision was made to create a new file format vs using the Git config one which is well known, extensible, and people have parser for (YAML or JSON would be nice, but they’re not used anywhere in Git).

Thanks for the feedback.  I'll try to address each point:

I want different Git LFS implementations to generate the exact same pointer file, such that it hashes to the same Git blob oid.  IMO pointers should be case sensitive (and the spec should make this clear).

Sure, good point.

:+1:

I think the spec should make it clear that the line break is required.

The order has to be consistent so that different Git LFS implementations generate the same file, which leads to the same Git blob OID.

They probably shouldn't, otherwise Git LFS may rewrite the blob and clobber unknown values.  I've had some ideas on other possible key/value pairs though, and am open to the idea.  Would be interested to hear specific use cases though.

IMO the version url shouldn't change, unless you're using a different, incompatible version.  Inspired by xml namespaces.  Four words I never thought I'd type :)

I designed them to look like the non-blob objects stored in git: key SP value.
 $ git cat-file -p `git rev-parse master`
 tree 776003038ef7b60bdfed6d3d645ab66d6b160dd8
 parent 1cb54bcdf1624ef43ba6bd2f89ad4f066277144e
 parent 05d4692e9fddefba46fe8ab275afe86574904233
 author risk danger olson<EMAIL_ADDRESS>1428694427 +0200
 committer risk danger olson<EMAIL_ADDRESS>1428694427 +0200

Would be interested to hear specific use cases though.

Well since GitHub is the standard for Git hosting and large files are a big problem with Git and I can imaging the ecosystem of Git tools adopting this extension and later down the road have asset management tools be created around it, it makes complete sense to expect people to want to attach some extra metadata in there (of course you don't wanna design the spec to say allow embedding an entire EXIF payload but there's a middle ground for simple key-value pairs).
The burden of proof is the other way around - can you make a case beyond reasonable doubt that metadata will never be needed or that the cost of supporting it clearly outweights its benefit? ;) Because the alternative to retrieve a 100 bytes of metadata is a round-trip to the server to download a multi-megabytes asset.

The order has to be consistent so that different Git LFS implementations generate the same file, which leads to the same Git blob OID.

That's a laudable goal, but it seems very hard to enforce (the spec doesn't even mention that today nor comes with a sample code to validate the expected OIDs), it prevents extensibility, but more importantly, why would it matter?
I mean are different Git backends required to generate the exact same SHA1s when creating a commit with the same user-level provided input data otherwise things would break? I cannot imagine why this would even be a problem the way Git works today but I might be missing something.
IMHO the big problem with this requirement is that it's not enforced. When server APIs require signing with HMAC for instance, the server verify that the payloads signature matches, and reject the call if not. So that's consistent: the spec says you MUST structure your payload only in one way then sign it, otherwise things will not work. And they don't.
In this case here, will GitHub servers extract the fields from the file pointer, regenerate it and recompute the OID from it, compare and reject when pushing to a repo commits with file pointers? That's very complex and even GitHub does it, I cannot imagine all Git hosting services doing. So here comes contamination... This means consistent OIDs is just an arbitrary rule that cannot be enforced, and by definition, nobody can make any assumption about it, which is equivalent to not having it.

I mean are different Git backends required to generate the exact same SHA1s when creating a commit with the same user-level provided input data otherwise things would break?

One thing I can think of is that not all Git implementation might use sub-second resolution timestamps when creating commits.

IMO the version url shouldn't change, unless you're using a different, incompatible version.

Agreed, but my point was about comparing to determine if they have "changed": is http://git-lfs.github.com/spec/v1 equal to https://git-lfs.github.com/spec/v1?
If you want to use URLs for versioning vs a simple integer field, then the spec must explain how to compare them. It's a whole section of the XML spec: http://www.w3.org/TR/REC-xml-names/#NSNameComparison.

Side note: it's really great to see GitHub driving a concrete effort for large files support in Git :+1:
I'm only pointing all these things because, considering the weight GitHub carries when it comes to Git, I really believe the spec should be super tight. The last thing we need is ambiguities which turn into different interpretations by different Git tools or Git hosting companies.

it makes complete sense to expect people to want to attach some extra metadata in there (of course you don't wanna design the spec to, say, allow embedding an entire EXIF payload, but there's a middle ground for simple key-value pairs).

The Git LFS pointer file is specifically to tell the client enough information to download the file effectively on checkout.  Optional meta data can be added in other ways.  I'm open to re-evaluating if there's a really great use case, though.

That's a laudable goal, but it seems very hard to enforce (the spec doesn't even mention that today nor comes with a sample code to validate the expected OIDs), it prevents extensibility, but more importantly, why would it matter?

It matters because the clean filter will mark the file as updated if the generated pointer file is different.  If the spec can stay small and strict, then I don't see it as a problem.

If you want to use URLs for versioning vs a simple integer field, then the spec must explain how to compare them.

If I'm reading that spec correctly, then it's saying to use simple string comparison, and not any kind of url resolution or matching.  That sounds good.

I really believe the spec should be super tight. The last thing we need is ambiguities which turn into different interpretations by different Git tools or Git hosting companies.

Definitely.  Thanks for your feedback.  I'm all for tightening the spec up, and will ping you on a PR to address some of your points here.

I'm open to re-evaluating if there's a really great use case, though.

The problem is the way the spec is currently designed, it's so inflexible that it pretty much guarantees you can't add new key-value pairs without breaking things in practice. Which means when the time comes (I'd bet on "when" not "if"), the version will have to be revised which means you will have an ecosystem of tools supporting v1 but not v2 (and breaking the pointer files that go through it) or the other way around.

It matters because the clean filter will mark the file as updated if the generated pointer file is different.

That is a very good point because it gives a very good reason for the ecosystem of tools to comply.
Here's my suggestion at a high-level revised pointer-file spec to attempt to unifying things while leaving the door open for future extensions:
================

Pointer files are text files which MUST contain only UTF-8 characters (this ensures international support for the future)
Each line MUST be of the format {key} {value}\n (unix newline, not windows or whatever)
Only a single space character between {key} and {value}
Keys MUST be using ASCII characters only
Keys MUST be lowercase
Keys MUST NOT contain whitespaces
Lines of key-value pairs MUST be sorted alphabetically in ascending order (this ensures both OID stability AND extensibility of key-value pairs)
Values may contain whitespaces
Custom or third-party key-value pairs MUST have their keys use reverse-DNS notation e.g. com.gitup.my-key - plain (i.e. non-reverse DNS) keys are reserved EXCLUSIVELY for use by the spec
Pointer files SHOULD not have the executable bit set when checked-in in Git

Required key-value pairs for v1:

(list goes here)

Example v1 pointer file:
(goes here)
For testing compliance of any tool generating its own pointer files, the reference is the official GitHub tool: - Run it with the command (fill in) to generate a pointer file for the passed-in large file

Run your own tool and generate your own pointer file
Run the Git command (fill in) and compare that the generate OIDs between the official GitHub tool and yours is the same

For tools that parse and regenerate pointer files, they MUST preserve (i.e. copy as-is) keys they don't know or care about.
Note that because of the way pointer files are used by Git, their contents is in-effect case-sensitive.
=============
This should address both your requirements and the potential issues I was pointing out :)

If I'm reading that spec correctly, then it's saying to use simple string comparison, and not any kind of url resolution or matching. That sounds good.

Indeed and it goes out of its way to say that equivalent URLs are not equal, which IMO is very important.

The alphabetical sorting is inspired from http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html which works great.

I moved the my suggested revised spec to a Gist since I kept modifying it - should be good now though :)
https://gist.github.com/swisspol/b9856fcca81029efb960

I moved the my suggested revised spec to a Gist since I kept modifying it

Looks good :+1:

Custom or third-party key-value pairs MUST have their keys use reverse-DNS notation e.g. com.gitup.my-key - plain (i.e. non-reverse DNS) keys are reserved EXCLUSIVELY for use by the spec

I'd rather replace this with a note that custom keys are not supported.  While your revised spec makes adding them to the pointer file spec possible without introducing a new version, we still haven't figured out how git-lfs should handle properties it doesn't know about in the code.
I do like  the idea of version being first always.  Any thoughts on making that an exclusion?
version someurl
abc def
oid {oid}
size 123
zyx wvu

This should make it easy for parsers to quickly figure out what version they're dealing with, while continuing to support possible key additions.  This also doesn't change existing pointer files.

I'd rather replace this with a note that custom keys are not supported. While your revised spec makes adding them to the pointer file spec possible without introducing a new version, we still haven't figured out how git-lfs should handle properties it doesn't know about in the code.

What's there's to handle? Is there more to just keeping them around in a dict then writing them back? What am I missing?
Seems like a very short-term limitation you will have to solve anyway, so it should really not bear on the spec IMO. The last thing you want is some sort of post 1.0 release of the GitHub tool not being able to handle this correctly :)

I do like the idea of version being first always. Any thoughts on making that an exclusion?

Why? What's the engineering rationale for this?
I'll even go one step further: you will actually notice that with my proposed spec'ed, since it's forward/backward compatible, there's actually no need for a version in the first place: it's implied.
Think about it, what matters is the presence of keys: parse pointer files, extract the 4 required keys you need, if they're here good, if not fail with error message. Compare with extracting version, comparing version, build logic to handle combination of versions and missing / present keys, degenerated cases if a version is the right one, but some keys are still missing, etc...
The question therefore becomes: what's the use case for a version field? What breaks in the toolchains or large file ecosystem if there's none?
If you really want a version field, I think it's a pretty bad idea to have this key looks like any other key and have the rule not apply to it - quite confusing. Instead, consider a special character prefix and format e.g. #version=foobar\n which comes with a rule that the first line MUST be this special thing. An example that comes to mind is the <!DOCTYPE html> at the beginning of HTML docs which is different than regular tags.
XML has a namespace/version because the same format is used for a variety of contents so you need to know what contents is in there. This doesn't apply here since it's a file format for one and only one goal.

I tweaked the spec a bit: https://gist.github.com/swisspol/b9856fcca81029efb960/revisions

One question pending for me is how should newline and returns characters be escaped? They can't be in the values as the spec says for obvious reasons, but it would nice (although not required) to allow it.

What's there's to handle? Is there more to just keeping them around in a dict then writing them back? What am I missing?

The fact that between Git Media and the tools it has inspired don't have any thing in their pointer other than oid leads me to believe this isn't a problem.  If someone wants to solve it in code, that's great.  I don't want the spec to promote something that hasn't been implemented in the code, or even fully thought through.  Luckily, your revised spec makes it easy to support new keys in the pointer format.  We can edit markdown and code easily.

I do like the idea of version being first always. Any thoughts on making that an exclusion?

Why? What's the engineering rationale for this?

Those are all good points, but not good enough to change the spec at this point IMO.  If we get to a point where we have to make a major version bump, we can revisit how or even if the version is specified.  I wouldn't mind # version {url} or even just # {url} at the top.

One question pending for me is how should newline and returns characters be escaped? They can't be in the values as the spec says for obvious reasons, but it would nice (although not required) to allow it.

The white list of allowed characters in point 4 of your revised spec leaves these out. :+1:

The fact that between Git Media and the tools it has inspired don't have any thing in their pointer other than oid leads me to believe this isn't a problem.

I'm confused, what is "this" referring to in this sentence?

Those are all good points, but not good enough to change the spec at this point IMO.

Just to be clear, you're saying you want a version field, but you're OK with not having it use the standard key format so it doesn't create any confusion, right?

If we get to a point where we have to make a major version bump, we can revisit how or even if the version is specified. I wouldn't mind # version {url} or even just # {url} at the top.

If there's one that actually needs to be rock stable forever that's how the version itself is specified ;)

The fact that between Git Media and the tools it has inspired don't have any thing in their pointer other than oid leads me to believe this isn't a problem.

I'm confused, what is "this" referring to in this sentence?

The problem of not supporting custom keys in the pointer spec.

Just to be clear, you're saying you want a version field, but you're OK with not having it use the standard key format so it doesn't create any confusion, right?

Sure.  I don't have any interest in changing the current pointer spec just to change it though.

I don't have any interest in changing the current pointer spec just to change it though.

Wouldn't it be part of the other changes like alphabetical sorting of keys?

Wouldn't it be part of the other changes like alphabetical sorting of keys?

I'm keeping the version at the top so that existing Git LFS objects are still compliant with the revised spec.

Regarding the commands you suggested:

Run it with the command (fill in) to generate a pointer file for the passed-in large file

How about something like:
$ git lfs pointer path/to/large-file
version https://git-lfs....
oid ...
size ...

Run the Git command (fill in) and compare that the generate OIDs between the official GitHub tool and yours is the same

I'm not sure what the point here is.  Can't you just look at the two pointers?  Though if we had a command:
$ cat some/other/pointer | git lfs pointer path/to/large-file
# either return exit 0, or non zero and a diff?
- version https://git-lfs....
+ # https://git-lfs....

How do you envision these commands working?

I'm keeping the version at the top so that existing Git LFS objects are still compliant with the revised spec.

Ah, lucky that the alphabetical order doesn't change the current file pointers!

Can't you just look at the two pointers? Though if we had a command:

If the requirement is that OIDs for file pointers match, then the compliance must be verified by comparing OIDs generated by Git for the blobs, not diffing text visually.
Maybe using something like (see http://git-scm.com/book/en/v2/Git-Internals-Git-Objects):
$ echo 'test content' | git hash-object -w --stdin
d670460b4b4aece5915caf5c68d12f560a9fe3e4

Ah, lucky that the alphabetical order doesn't change the current file pointers!

Ha, yes :)

If the requirement is that OIDs for file pointers match, then the compliance must be verified by comparing OIDs generated by Git for the blobs, not diffing text visually.

Even better.  :+1:

Maybe also check out https://github.com/github/git-lfs/issues/229 as a potential alternative for a pointer file spec... While there might be more overhead due to XML and a more rich file format, it is still negligible compared to what these files should point to. The advantage would be that Metalink is designed to be exactly what these pointer files try to do: A collection of file information (e.g. hash, name, size...), and location(s) where to find the file contents (HTTP mirrors, BitTorrent info hashes, FTP servers...).
The current spec seems to assume only a single location for file contents which might be useful for large service providers like GitHub, but does not in my opinion make this feature very flexible or adaptable. What about the use case for example to offer an internal asset server or load files mainly from an AmazonS3 bucket - but if something fails, use the quota at GitHub?

While there might be more overhead due to XML and a more rich file format, it is still negligible compared to what these files should point to.

XML is overkilled for this. It sounds simple on the surface, but it's a really complex file format with lots of special cases. It would require everyone to use parsing libraries and then walk the XML tree and everything. Lots of overhead and error handling just to get the idea.

What about the use case for example to offer an internal asset server or load files mainly from an AmazonS3 bucket - but if something fails, use the quota at GitHub?

No matter what this implies a custom tool anyway since the GitHub one won't handle this, so if you have a custom tool, you can have your own incompatible format.
Or you can just set up a proxy server.

I'm keeping the version at the top so that existing Git LFS objects are still compliant with the revised spec.

I thought more about this, and I really with this could be reconsidered. The spec is pre-1.0 and barely used today. Once things ramp up it will be around for 10 years and used by thousands of people and hundred of thousands of files minimum. Having a pointer file format with some avoidable clunkiness will generate some real costs and frustration down the road.
Custom key-value pairs should be supported from day 1 by the official tool and the version field should become something like <!DOCTYPE html> for HTML.
The cost of changing the spec right now to be more future proof is negligible in the grand scheme of things.

The current spec seems to assume only a single location for file contents which might be useful for large service providers like GitHub, but does not in my opinion make this feature very flexible or adaptable. What about the use case for example to offer an internal asset server or load files mainly from an AmazonS3 bucket - but if something fails, use the quota at GitHub?
Or you can just set up a proxy server which can handle such situations transparently.

This is one of the goals of Git LFS: push as much of the configuration to the servers.  It's a simple HTTPS spec that we hope will be implemented by other Git servers.  You can also push your large files to alternate Git LFS servers outside of your Git host.  Maybe you want a small server in the cloud that directs files to your own S3 bucket?  Or maybe you want to set up a local proxy/cdn server so that an entire office of coworkers only needs to download the content once from the remote source.  There's a lot of flexibility with HTTPS APIs.

The cost of changing the spec right now to be more future proof is negligible in the grand scheme of things.

I'm open to changing the spec before v1.0.  I'd prefer to do it just once if possible.  So, let me know if you have a compelling use case for custom keys that Git LFS needs in the pointer to effectively download the file.  Also, an alphabetical list of keywords does allow custom keys.  We don't need to break the pointer format.

It's a simple HTTPS spec that we hope will be implemented by other Git servers.

It does have 4 HTTP redirect codes which doesn't seem that simple ;)

So, let me know if you have a compelling use case for custom keys that Git LFS needs in the pointer to effectively download the file.

That's only 1 use case, the primary one I was thinking about and mentioning above is caching metadata for the large file in the file pointer. Furthermore, if the custom keys affect the file download, then the spec is not really interoperable. Custom keys should be used for metadata, orthogonal to the actual download IMO. That's the beauty of it.
It's very inefficient to download a 1 GB file to retrieve a 100 bytes of metadata or having to store it in a sidecar file while you already have a file pointer that could store the metadata for immediate access.
It could be used for something as simple as tags, or the name of the tool that generated the

Also, an alphabetical list of keywords does allow custom keys. We don't need to break the pointer format.

Except for the version field.

Great thread. I agree XML is overkill - wondering if YAML might be considered? it seems to me pretty crazy to re-invent a key/value file format spec and have people do possibly broken or non-compliant parsing when YAML has many very tight, small, and correct parsers out there. the current file is in fact /almost/ correct YAML if the key/value pairs had ':''s between them afaict.

YAML and TOML were considered.  The pointer format was designed to look like the format Git uses to store commit/tree/tag objects.

i'm not enough of a GIT-head to know how often extensions interact with the commit/tree/tag objects (I only know I have never interacted with them). I guess this file-type seems more common and perhaps in people's face in their tools, or something that lots more custom tools will work with, so that might influence the format a bit more. nutshell: the extensibility/fragility leaves a bit to be desired, which is why YAML seems like it would make good sense.

Thanks for the feedback, everyone!  #246 landed, with an enhanced spec, and a pointer tool to help build and compare pointer files.


Higher than usual resource drain?

https://spark.lucko.me/p86MimpATf
Hi, terribly sorry but just thought I'd check as in the plugins section of the Spark report it suggests Death-Chest is using almost 14%? The server was idling the whole time so not too sure but it seems extremely high compared to the other plugins. If it's intended it's absolutely fine but thought I'd check just in case.

Not sure if this is relevant but get constant errors of this sometimes if chunks with death-chests are loaded
[18:48:11 WARN]: [DeathChest] Plugin DeathChest v1.5.8 generated an exception while executing task 1418467
java.lang.IllegalStateException: async operation is not supported
        at me.filoghost.holographicdisplays.plugin.lib.fcommons.Preconditions.checkState(Preconditions.java:69) ~[HolographicDisplays-3.0.1-SNAPSHOT.jar:?]
        at me.filoghost.holographicdisplays.plugin.lib.fcommons.Preconditions.checkMainThread(Preconditions.java:92) ~[HolographicDisplays-3.0.1-SNAPSHOT.jar:?]
        at me.filoghost.holographicdisplays.core.CorePreconditions.checkMainThread(CorePreconditions.java:13) ~[HolographicDisplays-3.0.1-SNAPSHOT.jar:?]
        at me.filoghost.holographicdisplays.core.base.BaseTextHologramLine.setText(BaseTextHologramLine.java:35) ~[HolographicDisplays-3.0.1-SNAPSHOT.jar:?]
        at de.helixdevs.deathchest.support.hologram.holographicdisplays.HDTextLine.rename(HDTextLine.java:17) ~[death-chest-1.5.8-all.jar:?]
        at de.helixdevs.deathchest.DeathChestImpl$1.lambda$run$0(DeathChestImpl.java:165) ~[death-chest-1.5.8-all.jar:?]
        at java.util.LinkedHashMap.forEach(LinkedHashMap.java:721) ~[?:?]
        at de.helixdevs.deathchest.DeathChestImpl$1.run(DeathChestImpl.java:160) ~[death-chest-1.5.8-all.jar:?]
        at org.bukkit.craftbukkit.v1_19_R1.scheduler.CraftTask.run(CraftTask.java:101) ~[purpur-1.19.2.jar:git-Purpur-1845]
        at org.bukkit.craftbukkit.v1_19_R1.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:57) ~[purpur-1.19.2.jar:git-Purpur-1845]
        at com.destroystokyo.paper.ServerSchedulerReportingWrapper.run(ServerSchedulerReportingWrapper.java:22) ~[purpur-1.19.2.jar:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) ~[?:?]

Thank you very much I will fix it!

Would you like to add my on discord that we can test the fix for the first issue?
Best regards
Ricardo

These bugs should be fixed now. Thank you very much for your efforts!


UnmanagedRackPlugin : Unable to attach computer system chassis with chassistype 'RackMount' to a Rack

Steps to Reproduce:

Start URP service
Add computer system chassis with ChassisType 'RackMount' in odimra
Add URP to odimra
Create Rack Group
Create Rack and do a patch operation on the uri returned in Location in response header as mentioned in 4th step
Attach Computer System chassis to rack

Expected Response code : 200
Actual Response code : 405 Method not allowed

Verified and Response code is now 200


Attempt to improve stability a bit:

tracebacks due to network issues appears quite often, after each process freezes

It's a decent start but I'm thinking..

We ought to be raising proper exceptions rather than tuples (a bug from the original code I wrote).
It would be cleaner to just detect and handle the issue without exceptions at all instead of using them for control as your current patch does.
This whole section (not just your patch) could do with an overhaul. In particular, I think it would help to separate the EDSM lookups into a new pipeline so the display loads as quick as the game; Could have a spinny loading icon while the info is being gathered. Then as info comes in from EDSM, update the UI (or display an error indicating there's an EDSM connection issue).

It's a decent start but I'm thinking..

We ought to be raising proper exceptions rather than tuples (a bug from the original code I wrote).
It would be cleaner to just detect and handle the issue without exceptions at all instead of using them for control as your current patch does.
This whole section (not just your patch) could do with an overhaul. In particular, I think it would help to separate the EDSM lookups into a new pipeline so the display loads as quick as the game; Could have a spinny loading icon while the info is being gathered. Then as info comes in from EDSM, update the UI (or display an error indicating there's an EDSM connection issue).

Hi. This is awesome tool. Thank you for it.
I'm just patched it for myself to be able to use it on my trip to Colonia :)
Bit disagree on 2, once you using requests  lib that throws bunch of exceptions on quite usual network issues, probability of it for 500 jumps very close to 100%, and since it unprocessed, any of them will crush Flask thread. Pity but that make tool nearly unusable.
o7

Made some updates based on your proposal: https://github.com/joncage/ed-scout/pull/167 ...just need to add some handling in the web interface to highlight there are EDSM link issues.


Theme fixes for Hawthorn merge

@caesar2164 Actually, can you make this PR against origin/open-release/hawthorn.master?


feat(tokens): Modified building script to mitigate repeated tokens

What do these changes accomplish?
Single core tokens file
Modified the tokens building script so instead of it generating the files
gse-flare-light-core
gse-flare-dark-core
gse-legacy-light-core

with repeated tokens(see: the files on main for reference), it only generates a single
gse-core

Mitigate repeated semantic tokens
It also splits the semantic tokens into three files now corresponding to its subsets (theme, mode and global)
So instead of having
gse-flare-light-semantic
gse-flare-dark-semantic

with repeated tokens(see the semantic files on main), we have
gse-flare-semantic-theme
gse-flare-light-semantic-mode
gse-flare-dark-semantic-mode
gse-flare-light-semantic-global
gse-flare-dark-semantic-global

without repeated tokens
This also allows us to make mode swapping more efficient since we don't need to swap the core tokens and file, only the semantic-mode and global ones

Just for people reviewing  for the mitigation of repeated semantic tokens,
The file names have changed from

gse-flare-semantic-theme
gse-flare-light-semantic-mode
gse-flare-dark-semantic-mode
gse-flare-light-semantic-global
gse-flare-dark-semantic-global

to
gse-flare-dark-sematic-mode - > gse-semantic-flare-dark
gse-flare-dark-semantic-global - > gse-semantic-flare-global
gse-flare-light-semantic-mode -> gse-semantic-flare-light
gse-flare-semantic-theme -> gse-semantic-flare
gse-legacy-light-semantic-global -> gse-semantic-legacy-global
gse-legacy-light-semantic-mode -> gse-semantic-legacy-light
gse-legacy-semantic-theme -> gse-semantic-legacy
gse-flare-dark-ui -> gse-ui-flare-dark
gse-flare-light-ui -> gse-ui-flare-light
gse-legacy-light-ui -> gse-ui-legacy-light

I think thats all of them 🤔