Button partial error

Having an issue with the partial buttons, I get this error when running 'grunt'
Assembling dist/email.html ERROR
Warning: Parse error on line 32:
...     {{> button type="primary" align="ce
-----------------------^
Expecting 'CLOSE', 'CLOSE_UNESCAPED', 'STRING', 'INTEGER', 'BOOLEAN', 'OPEN_SEXPR', 'CLOSE_SEXPR', 'ID', 'DATA', 'SEP',
got 'EQUALS' Use --force to continue.
I'm also recreating this workflow from scratch so I can better understand how you've done it and why, so far my .json file has these dependencies:
"devDependencies": {
"assemble": "^0.4.42",
"grunt": "~0.4.5",
"grunt-assemble": "^0.4.0",
"grunt-cdn": "^0.6.5",
"grunt-contrib-clean": "^0.7.0",
"grunt-inline-css": "^0.1.5",
"grunt-juice-email": "^0.1.4",
"grunt-sass": "^1.1.0"
}
// UPDATE
Might have resolved this by changing the loadNpmTask to 'grunt-assemble' from 'assemble'

Interesting. Now I'm wondering why and if I need both assemble and grunt-assemble. Let me know if you have any recommendations for tidying up dependencies.

thanks I got it working with grunt-assemble, there might be some variable changes.
Mine looks like:
// Assembles your email content with HTML layout
assemble: {
options: {
layoutdir: 'src/layouts',
partials: ['src/partials/**/.hbs'],
flatten: true
},
pages: {
src: ['src/emails/.hbs'],
dest: 'dist/'
}
},


stride parameter is not used in ImmutableBitmap constructor, and so pixel data are corrupted

Describe the bug
As you can see, the stride parameter is not used, and so if the specified stride is different than "width * bytesPerPixel", the image data are incorrect.

To Reproduce
I am not using ImmutableBitmap but the constructor of Bitmap, like that:
new Avalonia.Media.Imaging.Bitmap(format, bitmap.AlphaType.ToAvalonia(), buf.Address, bitmap.Size, new Avalonia.Vector(96, 96), buf.RowBytes);
My buf.RowBytes is larger than bitmap.Size.Width*4 as I am using padding to align memory for SIMD processing.
Expected behavior
I am expecting that stride is handled as it should.
Avalonia version
11.0.10
OS
Windows
Additional context
No response

I can create a PR to fix it.


In drill-down browser, it is not clear how to open terms

https://github.com/geneontology/amigo/issues/331#issuecomment-203613831
revising the drill down browser text made me realise that I could open terms (despite it being called drill-down, doh).  Even once I knew it was possible  it wasn't obvious how.  I think this is partially because the traingle to click on is so tiny. Would the little 'plus in a box icon' be more obvio

us here?
Or bigger triangles. Something to make it clearer 'click here'

Totally agree, but this may be a limitation of the toolkit. I'll take a look at that late today.

I see it now. Its not so pretty but you can't have everything ;)

I'll try and give it a spit shine later on if/when I get the chance--I started to get a headache moving the wee pixels around. I think it at least says "click me" better than the last one.

More delicate "+'s" would do it;)


There is an issue when I install "officeparser" with the document loader pptx, terminating all my tRPC API.

There seems to be an issue ⚠ with loading the langchain  document and the officeparser  package.
Everything is running smoothly with my tRPC APIs, except for one issue I encountered while attempting to load a PowerPoint file using the langchain document loader. To fix the problem, I installed officeparser, but this caused all my tRPC APIs to stop working. Removing 'officeparser' resolved the issue and my tRPC APIs worked without any problems. However, when officeparser was installed, I received a 404 error message from tRPC.

There is an error in my terminal also

TypeError: s is not a function
    at C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:13:5619
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async tE (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:13:4860)
    at async tV (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\compiled\next-server\app-page.runtime.dev.js:13:32468)
    at async doRender (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\base-server.js:1294:26)
    at async cacheEntry.responseCache.get.incrementalCache.incrementalCache (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\base-server.js:1446:28)
    at async DevServer.renderToResponseWithComponentsImpl (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\base-server.js:1361:28)
    at async DevServer.renderErrorToResponseImpl (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\base-server.js:1854:24)
    at async DevServer.pipeImpl (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\base-server.js:826:25)
    at async DevServer.handleCatchallRenderRequest (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\next-server.js:623:13)
    at async DevServer.handleRequestImpl (C:\Users\Binary Gadget\Desktop\officeai\node_modules\next\dist\server\base-server.js:728:17)

My package.json file information:

{
  "name": "officeai",
  "version": "0.1.0",
  "description": "This is office utils SaaS application with AI",
  "private": true,
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint",
    "postinstall": "prisma generate"
  },
  "dependencies": {
    "@hookform/resolvers": "^3.3.2",
    "@mantine/hooks": "^7.0.1",
    "@pinecone-database/pinecone": "^1.0.1",
    "@prisma/client": "^5.3.1",
    "@radix-ui/react-avatar": "^1.0.4",
    "@radix-ui/react-dialog": "^1.0.5",
    "@radix-ui/react-dropdown-menu": "^2.0.5",
    "@radix-ui/react-hover-card": "^1.0.7",
    "@radix-ui/react-label": "^2.0.2",
    "@radix-ui/react-progress": "^1.0.3",
    "@radix-ui/react-scroll-area": "^1.0.5",
    "@radix-ui/react-separator": "^1.0.3",
    "@radix-ui/react-slot": "^1.0.2",
    "@radix-ui/react-toast": "^1.1.4",
    "@radix-ui/react-tooltip": "^1.0.7",
    "@sendgrid/mail": "^8.1.0",
    "@tailwindcss/typography": "^0.5.10",
    "@tanstack/react-query": "^4.35.3",
    "@trpc/client": "^10.38.4",
    "@trpc/next": "^10.38.4",
    "@trpc/react-query": "^10.38.4",
    "@trpc/server": "^10.38.4",
    "ai": "^2.2.13",
    "autoprefixer": "10.4.16",
    "bcryptjs": "^2.4.3",
    "class-variance-authority": "^0.7.0",
    "clsx": "^2.0.0",
    "date-fns": "^2.30.0",
    "eslint-config-next": "13.5.2",
    "jsonwebtoken": "^9.0.2",
    "langchain": "^0.0.213",
    "lodash": "^4.17.21",
    "lucide-react": "^0.299.0",
    "next": "^13.5.6",
    "next-auth": "^4.24.5",
    "openai": "^4.10.0",
    "pdf-parse": "^1.1.1",
    "pdfjs-dist": "^4.0.269",
    "pdfreader": "^3.0.2",
    "postcss": "^8.4.32",
    "prisma": "^5.3.1",
    "puppeteer": "^21.6.1",
    "react": "18.2.0",
    "react-dom": "18.2.0",
    "react-dropzone": "^14.2.3",
    "react-hook-form": "^7.49.2",
    "react-loading-skeleton": "^3.3.1",
    "react-markdown": "^8.0.7",
    "react-pdf": "^7.3.3",
    "react-resize-detector": "^9.1.0",
    "react-textarea-autosize": "^8.5.3",
    "simplebar-react": "^3.2.4",
    "stripe": "^13.7.0",
    "tailwind-merge": "^1.14.0",
    "tailwindcss": "3.3.3",
    "tailwindcss-animate": "^1.0.7",
    "typescript": "5.2.2",
    "zod": "^3.22.4",
    "zustand": "^4.4.7"
  },
  "devDependencies": {
    "@types/bcryptjs": "^2.4.6",
    "@types/jsonwebtoken": "^9.0.5",
    "@types/lodash": "^4.14.202",
    "@types/node": "20.6.3",
    "@types/react": "18.2.22",
    "@types/react-dom": "18.2.7",
    "@typescript-eslint/eslint-plugin": "^6.14.0",
    "@typescript-eslint/parser": "^6.14.0",
    "eslint": "^8.56.0",
    "eslint-config-prettier": "^9.1.0",
    "eslint-plugin-react": "^7.33.2",
    "prettier": "3.1.1"
  }
}

Please give me enough information to solve the error or how to solve the error. 🙏🙏🙏🥺🥺

It may be node only 😢 we will update docs accordingly

It may be node only 😢 we will update docs accordingly

But I used it only in NextJs APIs.

Same problem with me, all my next js API routes are getting invalid after installing officeparser. Do you found any solution for this?

I don't think it's supported outside of Node envs - what if you remove export const runtime = "edge";?


using model

How to pass image to trained model to get reconstruction?

im having same question, can anyone please advise?

I'm afraid you would need to modify the source code. This project was just a proof of concept and I simply don't have the free time to work on it any further. Sorry about this.

Only the proof of concept  of training  not  predict ?


README: update Feedstock Maintainers

Checklist

[x] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

@sugatoray Please add me (from Vizzu team) into Feedstock Maintainers. Thanks.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

@veghdev Have you maintained any conda-forge package before or authored any new recipe to add any PyPI package to conda-forge before?
If not, I would prefer to walk you through a few things first, before adding you as a maintainer.
Also, the README is autogenerated. We must never update the README.
What I would suggest is that you send a PR to this repository and update the recipe (meta.yaml file). If you have any questions there, I will be glad to help you out.
For now I am closing this PR. Let's get you acquainted with how to update the package here and maintain the recipe first.

@veghdev Have you maintained any conda-forge package before or authored any new recipe to add any PyPI package to conda-forge before?
If not, I would prefer to walk you through a few things first, before adding you as a maintainer.
Also, the README is autogenerated. We must never update the README.
What I would suggest is that you send a PR to this repository and update the recipe (meta.yaml file). If you have any questions there, I will be glad to help you out.
For now I am closing this PR. Let's get you acquainted with how to update the package here and maintain the recipe first.

@sugatoray Thank you. I am not experienced in conda yet, but I am going to read about it :)
I got it, I will edit the meta.yaml.
I would like to join as a maintainer to keep the description up to date, approve auto PR-s when we release new version etc.

@veghdev Auto PRs typically, if ran successfully, get merged automatically (by another bot). So, maintainers need not work on that.
But when the dependencies change, sometimes (or, often, depending on the stage of the library's development) manually fixing the recipe becomes necessary.
I am glad that you would like to maintain the feedstock. This is very much appreciated. But, this does not need you to be a maintainer in the first place. A PR to the feedstock will also suffice.
In my experience, adding upstream repo contributors as maintainers of the feedstock did not often work out effectively, if they already did not have enough experience with updating/maintaining conda-forge packages.
So, while I maintain over 60 feedstocks and it's a blessing when people show interest in co-maintaining the feedstocks, unless the volunteers are properly empowered with some practical experience of how to maintain the feedstocks, such collaborations did not effectively work as most often they would only remain as dormant maintainers.
So, I would like to add you as a maintainer, once we have at least worked with one-two such update cycles.
I can help you learn the ropes, if you are willing to. But merely adding you as a maintainer, will not help until you can create new conda-forge recipes if necessary (this is often needed).
If you are open to letting me help you create the recipe file when the next update happens, let's set up a meeting session and show you what is necessary in a live session.

@sugatoray Thanks, I appreciate your help and understand your concerns.
I would like to actively participate in the maintenance as I do with our other Vizzu packages.
However I have little experience with conda, so I would be very grateful if you could review this at the beginning.
Of course you can keep our maintenance PR-s open until we work together.
Furthermore I think it would be an advantage that someone from Vizzu has access (but only after your worries are gone).

@veghdev Thank you for understanding. I look forward to adding you as a co-maintainer to both ipyvizzu and ipyvizzu-story feedstocks. And thank you for offering to co-maintain.
Yes, it is the ideal solution to have someone from the upstream repository to have on the list of maintainers for the conda-forge feedstock. 🚀


better to use the repository field

To allow Crates.io , lib.rs and the Rust Digger to link to it. See also the manifest.

Thanks!


Dragging outside the url bar makes the next click select everything.

Focus something other than the url bar.
Press the mouse button to start selection then drag outside the url bar and release.

Next time you click in the url bar everything gets selected.

Expected:
Selection in URL bar becomes collapsed on next click


feature: Implement hybrid search on BYOD endpoint.

Purpose
Before this change, the /api/conversation/byod endpoint did not use hybrid search - it only used "simple" or "semantic" query types, based on whether semantic search was enabled.
This PR changes the query types to vector_simple_hybrid and vector_simple_hybrid respectively.
Does this introduce a breaking change?

[ ] Yes
[x] No

How to Test
Deploy CWYD.
Ingest a file and test whether chat works with and without semantic search enabled.

Is this for #295?

Is this for #295?

Yes.

Is this for #295?

Yes @ross-p-smith. I updated the PR description.


[WIP] Support ”cherry-picked” requires

This PR will make it so that any individual file can be required and work as expected (e.g. require "dry/monads/result").
To avoid circular requires, I've started with @flash-gordon's suggestion to make it so that each monad class only provides "stub" implementations of their conversion methods that raise helpful errors, e.g.
require "dry/monads/result"

Dry::Monads.Success("hello").to_maybe
# RuntimeError: Load Maybe first with require 'dry/monads/maybe'

And the real implementation of each conversion method is provided by the file of the class that is the target of the conversion:
require "dry/monads/result"
require "dry/monads/maybe"

Dry::Monads.Success("hello").to_maybe
# => Some("hello")

TODO:

[x] Extract all conversions
[ ] Add tests for errors raised in stub implementations

My last few commits here demonstrate the other side of this work: declaring the top-level Dry::Monads  constructors/constant aliases inside each individual file (which I've demonstrated with result.rb so far).
And I've also added a spec that does the usual $LOADED_FEATURES/remove_const tricks to be able to verify that the conversion method stubs raise errors when their target monad file isn't required yet.
I'll expand this work to cover all the files shortly.
This leaves one big thing: how do we make it so include Dry::Monads can still work, to include them all? i.e. this bit:
    def self.included(base)
      super

      # TODO: Fix once CONSTRUCTORS is empty
      base.include(*CONSTRUCTORS)
    end

Could we make a special dry/monads/all.rb which adds this behaviour? Any other ideas, @flash-gordon?

@flash-gordon You happy with the approach I started in https://github.com/dry-rb/dry-monads/pull/58/commits/4ee57cf6c1ec3214065db61dd0395bd67b1bce69?

@timriley this looks fine 👍
I somehow missed the email about all.rb, sorry about that. I like the approach, let's have dry/monads/all.rb which loads all the monads and defines the included hook. We can also have a default included with a warning which says "you need to load 'all' first in order to import constructors", wdyt?

@flash-gordon finally sorted some things out and I think this is ready for review now.
There are 3 things I wanted to point out from my work on this in the last couple of days:

In conversion_stubs_spec.rb, I tried various approaches of simulating the library not yet being fully loaded (e.g. un-defining all constants under Dry::Monads), but that ended up wreaking havoc on the rest of the test suite, causing errors everywhere. The approach I settled on at the end is a lot more "surgical", e.g. directly undermining the method we want to test the stub for, and then re-requiring the file to add the method back afterwards so its available for the rest of the suite. I feel like this is a fair compromise – how does it feel to you?
In dry/monads.rb, I adjusted .included to check for the CONSTRUCTORS constant provided by dry/monads/all.rb to determine whether to include the constructors or raise an error. I did try to work out some kind of inheritance-based approach for providing this behaviour, but nothing sat very well given that dry/monads/all doesn't actually provide its own module.
Like (1), in all_monads_inclusion_spec.rb, instead of fully unloading things, I've just removed the CONSTRUCTORS const temporarily to test the behaviour of raising the error when dry/monads/all hasn't been required.

Since it's been quite a circuitous path getting here, once you're happy with things, I squish all the commits here and we can get this merged :)

yeah, this looks great to me, thank you @timriley gonna test it and push beta2

Oh great, you’re the best, thanks!

On 20 May 2018, at 10:25 am, Nikita Shilnikov<EMAIL_ADDRESS>wrote:
@timriley I squashed them with GH bffa1b6
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


timeout header_read_timeout set, but no timer set

wstunnel panic when the client is trying to connect both client & server are updated to latest v10 update

It will be fixed in a few minutes by the new release sorry :x

It is fixed in the latest release v10.0.1, sorry about that again


[Bugfix] Prevent JVM from handling signals

What type of PR is this：

[x] bug
[ ] feature
[ ] enhancement
[ ] refactor
[ ] others

Which issues of this PR fixes ：

Fixes https://github.com/StarRocks/StarRocksTest/issues/474
Problem Summary(Required) ：

When the signal SIGINT or SIGTERM coming, the process BE captures it and performs graceful exit operations by order. For example, when a SIGTERM coming,

The process captures SIGTERM to make start_be() can be returned.
The thread TaskWorkerPool, which uses StarRocksMetrics::instance, is desctructed, when the function start_be() returns.
__run_exit_handlers desctruct all the static variables including StarRocksMetrics::instance.

However, JVM overwrites the handlers of SIGINT and SIGTERM. Then,  the sequential graceful exit operations are breaked. start_be() has no chance to return, so StarRocksMetrics::instance will be desctructed while The thread TaskWorkerPool is running.

run starrocks_clang-format

run starrocks_fe_unittest


Feature/geode 735

Added OffHeapHelperJUnitTest class

Hi Ken,
This pull request has a lot of other commits. Can you please close this and open another pull request by following the instructions here https://cwiki.apache.org/confluence/display/GEODE/Code+contributions

Looks like my fork wasn't clean when I created the PR. Closing this one, will open a new one when I get things clean.


Fix dimension table load when server restart or reload table

Currently DimensionTableDataManager overrides the addSegment(File indexDir, IndexLoadingConfig indexLoadingConfig) method to reload the lookup table, but this method is not always invoked when adding the segment. Fix the issue by overriding addSegment(ImmutableSegment immutableSegment) which is always invoked when adding the segment.
Other changes:

Enhance the validation for schema and primary key and fail with proper exception message
Enhance the test to mimic the actual flow of reloading the segment

Codecov Report

Merging #8721 (5c84901) into master (3bbae6e) will increase coverage by 3.41%.
The diff coverage is 76.00%.

@@             Coverage Diff              @@
##             master    #8721      +/-   ##
============================================
+ Coverage     66.20%   69.62%   +3.41%
- Complexity     4389     4576     +187
============================================
  Files          1279     1729     +450
  Lines         64619    90183   +25564
  Branches      10089    13415    +3326
============================================
+ Hits          42781    62786   +20005
- Misses        18802    23044    +4242
- Partials       3036     4353    +1317

Flag
Coverage Δ

integration1
26.96% <0.00%> (?)

integration2
25.34% <0.00%> (?)

unittests1
66.13% <76.00%> (-0.07%)
:arrow_down:

unittests2
14.27% <0.00%> (?)

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

Impacted Files
Coverage Δ

...ata/manager/offline/DimensionTableDataManager.java
82.14% <76.00%> (-2.48%)
:arrow_down:

...ore/query/scheduler/resources/ResourceManager.java
84.00% <0.00%> (-12.00%)
:arrow_down:

.../impl/dictionary/BaseOffHeapMutableDictionary.java
81.33% <0.00%> (-3.34%)
:arrow_down:

.../pinot/core/query/scheduler/PriorityScheduler.java
78.08% <0.00%> (-2.74%)
:arrow_down:

...e/pinot/segment/local/io/util/PinotDataBitSet.java
95.62% <0.00%> (-1.46%)
:arrow_down:

...org/apache/pinot/core/common/ObjectSerDeUtils.java
89.57% <0.00%> (-0.82%)
:arrow_down:

.../aggregation/function/ModeAggregationFunction.java
87.56% <0.00%> (-0.82%)
:arrow_down:

...he/pinot/segment/local/utils/SegmentPushUtils.java
12.70% <0.00%> (-0.22%)
:arrow_down:

...ingestion/batch/spec/SegmentGenerationJobSpec.java
53.33% <0.00%> (ø)

...ent/local/data/manager/TableDataManagerConfig.java
0.00% <0.00%> (ø)

... and 688 more

Continue to review full report at Codecov.

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


[unterstützer] remove page

has no additional information value (covered in FAQ)
drop it like it's hot.

is that done by removing the corresponding mod.routeand following code for hall-of-fame?


Fix compiler warnings from Apache AvalonLogger

Description (required)
Fixes #2632

Codecov Report

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

@@          Coverage Diff           @@
##           master   #2631   +/-   ##
======================================
  Coverage    2.77%   2.77%
======================================
  Files         259     259
  Lines       12365   12365
  Branches     1116    1116
======================================
  Hits          343     343
  Misses      11995   11995
  Partials       27      27

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 8e8558a...3d6056c. Read the comment docs.


When DO retires an image, it breaks image listing

Example:
ross@air:~/duggan/pontoon (master)$ pontoon droplet list
foo-api-1:   (512MB, 1505447 [could not determine image name], Amsterdam 2, <IP_ADDRESS>, active)
ross@air:~/duggan/pontoon (master)$ pontoon droplet show foo-api-1
No image found for id 1505447

I suspect the V2 API will have solved this somehow, will close until it can be reproduced.


Add "Starts With" as a drop down option in the Operator field for Filter

Within the Filter Settings dialog, in the Operator field, add "Starts With" as a drop down option.  This would be useful for scenarios where the text matches a large number of objects using Contains, but folks are only interested in seeing objects that start with the text
Contains: WHERE Name LIKE '%Sales%'
Starts With: WHERE Name LIKE 'Sales%'

Fixed by #23422


[MC-Version] 1.19 Fabric

Detailed description of the feature
Just wondering if 1.19 fabric will be released
Verify feature request

[X] I have checked that this is not a duplicate feature request and the feature does not yet exist in the latest version

Duplicate of #24

Sorry I was on the forge GitHub page and forgot I had already made an issue on the fabric page, and forgot that the fabric version was a separate page


Update Readme.md game list fixes i fixes all the games and make them in serial order

PR Description 📜
Please include summary related to the issue you have fixed and describe your PR in brief over here by specifying the issue number on which you were working below
Fixes # <4099>

Mark the task you have completed ✅

[ ] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[ ] I have performed a self-review of my own code or work.
[ ] I have commented my code, particularly in hard-to-understand areas.
[ ] My changes generates no new warnings.
[ ] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[ ] I have added screenshot for website preview in assets/images
[ ] I have added entries for my game in main README.md
[ ] I have added README.md in my folder
[ ] I have added working video of the game in README.md (optional)
[ ] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸

Thank you soo much for contributing to our repository 💗

Thank you @AkashKeote ,for creating the PR and contributing to our GameZone 💗
Review team will review the PR and will reach out to you soon! 😇
Make sure that you have marked all the tasks that you are done with ✅.
Thank you for your patience! 😀

Hey @AkashKeote,
Please make sure to link the relevant issue using the appropriate syntax, such as "#issueNumber" 👀.
Follow the proper guideline and make a new PR again 😀.
Happy Hacking 💗


Add Host for virtual machines

Would it be possible to add the name of the host when the machine is virtual (to the Info tab under Configuration)?  I think this solution may only work for HyperV hosts, but maybe someone will know how to get it for VMWare as well.
DECLARE @value VARCHAR(100)
EXEC master..xp_regread
'HKEY_LOCAL_MACHINE',
'SOFTWARE\Microsoft\Virtual Machine\Guest\Parameters',
'PhysicalHostName',
@value = @value OUTPUT
SELECT TOP 1 @value AS PhysicalHostName

Cool.  That might be something I could add to this collection.  It already pulls a couple of things out of registry keys if it has access to.


Is there any reason why FileDownloadMgr, DefaultDatabaseImpl, DefaultDatabaseOpenHelper are not public?

The fact that they are not public they can't be used in an app that has FileDownloader as a dependancy.

Because it's very dangerous to do that.
When I write code for such Classes, I never consider the case of that, it can raise many fatal problems for you to use FileDownloader when you do that.

If there are problems on there, VERY WELCOME PR.
If you think it can be more flexible, VERY WELCOME PR.

Sweet Tips: You can customize your own components on FileDownloader, ref: https://github.com/lingochamp/FileDownloader/wiki/Customizable-Component


WIP: Add PointSet percentile selection to PointSetToPointSetMetric

A percentile option allows to drive the registration using only the
percentile points returning the smallest error. This is a reasonable
hypothesis if the moving and fixed point sets are initialized in
a position where corresponding points are close. Setting the
percentile option to 100 returns the same result as the algorithm prior
to this patch would have returned.

One additional option to consider would be using a threshold in lieu of the percentile. For cases in which you know the point sets only have partial overlap and a good initialization this might be more intuitive than selecting a percentile (and it would be marginally faster since you don't need to sort the distances).

Maybe consider checking if m_Percentile is set to 100 and in that case not sort the distances.

Good ideas. Any takers to implement @samuelgerber 's ideas? :)

We briefly toyed around with adding something like this in the original implementation but ultimately decided against it.  We felt that, similar to the image analog, any preprocessing or pruning functionality of the input data should be performed outside any metric function.  For example, in considering the image analog, one wouldn't implement cropping within the ImageToImageMetric (which would currently be done prior and with a separate ITK class).  Also, it seems to me that the way that the point set is pruned in this case is based on distance determined on a point-by-point basis which isn't necessarily what you want to do in general for all point-set cases.  I would vote against merging.

@ntustison Having it as a preprocessing step would keep the registration framework simpler and apply to all metrics. On the other hand one can argue that it acts similar to setting a mask in the image registration framework. And if it is integrated in the metric the points used are adapted during the optimization which does not seem to be feasible when doing it as a preprocessing step.

@ntustison since you're here. I was considering adding a caching option to the metric, such that the nearest point index does not have to be recomputed during every iteration of the optimization. Any thoughts on this?

@samuelgerber  Yeah, I can see the analogy to masking but only in the loose sense of limiting the data considered within the metric.  However, in the context of ITK-usage, we have spatial objects specific for masking and that’s not what is being used here.  This is more akin to a rather blunt heuristic for pruning data.  I think the analogy to masking is also stretched when you consider how the “masking” here is actually being performed.  Instead of limiting the points according to the boundaries of some spatial object, the point-wise distances are being calculated, sorted, and then pruned according to a desired percentage.  I don’t see where this is analogous to the image case.
The adaptive argument in favor of this change also seems a bit suspect to me.  This pruning process appears to be somewhat computationally redundant as the individual metrics themselves consider point-wise distances at each iteration and essentially limit the influence of points which are far away.  And this is done in a much more systematic and formal manner, as defined by the individual metrics, than is being performed here.  I honestly don’t see how this would be useful and warrant the additional costs of code maintenance and potential feature creep.
Regarding the caching idea—sure, any possibilities for speed-up would be great but I can see where the transform updates at each iteration would require that the nearest point index be updated and I don’t see how this bookkeeping could be performed in a way such that you’d save processing time in the end.

@ntustison I think this implementation was mostly targeted at the EuclideanDistancePointMetric in which far away point can drive the optimization. My comment on caching was also with respect to that metric.
While the other metrics might do a good job at weighting far away distances, ultimately they implement a distance between probability measures as far as I understand, and thus consider always the overall match. If one would like to achieve a partial matching they might not be suited for that either, since even if there is a good partial match it might be beneficial to spread the points over a larger region to achieve an overall closer match between the probability distributions.

@samuelgerber  Correct me if I’m misunderstanding what you wrote but I would agree that it’s quite clear that the ICP, or Euclidean distance, metric is particularly susceptible to the presence of outliers which has partially motivated the development of other point set metrics.  If this merge candidate is meant to address that susceptibility, then I would think it should be implemented within that metric.  However, even then I’m highly skeptical that this blunt pruning procedure actually addresses this deficiency or addresses the more complicated issue of partial matching—at least I haven’t seen evidence of such presented in the literature (but am certainly open to reading something on the topic).   Please understand that my only motivation for down-voting something like this is my own subjective simple cost/benefit weighting of the proposed changes (code maintenance and feature creep vs. real world-utility).  I’d certainly go along with the other reviewers in the case of otherwise mutual disagreement.

@ntustison I don't have a strong preference. But I think it's an approach worth considering and has been around in the literature for while: https://ieeexplore.ieee.org/abstract/document/1047997
Whether this is better implemented as a pruning step or in the metric is up for debate. I think the possibility to not completely throw out points and allow refinement during the optimization has some merit.

@ntustison I guess an alternative middle ground would be to subclass the Euclidean Metric with a Trimmed Euclidean Metric.

@samuelgerber Yeah, that would be a great idea.  Thanks for the link.  I didn't get time to look at it today but will probably tomorrow.

Closing this. I will implement a version of this in a remote module here:
https://github.com/samuelgerber/ITKTrimmedPointSetRegistration
If it ends up working well and it can later be integrated.

A working implementation is now available at:
https://github.com/samuelgerber/ITKTrimmedPointSetRegistration
an initial simple example suggest it could be quite useful


Get balance with param : Account_id

Hello,
Looking at the code it seems to me that the balance function will only return the default account, is there any way to pass an account_id as proposed in coinbase API (https://coinbase.com/api/doc/1.0/account/balance.html) ?
Cheers,

Hey @etiennetatur. Responded to the PR. Two test failing. Want to check it out and respond to the PR directly? Closing the issue so we can comment there.


Improve performance of constructing ByteViews for small strings

Part of https://github.com/apache/arrow-rs/issues/5374
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
NoteL This is copied from the wonderful description on  https://github.com/apache/arrow-rs/pull/6031 from @XiangpengHao  and @aoil-al
In our benchmark, every string is larger than 12 bytes, this means that when making the views, we always fall into this branch. The specialty about this branch is that it only reads the first 4 bytes of the string, and LLVM is smart enough to inline loading the values (i.e., prevent calling into copy_non_overlapping).
Is that a big deal?
Unfortunately, yes. If you change the benchmark string to very small, e.g., "test", you should be able to see (using the same benchmark script above) the performance of loading ViewArray drops significantly, and it doesn't make sense -- how could building StringViewArrays wit shorter strings be so much slower than building longer strings?
The root cause is that when string is short, we need to memcpy the bytes to the view, as the compiler has no idea how long the string is, it can not inline the bytes and has to call to memcpy, which is slow.
Describe the solution you'd like
I would like to improve the performance of StringView creation more
Describe alternatives you've considered
here's a special variant of make_view, you can replace this function with the following new implementation, and the performance improves.
This new implementation makes 13 copies of make_view_inner; each copy is a specialized length known to the compiler (LEN is const), and then the compiler can optimize each of the implementations as needed. Looking at the assembly code, there is indeed no call to memcpy.
/// Creates a view from a fixed length input (the compiler can generate
/// specialized code for this)
fn make_view_inner<const LEN: usize>(data: &[u8]) -> u128 {
    let mut view_buffer = [0; 16];
    view_buffer[0..4].copy_from_slice(&(LEN as u32).to_le_bytes());
    view_buffer[4..4 + LEN].copy_from_slice(&data[..LEN]);
    u128::from_le_bytes(view_buffer)
}

/// Create a view based on the given data, block id and offset
#[inline(always)]
pub fn make_view(data: &[u8], block_id: u32, offset: u32) -> u128 {
    let len = data.len() as u32;
    // Generate specialized code for each potential small string length
    // to improve performance
    match len {
        0 => make_view_inner::<0>(data),
        1 => make_view_inner::<1>(data),
        2 => make_view_inner::<2>(data),
        3 => make_view_inner::<3>(data),
        4 => make_view_inner::<4>(data),
        5 => make_view_inner::<5>(data),
        6 => make_view_inner::<6>(data),
        7 => make_view_inner::<7>(data),
        8 => make_view_inner::<8>(data),
        9 => make_view_inner::<9>(data),
        10 => make_view_inner::<10>(data),
        11 => make_view_inner::<11>(data),
        12 => make_view_inner::<12>(data),
        _ => {
            let view = ByteView {
                length: len,
                prefix: u32::from_le_bytes(data[0..4].try_into().unwrap()),
                buffer_index: block_id,
                offset,
            };
            view.into()
        }
    }
}

(special thanks to @aoli-al for triangulating the root cause and prototype the fix)
While the above is somewhat non intuitive, if it improves performance and is sufficiently commented, it would be a good thing to add
Additional context

For anyone of the compiler persuasion, I think the code above is basically a form of loop unrolling (the loop is in memcpy) for certain constants that we know will be hit

Another pattern that works well for small copies and generates much smaller code than full specialization, is using divide and conquer, copy as large a chunk as possible followed by consecutive smaller chunks. Would look something like this on a simplified example:
pub fn make_view2(mut data: &[u8], block_id: u32, offset: u32) -> u128 {
    let len = data.len() as u32;
    let mut tmp = [0_u8; 16];
    tmp[..4].copy_from_slice(&len.to_le_bytes());
    let mut i = 4_usize;

    if data.len() >= 8 {
        tmp[i..i+8].copy_from_slice(&data[..8]);
        i += 8;
        data = &data[8..];
    }
    if data.len() >= 4 {
        // unsafe { std::intrinsics::assume(i+4 <= tmp.len()); }
        tmp[i..i+4].copy_from_slice(&data[..4]);
        i += 4;
        data = &data[4..];
    }
    if data.len() >= 2 {
        // unsafe { std::intrinsics::assume(i+2 <= tmp.len()); }
        tmp[i..i+2].copy_from_slice(&data[..2]);
        i += 2;
        data = &data[2..];
    }
    if data.len() >= 1 {
        // unsafe { std::intrinsics::assume(i < tmp.len()); }
        tmp[i] = data[0];
        i += 1;
        data = &data[1..];
    }

    u128::from_le_bytes(tmp)
}

This also avoids bounds checks on data, but unfortunately not on the last accesses to tmp array.

Update here that I benchmarked @jhorstmann 's implementation through #6101 but the performance did not improve much. I digged slightly deeper into this and convinced myself that the overhead is the function call to ptr::copy_non_overlapping.
An experiment with test string length of 1 shows the performance is still very slow, indicating that the loop unrolling is not the bottleneck here.

Just wonder if this problem is due to some optimization or other reason, I've tested some similar code in C++: https://godbolt.org/z/czePsTofc . And find the difference between makeInline2 would work better on string with same length but when string length change fastly it would run slower.

but when string length change fastly it would run slower.

Can you elaborate a bit more on this? @mapleFU
My understanding is that some string length are fast, e.g., 4 and 8, becuase they align with register width. Some string length need more instructions, e.g., 7, 11, because they need to load more data then shift to clear out the unused bits.
Because of that, testing with fixed 4-byte string can be quite faster than testing with varying lengths.

https://godbolt.org/z/czePsTofc : makeInline2 would try to generate lots of branching by switch, and if all string would likely to keep the same length, the code would like memset & memcpy for previous version:
        call    memset@PLT
        mov     rdi, r14
        mov     rsi, rbx
        mov     rdx, r15
        call    memcpy@PLT

on the otherside, makeInline2 would generate different function depending on bit-width. For example:
.LBB1_2:
        movzx   esi, byte ptr [rdi]
        xor     edx, edx
        shl     rsi, 32
        or      rax, rsi
        ret
.LBB1_3:
        movzx   esi, word ptr [rdi]
        xor     edx, edx
        shl     rsi, 32
        or      rax, rsi
        ret

If branch prediction works well, same function would be called again and again.

some string length are fast, e.g., 4 and 8, becuase they align with register width.

AFAIK, if same instr is used, and no cross cache-line memory visiting, memory copying instr would not suffer from unaligned access? ( Maybe I'm wrong )

If branch prediction works well, same function would be called again and again.

Did you observe the branch prediction suffers on string with varying lengths? That's very interesting! Would love to look at the benchmark code!
I think the rust implementation only has one conditional branch, i.e., len > 12. If len is smaller than 12, it calcuates the offset and unconditionaly jump to the corresponding offset, which should not cause pressure on the branch predictor.

with help of compiler assume

That's a very cool idea! That would lead to cleaner and more efficient code. But it seems that Rust don't suppor them yet.

Did you observe the branch prediction suffers on string with varying lengths?

Yeah, I'm interesting on this optimization so I tried on C++ code but find it may not so well if string length change fastly. But anyway it's a bit faster than calling memcpy on Clang
And I just think out that maybe performance for different string length would not so difference because of store buffer forwarding 🤔 Some analysis might required here

The compiler need -C  opt-level=3 flag to see optimized code

label_issue.py automatically added labels {'parquet'} from #6101

label_issue.py automatically added labels {'arrow'} from #6102

I opened an issue in LLVM https://github.com/llvm/llvm-project/issues/106895
I believe gcc optimized code is also good, would waiting for it released


Contents padding and multiline usage

PR of #14
Add contents padding parameter to consider constraints.
Merged secondTextSpan comparing when text length is greater than 0.
When maxLines = null, fitting method varies.

Hi @hyobbb, thank you very much for the PR. Sorry for late reply. I was occupied for some reasons.
Do you mind resolving the merge conflicts?
A few screenshots that demonstrate your fix will also be helpful for the community to know what they are about.
Greatly appreciate your PR. 🚀

Hey @lzhuor . I will change some code for null safety and then revise it.

@lzhuor Hi. I applied null safety to my code. I changed maxlines property from not-nullable to nullable because it is necessary to be null to implement multi-line textfield without limitation. Also I uploaded mulitline usage example in my repo so please check this out if you need this for readme file.

@hyobbb That's so nice of you! Thank you! Will review the code change!

Hi @hyobbb Do you mind PR the example and README.md change also in this PR? It will be easier for folks to review as well. Btw, awesome stuff. Excited. 💯

Hi @hyobbb Do you mind PR the example and README.md change also in this PR? It will be easier for folks to review as well. Btw, awesome stuff. Excited. 💯

I will do it by this week and let you know!

@lzhuor Please check the last commit. I put new gif demo to maxline part.

Thanks @hyobbb  Checking.

@hyobbb Should CHANGELOG also be updated? It also looks we should bump the version to 1.0.0+1
Other than that, anything blocking this @lzhuor?

Thank you @hyobbb. Merged. Apologies for the delay. I was running some personal errands.
Yes, I will update the CHANGELOG and bump the version.


refactor: add eslint-plugin-import and apply rules

Codecov Report

:exclamation: No coverage uploaded for pull request base (lit-migration@e813c44). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
@@               Coverage Diff                @@
##             lit-migration    #2162   +/-   ##
================================================
  Coverage                 ?   92.65%
================================================
  Files                    ?       53
  Lines                    ?     2409
  Branches                 ?      255
================================================
  Hits                     ?     2232
  Misses                   ?      175
  Partials                 ?        2

:mega: Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today!


[QUERY] Is there a way to grant ROLE_ADMIN with azure-spring-boot-sample-active-directory-backend

Query/Question
I'm playing with the /azure-sdk-for-java/sdk/spring/azure-spring-boot-samples/azure-spring-boot-sample-active-directory-backend example and I see that it always grants ROLE_USER. Is there a way to make it also grant ROLE_ADMIN based on certain group membership?
Why is this not a Bug or a feature Request?
A clear explanation of why is this not a bug or a feature request?
Because I'm not sure if this is possible, it's not documented anywhere which would lead you to say it's a feature request, but because in my experience there's loads of undocumented features everywhere, I'm curious if this is one of them.
Setup (please complete the following information if applicable):

OS:  Centos 7
IDE :  Spring tool suite
Version of the Library used 1.0.0

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Query Added
[x] Setup information Added

@jialindai could you please help route this issue?

I've found that it is kind of possible: https://github.com/Azure/azure-sdk-for-java/tree/master/sdk/spring/azure-spring-boot-starter-active-directory#authenticate-stateless-apis-using-aad-app-roles
However it doesn't work: https://github.com/Azure/azure-sdk-for-java/issues/17171

Replyed in #17171 , for the usage of app roles, please refer to the stateless sample.

Closing this issue now.

Closing this issue now.


Exposing axis.orient()

Any helpers or otherwise around working with axis are going to want to have access to the orientation.
If I write a layout library to help compose charts, or something similar, knowing what orientation an axis object is when passed in is absolutely useful.
Some other way of doing a typecheck or something other than just a getter would be good, too. But this seems straightforward and useful to inspect the orientation of a generic axis.

Let’s discuss in #16 further going into implementation.


Use double colons (::) for pseudo elements

Hello, it's recommended by the CSS3 standard to use double colons (::) for pseudo elements. See:
https://developer.mozilla.org/en/docs/Web/CSS/Pseudo-elements

Thanks for catching that! Since this is small change I'm going to just roll it into a separate upcoming PR.

Sure, feel free to close this PR when it's done 👍


Fix dropdown selection styling to match Bootstrap/Geeksui

Selections on dropdowns do not display the bootstrap/geeksui styling. The dropdown selections appear to be displaying the browser default. Tested in Chrome and Firefox.

Below shows the Geeks UI styling
https://geeksui.codescandy.com/geeks/docs/dropdowns.html

I can try to work on this.

@jmilljr24 @Tomaszabc
I think the issue is that these are using select tags and not drop down elements. From the GeeksUI docs for forms, it looks like the select tag options use the browser/os defaults.
I'm sure there's a way to get the select options to look like the drop down menu (possibly with the help of something like https://developer.snapappointments.com/bootstrap-select/) but I don't think it's an issue of the styling not being applied.

@jmilljr24 @Tomaszabc
I think the issue is that these are using select tags and not drop down elements. From the GeeksUI docs for forms, it looks like the select tag options use the browser/os defaults.
I'm sure there's a way to get the select options to look like the drop down menu (possibly with the help of something like https://developer.snapappointments.com/bootstrap-select/) but I don't think it's an issue of the styling not being applied.

Ah, I see. I didn't realize the select dropdown didn't use the styling applied to the other dropdown buttons. Thanks for pointing that out!
I was looking over the project designs in figma and saw the stylized dropdowns. When interacting with the live site it stood out to me that the dropdowns had styling while others were the browsers defaults.
This is probably more trouble than its worth to change if the maintainers are happy with the default for select. I'm happy to close this if that is the case.

Yeah, we should probably close this issue.


upgrade upload

Please makes sure these boxes are checked before submitting your PR, thank you!

[ ] Make sure you follow Element's contributing guide (中文 | English).
[ ] Make sure you are merging your commits to dev branch.
[ ] Add some descriptions and refer relative issues for you PR.

支持手动上传
增加 listType API
增加 onChange 钩子
部分 API 更新

done


Add LICENSE & VERIFICATION chocolatey requirements to nuspec

Fixes #137  - Adds appropriate verification files.

:white_check_mark: Build ServiceBusExplorer 4.0.102-PullRequest0142.3.build.283 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/0ee2be8d08 by @Nate-Wilkins)

:x: Build ServiceBusExplorer 4.0.102-PullRequest0142.4.build.284 failed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/d9349a62d6 by @Nate-Wilkins)

:white_check_mark: Build ServiceBusExplorer 4.0.102-PullRequest0142.5.build.285 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/8bf8d1c6ce by @Nate-Wilkins)

:white_check_mark: Build ServiceBusExplorer 4.0.102-PullRequest0142.6.build.286 completed (commit https://github.com/paolosalvatori/ServiceBusExplorer/commit/8bf8d1c6ce by @Nate-Wilkins)

I'm still thinking a single file reference is a better approach, but if
this is working, let's get over with it. It was the longest PR ever 😃
On Aug 10, 2017 00:19, "Tom Kerkhove"<EMAIL_ADDRESS>wrote:

@tomkerkhove commented on this pull request.
In VERIFICATION.txt
https://github.com/paolosalvatori/ServiceBusExplorer/pull/142#discussion_r132371618
:

@@ -0,0 +1 @@

I think we'll have to follow their format - Example
https://github.com/chocolatey/chocolatey-coreteampackages/blob/master/automatic/x2go/legal/VERIFICATION.txt
We could create the list and "tokenize" this example. Not sure if they
enforce this or not though
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/paolosalvatori/ServiceBusExplorer/pull/142#pullrequestreview-55442788,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABP7tlLlaUNl9PwOHq3Xw3NM-L1ZoAtVks5sWqD_gaJpZM4Oy-Vx
.

Merging it in, we can improve later on, if required.


developers.sap.com tutorial help

Hi Thomas,
I followed up the tutorial from here.
https://developers.sap.com/mission.hana-cloud-cap.html
Everything is working well. I just wonder if there is an existing tutorial which is focusing on the production deployment for a similar CAP-HANA project like this.
Appreciated in advance.

No we never created a tutorial series in developers.sap.com for this sample code.  However I did record a video series of creating this sample: https://www.youtube.com/playlist?list=PL6RpkC85SLQAHZ_V3cZsTok0T6BvI4HT1


[ENG-503] load primary email on init; use component.set() instead of native setter to trigger recompute

Purpose
Currently if you have two factor authentication enabled but not confirmed, the account settings page would not show the QR code for 2FA. The problem lies with the fact that we only load primary emails upon clicking the Configure button.
Summary of Changes
Perform the loadPrimaryEmail task in init(). Inside the task, use component.set() instead of native setters because native setter doesn't trigger recompute of dependent computed properties.
QA Notes
Enable 2FA on the account settings page but do not confirm. Then refresh the page and make sure the QR code shows up.
Ticket
https://openscience.atlassian.net/browse/ENG-503
Reviewer Checklist

[ ] meets requirements
[ ] easy to understand
[ ] DRY
[ ] testable and includes test(s)
[ ] changes described in CHANGELOG.md

Pull Request Test Coverage Report for Build 2951

1 of 1 (100.0%)  changed or added relevant line in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 72.009%

Totals

Change from base Build 2949:
0.0%

Covered Lines:
6176

Relevant Lines:
7726

💛  - Coveralls


Missing from lean 4: "∀ x < n" binders

In lean 3, you can use (x y z OP e) as a binder whenever OP is a binary operation, and it abbreviates the binder sequence (x y z : _) (H : x OP e) (H : y OP e) (H : z OP e).
example : ∀ x < 5, x < 5 := λ x H, H

Lean 4 doesn't have a general mechanism for infix notations, so these have to be added individually for every combination of binding notation and operator (i.e. ∀ x < e, p x and ∃ x < e, p x and ∃ x ∈ S, p x all need to be defined separately). It is unclear what we even want to do here for translation purposes besides simple expansion.

Some potential overlap with the "bigop" example from our macro paper https://github.com/leanprover/lean4/blob/2b451a3fed237f72da7e20f6b7062cf118114880/tests/lean/run/bigop.lean#L43-L50

Would it be possible for "binder group" to be a syntax class? Right now I think there are 3 or 4 different binder-like syntax classes in lean 4, which isn't great, and they all have more limitations than the "binders" syntax class of lean 3. I think the "index" class as in your paper needs to be defined in lean 4 core and needs to be used in forall and exists to be really useful; a user-defined index class is only helpful for new syntax added by the user.

Should they really be binders again? I thought most people agreed that in Lean 3 neither the generic desugaring nor the fact that you could use them anywhere a binder is expected was exactly optimal.

Ideally there should be some generic desugaring, a way to add new binder behavior for newly introduced binder syntax, and a way to do "double dispatch" for especially unusual combinations of binder and leader. I don't think that binder collections as a generic mechanism working anywhere binders do is a bad thing, but the generic desugaring of multiple binders is unfortunate for some binders, like exists unique, where iterating the combinator/lambda doesn't work.

To be clear, in this post I'm not necessarily advocating for binder collections as implemented in lean 3, but there are many hundreds of uses of this idiom in mathlib and even an exception in the style guide just so that people can write ∀ x > n, p x instead of ∀ x, n < x -> p x, so this is clearly a desired feature and while desugaring it during translation is an option, it's not a good one.

Sure, I don't think anyone wants to live without QUANT x OP e, ..., so we should not lose that during translation. But I would not have implemented that specific pattern via a binder category. How many more complex (and convincing) uses of this feature are there in mathlib?

For example, these look pretty weird to me. But that might just be lack of familiarity on my side.
src/set_theory/cardinal.lean
710:  suffices : ∀ (n : ℕ) (m < n), F m ≠ F n,
1205:lemma powerlt_le {c₁ c₂ c₃ : cardinal} : c₁ ^< c₂ ≤ c₃ ↔ ∀(c₄ < c₂), c₁ ^ c₄ ≤ c₃ :=

Well, we use what we have. It's somewhat limited, but useful when it can be used. There are lots of things about the lean 3 binder collection syntax I would like to change, for example you can't put a type ascription on the variables, but the general mechanism that is missing that prevents the whole feature from being implemented in mathlib is that binders are not an extensible syntax category.

My point is that, if there is consensus this kind of binder is its own special thing and should not be mixed with other binders, then it should not be a member of a general binder category by used directly by each operator that wants to support it, i.e. something like binders <|> opBinder. Thus my question about how many other uses of this feature there are, and whether continuing to support them makes sense. If there are only a handful and no-one insists on keeping them, wouldn't it be easier to erase them before porting?

For example \forall x (y : Nat), True works but \exists x (y : Nat), True doesn't.

I agree this distinction doesn't make much sense, and it likely wasn't deliberate. On the other hand, I'm pretty sure it was deliberate that e.g. implicit binders cannot be used with exists, since it just doesn't make any sense. So we should refine this part of the grammar, but I don't see us using the exact same binder parser in each case.

Perhaps as a more general design criterion that Leo and I never explicitly talked about, but I think we agree on: the more extensive and extensible your grammar is, the more care should be taken in designing each grammar rule. It will be confusing enough to keep track of the many syntax variations people will introduce, so let's not make newcomers' lives even harder by providing confusing syntax combinations that don't even make sense semantically.

I agree this distinction doesn't make much sense, and it likely wasn't deliberate. On the other hand, I'm pretty sure it was deliberate that e.g. implicit binders cannot be used with exists, since it just doesn't make any sense. So we should refine this part of the grammar, but I don't see us using the exact same binder parser in each case.

I don't think this should be enforced at the parser level. That just makes everything meaninglessly more complicated. Just either error or filter out bad binder kinds during elab.

Perhaps as a more general design criterion that Leo and I never explicitly talked about, but I think we agree on: the more extensive and extensible your grammar is, the more care should be taken in designing each grammar rule. It will be confusing enough to keep track of the many syntax variations people will introduce, so let's not make newcomers' lives even harder by providing confusing syntax combinations that don't even make sense semantically.

It's not clear to me whether or not my position is compatible with this design criterion, but I value simplicity of the grammar, both literally in terms of the number of grammatical constructs, and in the user's impression of the grammar, where fewer constructs means more regularity - if a thing works in one place then it also works in all similar places. I would put implicit binders for exists in that category - just because they aren't particularly useful doesn't mean they should be a parse error, and making them such means documentation and such have to be more complicated to outline the holes that have been cut into the grammar.

My point is that, if there is consensus this kind of binder is its own special thing and should not be mixed with other binders, then it should not be a member of a general binder category but used directly by each operator that wants to support it, i.e. something like binders <|> opBinder.

I'm not sure what is what in your example. I agree that some contexts want to be able to support more kinds of binders than the usual, for example fun might accept either binder or term where binder is an extensible syntax category for binder groups. But I don't see how you imagine it would be possible to retrofit opBinder into all the locations binders are accepted, if this is done outside the core, without overriding literally every command in lean.

Thus my question about how many other uses of this feature there are, and whether continuing to support them makes sense. If there are only a handful and no-one insists on keeping them, wouldn't it be easier to erase them before porting?

I'm looking forward here, not at the port itself. It's certainly possible to erase them during porting, and indeed I'm doing this at the moment, but in the far future when mathlib is all in lean 4, I don't want to have to settle for a worse syntax than what lean 3 offers. That doesn't mean copying what lean 3 is doing, but it does mean doing something approximately equivalent. There are plenty of current uses of this idiom (your list is far from complete, although I don't think you were going for that) that indicate that something approximately like the feature is desirable.

I don't think this should be enforced at the parser level. That just makes everything meaninglessly more complicated. Just either error or filter out bad binder kinds during elab.

Well, I don't necessarily disagree. But not something for me to decide either, I didn't even write those parts of the grammar :) .

But I don't see how you imagine it would be possible to retrofit opBinder into all the locations binders are accepted, if this is done outside the core, without overriding literally every command in lean.

Same discussion as above I suppose, but surely we don't need support for this kind of binder in "literally every command" of core, but, like, four or something? Since opBinder should not overlap with any core binder syntax, redeclaring core syntax with it should just work.

There are plenty of current uses of this idiom (your list is far from complete, although I don't think you were going for that) that indicate that something approximately like the feature is desirable.

Let me rephrase my question: how many uses of this idiom that are not of the form QUANT x OP e that we all agree on are there in mathlib, ? With the query ∀[^,]*< I found the above and ∀ (i<n) (j<n) and I can't say I'm convinced... that's not even shorter than two quantifiers.

Same discussion as above I suppose, but surely we don't need support for this kind of binder in "literally every command" of core, but, like, two (four with Sigma/PSigma)? Since opBinder should not overlap with any core binder syntax, redeclaring core syntax with it should just work.

I mean, if you want to use this in binders for def, you will have to override the def command; if you want it in instance you will need to override that too, and so on. It's a game of whackamole with all possible occurrences of the production in the grammar - almost all commands transitively depend on the binder production except for trivial commands like namespace.

Let me rephrase my question: how many uses of this idiom that are not of the form QUANT x OP e that we all agree on are there in mathlib, ? With the query ∀[^,]*< I found the above and ∀ (i<n) (j<n) and I can't say I'm convinced... that's not even shorter than two quantifiers.

Other common binops used in that position include <=, > and \in. I will be able to answer this question more definitively soon, when mathport gets to the point that we can run it on all of mathlib with a minimum of errors, and then it will be possible to instrument the parser to just see how commonly the Binder.collection variant is used.


Bug?

Discussed in https://github.com/kapilratnani/JSON-Viewer/discussions/128

Originally posted by jocgoran July 22, 2022
Hello,
I am using the version <IP_ADDRESS> and I spend some hours to find that there is a bug when I switch to Format or Compressed view.
For the Double with precision grather than 15 places after comma, some numbers are omitted.
Example:
{"FieldOne":[{"DoublePrecisionMoreThan15":27.1234567890123456}]}
Try to format and you will lose the position 15.
Is this maybe fixed?
Thank you,
Very kind regards
Goran Joc

Hi Goran Joc,
This is a known issue and has dependency on the json parsing library (Rapidjosn). I will see if it is fixed in latest version of Rapidjson or any workaround for this.
Related issue: #39
Thanks
Rajendra

Closing to avoid duplicates. Will be fixed once we resolve #39.


Use SingletonStrT in case of const literal declarations

// @flow

const x = 'X';
const y: typeof x = 'Y';

Before: no errors.
After:
  4: const y: typeof x = 'Y';
                         ^^^ string. Expected string literal `X`, got `Y` instead
  4: const y: typeof x = 'Y';
              ^^^^^^^^ string

Fixes https://github.com/facebook/flow/issues/2639.
This is my first attempt to dive into Flow codebase, not sure if the implementation is sane. I would like to get some comments on this. Will add tests if everything is ok.

@samwgoldman @mroch @gabelevi any comments?

Sorry for the radio silence on this. I really like this idea! Going to import this and have the rest of the team weigh in.

any updates on this?

@samwgoldman 🙏 please, implement this feature! It's so of a principle of least astonishment :)

Please please make this happen

Oh hey, I looked a bit into what happened. Looks like this interfered with React default props for some reason, and then it fell off the radar (the flow team is busy). I'll try to find out if this is still an issue, I really like this idea.
Mind fixing the merge conflict though @agentcooper?

@mrkev I'll try to update the code over the weekend

sounds good!

@mrkev 👀

@mrkev any updates on this?
I'm trying to rebase my diff again, but I can't solve one compiler error:
File "src/typing/statement.ml", line 2499, characters 45-55:
Error: This function has type Context.t -> Loc.t Ast.Expression.t -> Type.t
       It is applied to too many arguments; maybe you forgot a `;'.

and line 2499 is:
              | VariableDeclaration.Const -> expression ~is_const:true cx expr

Here is the full patch I'm trying to apply:
diff --git a/newtests/gen_flow_files_command/test.js b/newtests/gen_flow_files_command/test.js
index da5be6130..b373edfee 100644
--- a/newtests/gen_flow_files_command/test.js
+++ b/newtests/gen_flow_files_command/test.js
@@ -146,7 +146,7 @@ export default suite(({addFile, addFiles, flowCmd}) => [
           // @flow

           declare export default number;
-          declare export var str: string;
+          declare export var str: "asdf";

         `,
diff --git a/src/typing/statement.ml b/src/typing/statement.ml
index e210a296a..8f3582ce3 100644
--- a/src/typing/statement.ml
+++ b/src/typing/statement.ml
@@ -2494,7 +2494,11 @@ and variable cx kind ?if_uninitialized (_, vdecl) = Ast.Statement.(
         Type_inference_hooks_js.(dispatch_lval_hook cx name loc (Val t));
         (match init with
           | Some ((rhs_loc, _) as expr) ->
-            let rhs = expression cx expr in
+            let rhs =
+              match kind with
+              | VariableDeclaration.Const -> expression ~is_const:true cx expr
+              | _ -> expression cx expr
+            in
             (**
              * Const and let variables are not declared during evaluation of
              * their initializer expressions.
@@ -2596,8 +2600,8 @@ and mixin_element_spread cx (loc, e) =
     Flow.flow_t cx (arr, DefT (reason, ArrT (ArrayAT(tvar, None))));
   )

-and expression ?(is_cond=false) cx (loc, e) : Type.t * unit Ast.Expression.t' =
-  let t, e' = expression_ ~is_cond cx loc e in
+and expression ?(is_cond=false) ?(is_const=false) cx (loc, e) : Type.t * unit Ast.Expression.t' =
+  let t, e' = expression_ ~is_cond ~is_const cx loc e in
   Env.add_type_table cx loc t;
   t, e'

@@ -2610,11 +2614,11 @@ and this_ cx loc = Ast.Expression.(
 and super_ cx loc =
   Env.var_ref cx (internal_name "super") loc

-and expression_ ~is_cond cx loc e : Type.t * unit Ast.Expression.t' =
+and expression_ ~is_cond ~is_const cx loc e : Type.t * unit Ast.Expression.t' =
   let ex = (loc, e) in Ast.Expression.(match e with

   | Ast.Expression.Literal lit ->
-      literal cx loc lit, Ast.Expression.Literal lit
+      literal ~is_const cx loc lit, Ast.Expression.Literal lit

   (* Treat the identifier `undefined` as an annotation for error reporting
    * purposes. Like we do with other literals. Otherwise we end up pointing to
@@ -3935,7 +3939,7 @@ and identifier cx name loc =
   t

 (* traverse a literal expression, return result type *)
-and literal cx loc lit = Ast.Literal.(match lit.Ast.Literal.value with
+and literal ?(is_const=false) cx loc lit = Ast.Literal.(match lit.Ast.Literal.value with
   | String s ->
       (* It's too expensive to track literal information for large strings.*)
       let max_literal_length = Context.max_literal_length cx in
@@ -3944,7 +3948,9 @@ and literal cx loc lit = Ast.Literal.(match lit.Ast.Literal.value with
         then Literal (None, s)
         else AnyLiteral
       in
-      DefT (annot_reason (mk_reason RString loc), StrT lit)
+      if is_const
+      then DefT (annot_reason (mk_reason RString loc), SingletonStrT s)
+      else DefT (annot_reason (mk_reason RString loc), StrT lit)

   | Boolean b ->
       DefT (annot_reason (mk_reason RBoolean loc), BoolT (Some b))

Welp sorry, got busy with other projects. IIRC this was breaking some stuff with object literals (object literal strings were thought to be constant? So {a: 'foo'} was the inferred type for const a = {a: 'foo'}?). I might be wrong sorry, it was a while ago 😅

@mrkev any info about this PR?

Have there been any updates? I remember this broke the tests. 😅

Just two years and ten months so far, too early to fix tests 😈

I mean if author still wants to pursue this PR, Flow team is more willing to accept PRs lately, than 2 years ago

Sorry, folks, but I'm not interested in working on this anymore. I've switched to TypeScript since then. My contribution experience there was much better.
Feel free to re-use the code for another PR.

Thank you! I re-opened this PR https://github.com/facebook/flow/pull/7607

Closing this one in that case 👍


fix: Fix library crashing on android 5.x

This PR fixes #33 by migrating from deprecated MasterKeys class. Also, this PR adds android unit test to check library on different android devices (I checked on android 5 VM and it works). As well, this PR bumps androidx.security:security-crypto which has possibility to fix #31

Hi! Thank you for this, I wasn't even aware of the deprecation you mentioned. I will review this late today, happy holidays!


Rebase branch and force-push for cleaner code

The commit history should be clean, contain good commit messages as requested here, and not refer to any issues in this (forked) repo. The reason for the last part is that if "#18" is used in a commit message to refer to THIS issue, then it will refer to issue/pull 18 of the original JabRef repo when it appears in the UI of the original JabRef repo.

I suggest we accomplish this by rebasing the fix-issue-7452 branch interactively onto the JabRef master branch, together, providing good commit messages, and then force-pushing it to hide the old history.


Add tags to categorize the module

We should try the tag functionality we've added in ceylondoc for that very purpose. It allows us to filter the doc based on categories, such as basic types, numbers, streams, functions.
To kick-start the discussion and illustrate what this does, I'll add a commit so you can run and doc and check the results in the generated API docs in Filters (top-right menu). If you guys agree, feel free to suggest categories and members (or just do it). If you disagree we can always revert my commit. But PLEASE try it out, it's pretty neat.

When I click on "Basic types" I get taken to the search page with "Basic%20types" in the input and no results.
Also, I want a tag cloud.

Also, I want a tag cloud.

It doesn't lamely have to use a bigger font for more popular tags though.

Oh, and finally, it might be useful to issue a warning about tags with only one member (that will tend to catch typos, for instance), and a tag with only one thing is a bit pointless.
Apart from these things it seems vaguely useful.

What? I don't get to the search page by clicking Basic types, that's really weird.

Are tags on modules supported? The ceylon.html module descriptor is tagged – the only use of tagged in language module and SDK I could find yesterday – but I don’t see the tags anywhere on the Herd.

Oh, when you click on the tag, not the menu. Yes that's a bug.

Are tags on modules supported?

If not, they should be.

Oh, when you click on the tag, not the menu

The menu?... Ah the filter thing you mean? I didn't even spot that, it's not obvious at all. Should it have an "untagged" option?

check the results in the generated API docs in Filters (top-right menu)

:(
That's the only place where this feature shines. It's extremely nice IMO.

Should it have an "untagged" option?

Good question. I am not sure it'd be very useful.

So what other tags do we need for the language module?

Sorting? (for stuff to do with comparing and comparators)
Operator? (for methods used to define operators)

Any others?
Also I can't help but feel we'll one day want a refactoring to change a tag, but that's another issue I guess.

Sorting, Operator

Both good ideas IMO.
@gavinking any opinion?

The major categories are: numbers, streams, collections, sequences, strings, functions, environment.

Not operators?

And metamodel and serialisation I guess.

Um. Not really...

Yes, meta and serialization of course.

Added tags everywhere, and added the Comparisons tag to the list, since we had lots of stuff for that.
Remaining untagged things:

default, abstract annotations and the rest, I suggest a Language annotations tag or something
doc, deprecated annotations and the rest, I suggest a Documentation tag,
Range, Measure and stuff that I just don't know how to categorise,
Annotated, Annotation, ConstrainedAnnotation and stuff, perhaps Annotations tag?
Binary (no idea, seems alone),
Enumerable again no idea,
Contextual no idea,
identityHash no idea

Any idea/comment?

Well, if nobody has comments, let's just close this as good enough until someone becomes interested again.


[AUDIT0004] Fix issues in the DAO found during audit

Description
During the Audit by Inference, two main issues have been found
Snapshot block
Snaptshot block is not managed correctly.
Snapshot block shall only by taken in the main DAO contract.
Problems:

the snapshot block is delayed and taken only when the vote is allowed after the delay and not right when the proposal is injected. This allow a user to buy/mint a lot just after the proposal.
the snapshot block is retaken when we enter the opt out phase 2

Dynamic quorum
The dynamic quorum update shall be a percentage.
For instance, if the quoum is 4000 votes of 10000 possible votes (40%).
If 4000 exactly votes, then the dynamic quorum remains the same.
If during the next vote, we have 20000 possible vote, then the quorum shall 8000 (and not 4000).

Work to do

Rework the snapshot block
Rework thge dynamic quorum computation
Improve testing
Improve specifications


Require confirmation if a blacklist pattern is already caught

This came up yesterday, when someone tried to blacklist a keyword that was in the old bad_keywords_nwb.  I added a check, similar to !!/test, before each blacklisting operation so that confirmation is required if blacklisting a keyword that is already caught.
Since the pattern to blacklist is a regex and not just a keyword or URL, this is not perfect, since the blacklist pattern is run through the filters and not necessarily what the pattern was intended to catch.  I replace \W with a space and \. with a period, so it should work for most blacklist/watchlist operations.

Hmm; I'm unsure what to do about the codeclimate review.  The "Too many parameters" ones seem mostly unavoidable, and the "Similar code" ones are incorrect (it's complaining about the docstrings), leaving only "Method too long."

Codecov Report

Merging #867 into master will increase coverage by 0.01%.
The diff coverage is 17.94%.

@@            Coverage Diff             @@
##           master     #867      +/-   ##
==========================================
+ Coverage   63.56%   63.57%   +0.01%
==========================================
  Files           6        6
  Lines        1762     1771       +9
==========================================
+ Hits         1120     1126       +6
- Misses        642      645       +3

Impacted Files
Coverage Δ

chatcommands.py
48.67% <17.94%> (+0.25%)
:arrow_up:

Continue to review full report at Codecov.

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

"Too many parameters" can be solved either by splitting a method into multiple (which also solves "method too long"), or by using **kwargs.

Thanks!

Apparently I can also make the CC status check pass manually, so... that's a thing

Alright; would you still like me to make those changes?  I probably would have used **kwargs had I known about it then; that's pretty cool!

Yeah, go ahead on **kwargs. I won't make you pass the codecov/patch check, though ;)

Alright; thanks!  check_blacklist would be be pretty trivial to test; I can add a quick test if you like.
From Jonathan

On Jun 21, 2017, at 2:07 PM, ArtOfCode<EMAIL_ADDRESS>wrote:
Yeah, go ahead on **kwargs. I won't make you pass the codecov/patch check, though ;)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

!!/approve


Bump to 1.2.2, rerender with conda-smithy 2.4.4

This updates to deap 1.2.2, runs the test suite with nose, includes the license file, and all manner of other good things. Thanks @TiemenSch for pointing out availability on #4!
I think it's still okay to not set numpy x.x, as it doesn't look like the compiled bits include any numpy headers, hooray!

Hi! This is the friendly automated conda-forge-linting service.
I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.
Here's what I've got...
For recipe:

The about section contained an unexpected subsection name. docs_url is not a valid subsection name.

Builds are looking good! Once they finish, I'll fix the lint and (hopefully) merge later today! 🤞

Great! Thanks so much for picking this up so quickly 👍

Builds 💚 ! @TiemenSch, would you be interested in joining our merry band of maintainers?

Well fixing the lint so that we get back in the queue. Make a PR with your own name in maintainers if you are so inclined!

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

Take that lint!

What would you expect from me if I were to become a maintainer (:?

@TiemenSch the conda-forge team has tried to make maintainership as easy as possible!
Of perhaps most interest: when a new version lands on PyPi , you would create a PR (even in the web UI!) that updated:

the new version
the new sha256  from pypi.io

Of course you could already do this as a non-maintainer! However, if all of the CIs pass, a maintainer can hit Merge and new versions would be available for everyone after the merge to master completes.
Because you'd only be signing up for deap (and not all of them), the amount of noise in your Github inbox would be minimal. On a less-than-monthly basis, you might help (i.e. press Merge!) when an automated PR comes along, usually minor changes to CI that, if they work, won't require anything more than a cursory inspection of the build logs.
Maintainers that actually make use of the package of interest are very valuable, as they are most likely to a) want the newest, shiniest features and b) know when Something Is Wrong.
Of course, the Secret Master Plan is starting with a little maintaining, you'd be driven to want to

learn more about conda, conda-build and conda-forge
submit, improve, or maintain other feedstocks
generally make conda-forge a more lovely way to get work done.

Anyhow, we waited 2.5 years between 1.0.2 and 1.2.x, so it's not like maintaining this package has been a crushing burden, but we're always looking for new, excited people!
Cheers!


Pin shellcheck ubuntu to 20.04

@tsibley correctly identified that the recent shellcheck failures was due to us using ubuntu-latest which caused an implicit upgrade to 22.04 which caused a failure.
Pinning to 20.04 seems to fix it.

Wish I knew why… but I'm trying hard to avoid digging into that now.


Bug: 无法发送消息

按文档配置了插件，群聊中已订阅仓库。github webhook 发送请求后能接收到 response，但不会往群聊中发送消息。能正常使用插件新建 issue。

没有报错吗？

没有

相同的问题。我开了debug模式看了一下日志。原因可能在数据库里

数据库对应表内容

id是对不上的
我在源码里没找到具体是调用的哪一段代码

![image](https://github.com/koishijs/koishi-plugin-github/assets/17946284/a45012aa-72f8-462d-b499-65c5c9964c9d)

但从黑盒的角度看，需要做的事情是

比较secret
从数据库找出订阅了这个仓库的频道
看起来是哪里出问题了


Reschedule meeting time

Should the 8:00am PT every other Monday time slot be moved to increase participation to the meeting?

That'd be nice. I'd like to attend again and can't at its current time.

I'm open to changing if it helps more folks attend.


Public Release Tasks

These are several items that should be completed for the public release of the module. Any contributions are more than welcome.
Tasks for the public announcement: https://github.com/nuxt/scripts/issues/47
Nuxt

[x] Add stub for useScript to Nuxt core (https://github.com/nuxt/nuxt/pull/26854 & https://github.com/nuxt/nuxt/pull/27010#issue-comment-box)

Benchamarks

[x] See what the overhead of using registry script is - 2.09kb gzipped for fathom analytics
[x] Test web vitals & PSI with / without useScript - not meaningful by itself, too much variability

Documentation
Content
(some content exists on all these pages it just needs polishing)
Getting started

[x] Introduction
[x] Installation
[x] Tutorial: js-confetti
[x] Reproductions - add a stackblitz demo repo

Guides

[x] Script Loading
[x] Script Triggers
[x] Bundling
[x] Consent
[x] Page Events
[x] Global Scripts

API

[x] useScript
[x] createConsentScriptTrigger
[x] useElementScriptTrigger
[x] useAnalyticsPageEvent
[x] Nuxt Config
[x] Nuxt App Hooks
[x] Nuxt Hooks

Registry
(see below)
Read Me

[x] Better background details, more concise and informative.

Home Page

[x] Benchmarks

Nuxt Scripts
Tests

[ ] Consuming module

[ ] Playground installing module externally working

[ ] Generate
[ ] Build

[x] StackBlitz working

[x] e2e Trigger tests

[x] onNuxtReady
[x] manual
[x] visibility
[x] mouseover

Registry Scripts
The initial implementation for all of these scripts is complete. No new scripts should be added at this stage.
The below require proper documentation and sanity checks on implementation. There is some tree-shaking improvements to be made, see Cloudflare Web Analytics example as it's complete.
We also need to properly document which scripts can be bundled.
Analytics

[x] cloudflare-web-analytics
[x] fathom-analytics
[x] google-analytics
[x] matomo-analytics
[x] plausible-analytics

Content

[x] google-maps
[x] vimeo-player
[x] youtube-player

Marketing

[x] intercom
[x] hotjar

Payments

[x] lemon-squeezy
[x] stripe

Tracking

[x] meta-pixel
[x] google-tag-manager
[x] segment
[x] x-pixel

Util

[x] npm
[x] :question: Drop the confetti script and replace it with just a usage example of npm

From my own observation, it makes sense to add e2e tests for Registry Scripts to the list.
Especially when it comes to analytics, they like to "go crazy". I tried to run Google Analytics and use events but it didn't work at all, hence my suggestion to add tests to the registry as well.
Maybe I was doing something wrong in general (I was using the documentation). Anyway, this is a suggestion and if I still have a problem with it after updating the packages, I will make an issue and reproduce it.

Thank you for the feedback @oritwoen. Unfortunately to do an e2e test with the registry scripts is not fully possible for all scripts, we can support it for registry scripts that expose an API to check the data we send it.
If you can provide the code you had an issue with or a reproduction it would help.


Ignore the open parentheses when measuring BestFitsParenthesize

Summary
This PR changes the definition of BestFitParenthesize to only consider whether its content fits when parenthesizing and not whether the whole parenthesized expression fits.
The difference is subtle but relevant when what comes before BestFitParenthesize already exceeds the configured line width:
this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = aaaaaa

The this_is_a... exceeds the configured line width. The existing implementation doesn't parenthesize aaaaa because the opening ( doesn't fit on the line. This is unfortunate, because parenthesizing would make aaaaa fit in the configured line width and is what Black does:
this_is_a_ridiculously_long_name_and_nobody_in_their_right_mind_would_use_one_like_it = (
    aaaaaa
)

This PR implements Black's behavior by ignoring whether there's sufficient space to place the ( and instead only measures whether its content (aaaaaa) fits when indenting.

Test Plan

Current dependencies on/for this PR:

main

PR #8940   👈

This stack of pull requests is managed by Graphite.


HDFS-14148. HDFS OIV ReverseXML SnapshotSection parser throws exception when there are more than one snapshottable directory

Fork the PR 1274

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Comment

0
reexec
914
Docker mode activated.

_ Prechecks _

+1
dupname
0
No case conflicting files found.

+1
@author
0
The patch does not contain any @author tags.

+1
test4tests
0
The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1
mvninstall
1060
trunk passed

+1
compile
56
trunk passed

+1
checkstyle
44
trunk passed

+1
mvnsite
64
trunk passed

+1
shadedclient
746
branch has no errors when building and testing our client artifacts.

+1
javadoc
54
trunk passed

0
spotbugs
160
Used deprecated FindBugs config; considering switching to SpotBugs.

+1
findbugs
158
trunk passed

_ Patch Compile Tests _

+1
mvninstall
60
the patch passed

+1
compile
53
the patch passed

+1
javac
53
the patch passed

+1
checkstyle
38
the patch passed

+1
mvnsite
58
the patch passed

+1
whitespace
0
The patch has no whitespace issues.

+1
shadedclient
721
patch has no errors when building and testing our client artifacts.

+1
javadoc
45
the patch passed

+1
findbugs
164
the patch passed

_ Other Tests _

-1
unit
6497
hadoop-hdfs in the patch failed.

+1
asflicense
41
The patch does not generate ASF License warnings.

10832

Reason
Tests

Failed junit tests
hadoop.hdfs.server.balancer.TestBalancer

hadoop.hdfs.server.namenode.TestNamenodeCapacityReport

hadoop.hdfs.TestDFSStripedInputStream

hadoop.hdfs.server.datanode.TestLargeBlockReport

hadoop.hdfs.server.namenode.TestTransferFsImage

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/hadoop-multibranch/job/PR-1276/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/1276

Optional Tests
dupname asflicense compile javac javadoc mvninstall mvnsite unit shadedclient findbugs checkstyle

uname
Linux 7d774ac61bde 4.4.0-138-generic #164-Ubuntu SMP Tue Oct 2 17:16:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
personality/hadoop.sh

git revision
trunk / d29007f

Default Java
1.8.0_222

unit
https://builds.apache.org/job/hadoop-multibranch/job/PR-1276/1/artifact/out/patch-unit-hadoop-hdfs-project_hadoop-hdfs.txt

Test Results
https://builds.apache.org/job/hadoop-multibranch/job/PR-1276/1/testReport/

Max. process+thread count
4296 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs U: hadoop-hdfs-project/hadoop-hdfs

Console output
https://builds.apache.org/job/hadoop-multibranch/job/PR-1276/1/console

versions
git=2.7.4 maven=3.3.9 findbugs=3.1.0-RC1

Powered by
Apache Yetus 0.10.0 http://yetus.apache.org

This message was automatically generated.

Test failure looks unrelated. I'll close this one and merge #1274


Travis build failing due to unsupported nodejs version

Upgrade travisyml to support nodejs version 12

Merged fix for this in #10


Migrate from using IID SDK for Remote Config to the new FIS SDK

WIP.

Both merge conflicts and tests should are expected to be fixed by #5109.


wrong authorityCertIssuer used in org.bouncycastle.cert.X509ExtensionUtils.createAuthorityKeyIdentifier(X509CertificateHolder certHolder)

According to the javadoc comment of  "public AuthorityKeyIdentifier createAuthorityKeyIdentifier(
X509CertificateHolder certHolder)" the returned AuthorityKeyIdentifier should refer to the certificate given in  certHolder. But the AuthorityKeyIdentifier is generated out of the ISSUER of the ISSUER certificate given as parameter.
Proposed solution:
Replace
"GeneralName   genName = new GeneralName(certHolder.getIssuer());" with
"GeneralName   genName = new GeneralName(certHolder.getSubject());"

No the code is correct - a certificate's serial number is related to the issuer of the certificate in question, not the subject.


Precompile

faster asset precompiling on deploy - tmp/cache isn't getting flushed

So the main thing here was switching to a different version of angular-rails4-templates? Or changing the order in which we include all our angular deps?

There were two separate issues: assets taking a long time to precompile and not being able to deploy to hechtia. I was mainly focused on the former. Turns out angular-rails-templates clears the tmp files, which are needed for fast asset precompiling. Moving from that to angular-rails4 seemed to fix that.
Unrelated, I split the bundles so we don't have to recompile the bower stuff any time we change our app logic. The benefit of that remains to be seen.
For the deploy to hechtia, the main bug was different, and fixed in 35c733b . That server was configured to load Spanish by default, which created an i18n key that did not exist. It expected the English key. After that was fixed, I needed to remove multiple public/assets/manifest-.yml files to get assets to precompile again. Right now I am able deploy, and asset precompiling is down from 220 seconds to 20 seconds or less.

Oh jeez, the hechtia issue was mine. Forgot that would be precompiled in different languages. Apologies. Will try to be on the lookout for that in the future.


hastec: panic! (the 'impossible' happened)

hastec: hastec: panic! (the 'impossible' happened)
||   (GHC version 7.10.3 for x86_64-unknown-linux):
|| 	ModOrigin: hidden module redefined
||
|| Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug
code:
ModuleX.hs:
{-# LANGUAGE OverloadedStrings #-}

module ModuleX where

import Haste.Foreign
import Haste.DOM (Elem)

jsOp :: IO Elem
jsOp = ffi "..."

Main.hs:
import ModuleX

main :: IO ()
main = do
  x <- jsOp
  let y = zip x x -- also other operations violating the type [a] ~ Elem
  return ()

files.tar.gz

I'm unable to reproduce this on my end, I get a type error as expected. Which version of Haste are you using, and did you install from Hackage or using the binaries from haste-lang.org? Is the issue still present in the latest git head?

It is the binary from haste-lang.org, which I took because of #380.


Using EEPROM with a fixed address may cause excessive wear

Using EEPROM with a fixed address may cause excessive wear on the flash and increases the risk of premature failure.
To reduce the wear on the flash through repeated erase and write cycles, I'd recommend using Espressif's nvs library. It is ideal for storing small pieces of frequently changing information, using an efficient append only strategy that avoids the need to erase the flash sector before writing. This is what the stock firmware uses to store the frame count.
One caveat, I do not believe the Arduino framework for the 8266 includes nvs. It is available for RTOS builds and may be possible to port to Arduino with shim for RTOS partition methods.

Maybe https://github.com/jwrw/ESP_EEPROM would be a good and easy option.


Map stuck until all tiles loaded

All map interaction is stuck as long as tiles are loading. I'm using the current version loading from http://leafletjs.com/dist/leaflet.js.
This bug is particularly prominent on Chrome 44.0.2403.155 (64-bit) / Mac OS X but I can also see some of this behavior on Firefox 39.0.3 / Mac OS X.
I can confirm the same behavior with Mapbox.js v2.2.1.
Here you can see how panning is stuck until all tiles load. Also zooming is stuck in such a situation.

Duplicate of #3685

:+1:


Duplicate DataTypeTemplates when importing an ICD file, if a previous ICD import was renamed

The current import template feature seems to import duplicate DataTypeTemplates if the IED of a previous ICD import is renamed.
Steps to reproduce:

Start with new project
Import the following ICD files, 1 IED per ICD.

Siprotec_6MU85_Transformer_Line.zip
Siprotec_7UT85_Supply_Yd.zip

Renamed the 7UT85 to XAT_T1_P2
Import the 7UT85 ICD file again and create one IED
Validation fails

The resulting SCD file with the duplicates:
2023-11-13_ICD_import_duplicate_datatypetemplates.zip
The present workaround is to open the SCD file up in a text editor and manually replace the SIEMENS_7UT85_01 with the new IED name XAT_T1_P2. However, this proliferates duplicate DataTypeTemplates but with different ids.

Good catch! I need to do some work as to why this is because I find it unexpected and confusing.

This has been fixed upstream and a new release has been published and incorporated into our distribution.
Please test!


New package: HiroshibaKazuyuki.VOICEVOX version 0.14.10

Pull request has been created with Komac v1.11.0 :rocket:
Microsoft Reviewers: Open in CodeFlow

For moderators
This account is bot account and belongs to CoolPlayLin. Any issue should call him up instead of assigning to this account. He has the write permission of this account's fork so that he can resolve the issue directly.

[!important]
Please recheck these Pull Request carefully before merging. If it is a incorrect-removing Pull Request and the URLs don't have any issue while manual checking, please close this Pull Request directly(It's best to let CoolPlayLin know).

Have a good day!

For moderators
This account is automated by Github Actions and the source code was created by CoolPlayLin. If you have any questions about any pull request, don't hesitate to ping @Exorcism0666, I'll get a notification. It has the write permission of this account's fork so that it can resolve the issue directly.

[!important]
Please recheck these Pull Request carefully before merging. If it is a incorrect-removing Pull Request and the URLs don't have any issue while manual checking, please close this Pull Request directly(It's best to let Exorcism0666 know).

良い一日をお過ごしください！

Manifest Error: Duplicate installer entry found.

Hi @Exorcism0666,
From the URLs, these appear to be CPU, CUDA, and Web versions respectively. But they're all given the same identifier of just Architecture: x86, so the package manager can't tell them apart.

@stephengillie i think so!

@stephengillie what should I do now, maintain this pull request, or close it to create a new one?


plexamp: 4.4.0 -> 4.5.1

Motivation for this change
Upgrades plexamp from 4.4.0 to 4.5.1
This PR was automatically generated by nixpkgs-upkeep.

CI workflow that created this PR.
Internal tag: f8bf857d156d1c6c0f7fa2fcbc39fc4f.

Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[x] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

superseded by https://github.com/NixOS/nixpkgs/pull/204712


Using helm install --upgrade --dry-run foo . wil not result in an error when port name is too long

I use helm install --dry-run to let the server render my template.
When I do it everything is fine and I get the resulting YAML.
When I remove the --dry-run I am unable to install the chart because a value (in this case the port number for a service) is exceeding the maximum char length (15).
My expectation was, that I get the same error when I let the server render the template, this being the advantage of --dry-run vs template.
Full error:
Error: UPGRADE FAILED: failed to create resource: Deployment.apps "foo" is invalid: spec.template.spec.containers[0].ports[0].name: Invalid value: "12345678901234-port": must be no more than 15 characters
Output of helm version:
version.BuildInfo{Version:"v3.10.2", GitCommit:"50f003e5ee8704ec937a756c646870227d7c8b58", GitTreeState:"clean", GoVersion:"go1.18.8"}
Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"windows/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.3", GitCommit:"434bfd82814af038ad94d62ebe59b133fcb50506", GitTreeState:"clean", BuildDate:"2022-10-12T10:49:09Z", GoVersion:"go1.19.2", Compiler:"gc", Platform:"linux/amd64"}
Cloud Provider/Platform (AKS, GKE, Minikube etc.): Minikube

But one thing. The docs for Debugging Templates it says

helm install --dry-run --debug: We've seen this trick already. It's a great way to have the server render your templates, then return the resulting manifest file.

Isn't this documentation misleading, when --dry-run does not contact the server?

Is is indeed. Would you mind filing a docs issue in helm-www

I'm going to go ahead and close this as a duplicate of #8137

Issue is opened. Thank you for the feedback :)