Fix tesla

Description

fix tesla.svg
Fixes #(issue)

top t line
Type of change

:x: Bug fix (non-breaking change which fixes an issue)
:x: General change (non-breaking change that doesn't fit the above categories, such as copyediting)

https://github.com/LawnchairLauncher/lawnicons/pull/1517/files#diff-4146ba9fd23928866f9190c9c1d43bcc09b7d1a2fe33e5399dbfb0df626c7a71
Tesla icon has been intentionally simplified so that its quality does not spoil on the phone screen due to too small distances between the lines at the top.
Icons with small distances between the lines look worse on the phone screen, because there they can be ~4 times smaller than here. I have redesigned hundreds of old icons to improve the overall quality of Lawnicons, although we still have quite a few icons added before May 2023, which are made without taking into account that they will be smaller on the phone screen. Sometimes deterioration in quality cannot be avoided, for example, when an icon cannot be significantly simplified without loss of recognition. But this is not the case of the Tesla icon.
In short, if you disagree, then maybe some other reviewer will accept your option.


test-pyproject-toml

It seems the toml file is not recognized as the setup.py was, since the CI is failing at the install phase.
Does that mean we have to adapt the CI configuration?
Do we need to update our installation instructions in the README?

It seems the toml file is not recognized as the setup.py was, since the CI is failing at the install phase.
Does that mean we have to adapt the CI configuration? Do we need to update our installation instructions in the README?

It seems the toml file is not recognized as the setup.py was, since the CI is failing at the install phase.
Does that mean we have to adapt the CI configuration? Do we need to update our installation instructions in the README?

I am trying to update ci configuration as below:
'''
jobs:
test:
runs-on: ubuntu-latest
strategy:
matrix:
python-version: ["3.8", "3.10", "3.12"]
env:
COUCHDB_ADMIN_PASSWORD: "yo0Quai3"
AAS_SPECS_RELEASE_TAG: "V3.0.7"
services:
couchdb:
image: couchdb:3
ports:
- 5984:5984
env:
COUCHDB_USER: "admin"
COUCHDB_PASSWORD: ${{ env.COUCHDB_ADMIN_PASSWORD }}
steps:
- uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
  uses: actions/setup-python@v2
  with:
    python-version: ${{ matrix.python-version }}
- name: Install Poetry
  run: |
    pip install poetry
- name: Install dependencies with Poetry
  run: |
    poetry install
- name: Collect schema files from aas-specs
  run: |
    mkdir -p ./test/adapter/schema
    curl -sSL -o ./test/adapter/schema/aasJSONSchema.json https://raw.githubusercontent.com/admin-shell-io/aas-specs/${{ env.AAS_SPECS_RELEASE_TAG }}/schemas/json/aas.json
    curl -sSL -o ./test/adapter/schema/aasXMLSchema.xsd https://raw.githubusercontent.com/admin-shell-io/aas-specs/${{ env.AAS_SPECS_RELEASE_TAG }}/schemas/xml/AAS.xsd
- name: Setup test config and CouchDB database server
  run: |
    python test/_helper/setup_testdb.py -u "admin" -p "$COUCHDB_ADMIN_PASSWORD"
- name: Test with coverage + unittest
  run: |
    poetry run coverage run --source=basyx -m unittest
- name: Report test coverage
  if: ${{ always() }}
  run: |
    poetry run coverage report -m

'''

And then furthermore, this PR should probably point at eclipse-basyx/basyx-python-sdk/main, rather than our fork's main

the PR is already targeting the main branch of the current repository, could you elaborate more about this review: '''And then furthermore, this PR should probably point at eclipse-basyx/basyx-python-sdk/main, rather than our fork's main'''

https://github.com/rwth-iat/basyx-python-sdk/pull/51


Failed errorInternal Server Error

trying to deploy this repo:
https://githubsfdeploy.herokuapp.com/app/githubdeploy/mshanemc/ng-kitbag'
Get
Failed errorInternal Server Error as a popup.

Its because you don't have a package.xml, so the tool falls back to trying to create a package.xml on the fly, trouble is this mode depends on your repo being a certain shape, which i don't recall the details on right now. I would personally recommend you add a package.xml, the mode to auto generate it tbh makes a few assumptions which might not work for all MD types and i'm not sure really can be full retained in the future anyway.

Great, thanks.   I'll put the package.xml on all repos.
Just FYI, your previous button code had been working without package.xml, so there may be other people whose package buttons broke with the change.

Ah ok, thanks for that, a regression is for sure a bug, i'll keep this open!


Adding github owner to the github provider setup details

Fixes: https://github.com/pulumi/docs/issues/5359
Please note, the difference from that original issue is that
GITHUB_ORGANIZATION has been deprecated in favour of GITHUB_OWNER as
per https://github.com/pulumi/pulumi-github/#configuration

@stack72 I re-arranged some of the text a bit to denote that the GitHub owner configuration setting is optional. LMK if the changes match what you wanted to convey.

Love it! This is way more clear


Fix buildkit export-cache with Trow.

We're using Buildkit for building images and pushing them to Trow.
We tried adding the --export-cache argument to Buildkit (e.g. --export-cache type=registry,mode=max,ref=some/image:cache,compression=zstd) but this fails with a 400 in Trow.
It seems to be due to the fact that there's no platform field, afaiu. The error is:
ERROR Error verifying manifest Error("missing field `platform`")

Making this field optional makes the --export-cache argument work for us.
I have no idea about the bigger implications of this - but thought this might be okay (everything seems to continue working for us) :-)

Oh interesting. Sounds ok on the face of it.


Fix github codespaces tokens always erroring

Resolves (hopefully): https://github.com/rojo-rbx/rokit/issues/53#issue-2416947502

It seems like in the time between this PR opening and me seeing it there has been another PR made that is slightly more flexible (#60) and I think we should go with that one instead. Nonetheless, thank you for investigating this and for providing a fix!


Fix many files bug

I made the test fail by making the file name really long.
Made the file name repeat the number multiple times so a radix tree does not optimize the long name away, just in case we do radix trees in the future.

Fixes https://github.com/n0-computer/iroh/issues/915


Add helper methods for signing typed data

Not natively supported by web3dart, so adding our own wrappers will make dev's lives much easier.

Fixed by #23


Kind of datasets the approach would work

I was wondering about the application domain and dataset type of the approach. Suppose that our scenes are heavily containing metal objects (3d models and 2d images are known to us, of course) which may be a bit shiny or similar to each other (after all, all would have metalic texture).
In such cases, would the approach actually perform within the acceptable limits?

I haven't tested the approach on such datasets, but in my opinion our part-based pose parametrization should be robust against such conditions that include specular and shiny surfaces. The following paper (https://infoscience.epfl.ch/record/212781/files/1688.pdf?version=1) which has a similar pose parametrization particularly investigates the performance of their pose estimation approach in industrial environments with metallic objects and concludes that their method is suitable for practical augmented reality applications in industrial contexts.


add support for transparency in color specification

From<EMAIL_ADDRESS>on December 06, 2012 11:50:41

Amend pattern in data.COLOR to

<rng:data type="token">
<rng:param name="pattern"
>(#([0-9A-Fa-f]{2,2})?[0-9A-Fa-f]{6,6}|aqua|black|blue|fuchsia|gray|green|lime|maroon|navy|olive|purple|red|silver|teal|white|yellow)</rng:param>
</rng:data>
This makes the leading hexadecimal duple (the one that specifies transparency) optional.

Revise description
<desc>Either a hexadecimal color value, i.e.., #[0-9A-Fa-f]{6,6} OR a descriptive word, i.e., aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, or yellow, for colors defined by the HTML 4.01 specification. A hexadecimal value may be preceded by an additional hexadecimal value that specifies the amount of transparency. A value of '00' in this leading value indicates the color is totally transparent, while 'FF' defines it as totally opaque. When the leading duple is not supplied, a value of 'FF' is assumed.

Original issue: http://code.google.com/p/music-encoding/issues/detail?id=138

From<EMAIL_ADDRESS>on December 06, 2012 11:34:40
I wouldn't do this by prepending two hex digits, as this is not valid CSS, while the other specs follow CSS. Instead, CSS uses a completely different scheme for it, which I suggest to follow.
"rgba(255,0,0,0.5)" would be a semi-transparent red. The "a" in rgba ranges from 0.0 (transparent)to 1.0 (opaque), but allows any number of digits after the dot. All other values range from 0 to 255 and are thus easy to translate to the regular hex values. CSS also offers other color schemes ("rba()", "hsl()", "hsla()"), which we could implement as well or delay until there is an explicit need.
By the way, couldn't we use a more sophisticated way of expressing this, perhaps by using a mixture of choices, lists and regex' instead of just one long regex?

From<EMAIL_ADDRESS>on December 06, 2012 12:44:07
"More sophisticated methods of expression" are usually more verbose, sometimes more prone to misinterpretation, and sometimes less efficient.   Using the current regular expression, you may not get the color you want, but a value can never be outside the range of possibilities -- if it matches the expression, it's a legitimate color.
It seems to me the CSS rbga syntax, with its mixture of text and numbers will be difficult to fully implement; that is, a regular expression can help with the syntax, but can't be used to check that the values are between 0 and 255. I don't know if a combination of regular expressions and other patterns are possible.
But this is just my first impression.  I'm willing to give it a try.

From<EMAIL_ADDRESS>on December 06, 2012 15:02:28
I can't find a way to easily and simply control both the lexical space and the value space of the rgba syntax -- rng:data can neither contain other rng:data elements nor be grouped using rng:group to form a complex pattern.  ODD doesn't complain, but the resulting RNG schema isn't valid.
So, it looks like regex is our only choice.  The 2nd data option below isn't pretty or immediately obvious, but I believe it gets us what we need -- "rgba(", followed by 3 comma-separated values between 0 and 255, followed by an optional comma and decimal transparency value between 0 and 1, followed by ")".
<content>
<rng:choice>
<!-- hex values -->
<rng:data type="token">
<rng:param name="pattern"
>(#[0-9A-Fa-f]{6,6}|aqua|black|blue|fuchsia|gray|green|lime|maroon|navy|olive|purple|red|silver|teal|white|yellow)</rng:param>
</rng:data>
<!-- rgba values -->
<rng:data type="token">
<rng:param name="pattern"
>rgba(((0|1([0-9]{1,2})?|2-9?|2([0-5]{2})?)\s*,\s*){2}(0|1([0-9]{1,2})?|2-9?|2([0-5]{2})?)(\s*,\s*(0(.[0-9]+)?|1(.[0]+)?))?)</rng:param>
</rng:data>
</rng:choice>
</content>

From<EMAIL_ADDRESS>on December 06, 2012 15:13:16
Of course, the documentation of data.COLOR has to be changed as well --
<desc>Either a hexadecimal color value, i.e., #[0-9A-Fa-f]{6,6}, a descriptive word defined by the HTML 4.01 specification, i.e., aqua, black, blue, fuchsia, gray, green, lime, maroon, navy, olive, purple, red, silver, teal, white, or yellow, or an RGBA value in the form "rgba(r,g,b[,a])" where "r", "g", and "b" are integer values between 0 and 255 and the optional "a" is a decimal value between 0 and 1. Any number of decimal digits is allowed in "a" following a "0"; however, only zeroes may be used as decimal digits following a value of "1". When the alpha value is not supplied, a value of '1' is assumed.

From andrew.hankinson on December 06, 2012 23:09:25
I would agree with Johannes on this. I've never seen a 4-pair hex combo for alpha.
The last sentence in the documentation could read something like:
"Any decimal value between '0' and '1' is permitted as an alpha channel value, with '0' being fully transparent and '1' being fully opaque. When the alpha value is not supplied, a value of '1' is assumed."
A quick search for a CSS colour regex turns up this: http://www.kylirhorton.com/2008/a-regular-expression-that-matches-css-colors/ (#([0-9A-Fa-f]{3,6})\b)|
(aqua)|(black)|(blue)|(fuchsia)|
(gray)|(green)|(lime)|(maroon)|
(navy)|(olive)|(orange)|(purple)|
(red)|(silver)|(teal)|(white)|(yellow)|
(rgb(\s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
\s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
\s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*))|
(rgb(\s*(\d?\d%|100%)+\s*,\s*(\d?\d%|100%)+\s*,\s*(\d?\d%|100%)+\s*))

From<EMAIL_ADDRESS>on December 07, 2012 01:34:05
Actually, Perry's suggestion is wrong again. rgba() always needs the alpha channel decimal number. It's rgb() which goes without it (thus allowing only three numbers from 0 to 255). Andrew's snippet doesn't consider rgba(), but only rgb(). Should be easy to add, though. Actually, what if we provide a list for the named values, and separate regex' for the hex, rgba(), rgb(), hsl() and hsla() schemes? Seems the best to maintain. By the way, we don't want to include the increased set of color names, do we? This would add a whole bunch of other values.
The official ruleset for colors in CSS(3) can be found at http://www.w3.org/TR/css3-color/ From there I just learned that the values in rgba() may also be expressed as percentage…

From<EMAIL_ADDRESS>on December 07, 2012 02:12:01
Hi all,
I tried to work in all the different options, instead of complaining about your work (sorry for that :-) I hope I got everything covered, and I may be definitely wrong. Also, there are probably more elegant ways of doing it. I used Andrew's regex as muhc as possible, though I didn't get the intention of some + (they seemed to be wrong…). Here's my result:
<content>
<rng:choice>
<!-- hex values -->
<rng:data type="token">
<rng:param name="pattern">(#[0-9A-Fa-f]{6,6})</rng:param>
</rng:data>
      \<!-- rgb values -->
      \<rng:data type="token">
        \<rng:param name="pattern">
          (rgb\(\s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
          \s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
          \s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*\))|
          (rgb\(\s*(\d?\d%|100%)\s*,\s*(\d?\d%|100%)\s*,\s*(\d?\d%|100%)\s*\))
        \</rng:param>
      \</rng:data>

      \<!-- rgba values -->
      \<rng:data type="token">
        \<rng:param name="pattern">
          (rgba\(\s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
          \s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
          \s*\b([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\b\s*,
          \s*\b(0\.\d+|1(\.\d+)?)\b\s*\))|
          (rgba\(\s*(\d?\d%|100%)\s*,\s*(\d?\d%|100%)\s*,\s*(\d?\d%|100%)\s*,\s*\b([01](\.\d+)?)\b\s*\))
        \</rng:param>
      \</rng:data>

      \<!-- hsl values -->
      \<rng:data type="token">
        \<rng:param name="pattern">
          (hsl\(\s*\b(\d{1,2}|[12]?\d{2}|3[0-5]\d|360)\b\s*,
          \s*\b(\d?\d%|100%)\b\s*,
          \s*\b(\d?\d%|100%)\b\s*\))
        \</rng:param>
      \</rng:data>

      \<!-- hsla values -->
      \<rng:data type="token">
        \<rng:param name="pattern">
          (hsla\(\s*\b(\d{1,2}|[12]?\d{2}|3[0-5]\d|360)\b\s*,
          \s*\b(\d?\d%|100%)\b\s*,
          \s*\b(\d?\d%|100%)\b\s*,\s*\b([01](\.\d+)?)\b\s*\))
        \</rng:param>
      \</rng:data>

      \<!-- color names-->
      \<rng:value>aqua</rng:value>
      \<rng:value>black</rng:value>
      \<rng:value>blue</rng:value>
      \<rng:value>fuchsia</rng:value>
      \<rng:value>gray</rng:value>
      \<rng:value>green</rng:value>
      \<rng:value>lime</rng:value>
      \<rng:value>maroon</rng:value>
      \<rng:value>navy</rng:value>
      \<rng:value>olive</rng:value>
      \<rng:value>purple</rng:value>
      \<rng:value>red</rng:value>
      \<rng:value>silver</rng:value>
      \<rng:value>teal</rng:value>
      \<rng:value>white</rng:value>
      \<rng:value>yellow</rng:value>

    \</rng:choice>
  \</content>

From<EMAIL_ADDRESS>on December 07, 2012 08:14:31
Just tried to generate RNG from an ODD that includes Jo's attempt at constraining color values.  Got the following error:
E [Jing] invalid parameter: invalid regular expression: illegal escape:
(hsla(\s*>>>>b(\d{1,2}|[12]?\d{2}|3[0-5]\d|360)\b\s*,
\s*\b(\d?\d%|100%)\b\s*,
\s*\b(\d?\d%|100%)\b\s*,\s*\b(01?)\b\s*))
Also, all this attention to the myriad ways of color representation in CSS still doesn't help with the immediate problem -- whether or how to accommodate the MusicXML color specification, which uses hexadecimal ARGB tuples.

From<EMAIL_ADDRESS>on December 07, 2012 08:36:03
In your copied Jing message, do the angle brackets indicate the problem? They weren't in my original post. I have to admit that I haven't used these \b delimiters ever before, and just kept them from the regex Andrew found. Would it help to remove them? The whitespace could probably go away as well - it seems helpful to identify randomly formatted CSS colors, but less helpful to enforce a consistent encoding style.
MusicXML's color representation should not guide us, especially if it invents something as weird as an 8 character hex value… For the MusicXML<->MEI stylesheets, it should still be easy to translate between. A search for "xslt convert decimal hex" reveals some promising stylesheets. So if this is the problem, I thing we shouldn't address it in the schema, but in the processor.

From<EMAIL_ADDRESS>on December 07, 2012 11:41:15
I think the following fixes the problems with Jo's suggestions.  It also allows AARRGGBB values because I don't want to get into color conversion of MusicXML.
<macroSpec ident="data.COLOR" module="MEI" type="dt" mode="replace">
<desc>A value in one of the following forms is expected: 1) hexadecimal RRGGBB, 2)
hexadecimal AARRGGBB, 3) CSS RGB, 4) CSS RGBA, 5) HSL, 6) HSLA, or 7) HTML 4.01 color
name.
<content>
<rng:choice>
<!-- hex values -->
<rng:data type="token">
<rng:param name="pattern">#[0-9A-Fa-f]{6,6}</rng:param>
</rng:data>
<!-- AARRGGBB values -->
<rng:data type="token">
<rng:param name="pattern">#[0-9A-Fa-f]{8,8}</rng:param>
</rng:data>
<!-- RGB values -->
<rng:data type="token">
<rng:param name="pattern"
>rgb(\s*((0|1(\d{1,2})?|2-9?|2([0-5]{2})?)\s*,\s*){2}(0|1(\d{1,2})?|2-9?|2([0-5]{2})?)\s*)|rgb(\s*((\d{1,2}%|100%)\s*,\s*){2}(\d{1,2}%|100%)\s*)</rng:param>
</rng:data>
<!-- RGBA values -->
<rng:data type="token">
<rng:param name="pattern"
>rgba(\s*((0|1(\d{1,2})?|2-9?|2([0-5]{2})?)\s*,\s*){3}(0(.\d+)?|1(.0+)?)\s*)|rgba(\s*(((\d{1,2})?%|100%)\s*,\s*){2}(\d{1,2}%|100%)\s*,\s*(0(.\d+)?|1(.0+)?)\s*)</rng:param>
</rng:data>
<!-- HSL values -->
<rng:data type="token">
<rng:param name="pattern"
>hsl(\s*((\d{1,2})|[12]\d{2}|3[0-5]\d|360)\s*,\s*(\d{1,2}%|100%)\s*,\s*(\d{1,2}%|100%)\s*)</rng:param>
</rng:data>
<!-- HSLA values -->
<rng:data type="token">
<rng:param name="pattern"
>hsla(\s*(\d{1,2}|[12]\d{2}|3[0-5]\d|360)\s*,\s*(\d{1,2}%|100%)\s*,\s*(\d{1,2}%|100%)\s*,\s*(0(.\d+)?|1(.0+)?)\s*)</rng:param>
</rng:data>
<!-- color names -->
<rng:value>aqua</rng:value>
<rng:value>black</rng:value>
<rng:value>blue</rng:value>
<rng:value>fuchsia</rng:value>
<rng:value>gray</rng:value>
<rng:value>green</rng:value>
<rng:value>lime</rng:value>
<rng:value>maroon</rng:value>
<rng:value>navy</rng:value>
<rng:value>olive</rng:value>
<rng:value>purple</rng:value>
<rng:value>red</rng:value>
<rng:value>silver</rng:value>
<rng:value>teal</rng:value>
<rng:value>white</rng:value>
<rng:value>yellow</rng:value>
</rng:choice>
</content>
</macroSpec>

From<EMAIL_ADDRESS>on December 07, 2012 12:44:46
Perry wrote:
> It also allows AARRGGBB values because I don't want to get into color conversion of MusicXML.
I fear this only postpones the problem. Other applications relying on standard CSS colors will then have to do it.
 I volunteer writing the color conversion, if this helps.

From andrew.hankinson on December 07, 2012 12:55:20
I don't think this is really a fair assessment. #AARRGGBB is an accepted form (so is #RRGGBBAA), and since we're providing a superset of CSS3 colour values, there is nothing lost here.
By all means we should support the CSS spec, but that doesn't preclude supporting other specs too.

From<EMAIL_ADDRESS>on December 07, 2012 13:05:32
I agree that it is not harmful to include more possibilities, as soon as we have support for CSS(3). But, if I understand correctly, both hex rgba and hex argb are expressed with eight hex digits. There seems to be no way to distinguish between them. Ig that's true, I would prefer to wait until CSS4 is actually finalized. After all, they could change their mind…

From<EMAIL_ADDRESS>on December 07, 2012 14:03:33
Sorry if I confuse something, but aren't we providing a subset of CSS3 color values rather than a superset?

From<EMAIL_ADDRESS>on December 07, 2012 14:18:16
Yes, we provide a subset, but only with regard to color names. CSS3 adopts a whole bunch of color names from SVG, including values like "darkgoldenrod", "mediumorchid", "moccasin", "papayawhip", "peachpuff" amd "saddlebrown". Other than these, the regex sketched above includes all valid CSS3 color schemes. According to Andrew, hex rrggbbaa / aarrggbb will be part of CSS4. Looking at http://www.w3.org/Style/CSS/Tracker/products/17 , I see only rrggbbaa, cmyk() and hlc(), though. So MusicXML's implementation won't even match CSS4, which seems like another argument against adopting their approach.

From<EMAIL_ADDRESS>on December 07, 2012 15:58:44
If Thomas is willing to provide an XSLT named template for converting AARRGGBB to RGBA, I'm perfectly happy not to support MusicXML's attempt at CSS4 prognostication.  Thomas, how soon can you get it to me?

From<EMAIL_ADDRESS>on December 07, 2012 23:24:23
The template can be ready today, at the latest tomorrow.

From<EMAIL_ADDRESS>on December 08, 2012 13:30:43
Perry, the code is attached. I included two variants to choose from:

As you suggested, a named template that takes a string as argument
A matching template that turns an aarrggbb <color> element into a color attribute (feels more elegant to me)

You should probably throw away one of them. A third alternative would be a function aarrggbb2css() (would be almost the same as the named template).
All of them require the function hex2integer(). I chose the namespace " http://music-encoding.org/tools/musicxml2mei " for this function, but this is arbitrary.
If something needs improvement, let me know.
Attachment: aarrggbb2css.xsl

From<EMAIL_ADDRESS>on March 14, 2013 11:19:05
This issue was closed by revision r860 .
Status: Fixed


Get-DbaDatabaseSnapshot, test suite

Type of Change

[ ] Bug fix (non-breaking change, fixes #)
[ ] New feature (non-breaking change, adds functionality)
[ ] Breaking change (effects multiple commands or functionality)
[x] Ran manual Pester test and has passed (`.\tests\manual.pester.ps1)
[x] Pester test is included

Purpose
Adding pester tests

(do Snapshot)

thank you so much 💯


Use RAW_IO on Windows for bulk and interrupt IN endpoints

Windows serializes IN transfers by default, negating the usefulness of Queue. RAW_IO disables this.
Libusb is adding an option for RAW_IO and decided to not turn it on by default for fear of breaking existing code that makes requests that are not a multiple of maxPacketSize. But nusb has no such consideration, and already documents that IN transfers must be a multiple of maxPacketSize, because it's a good idea anyway to avoid errors on overflow. I think RAW_IO should just be turned on unconditionally, and not doing so is just failing to provide the streaming behavior that users would expect.

I'm the author of the libusb RAW_IO support and have been running into this issue on different projects for many years. Everyone's instinct is always to try to abstract the issue away, but it's trickier than it seems.
I don't think your approach of requiring all inbound bulk transfers be a multiple of maxPacketSize is viable if you want the library to be usable for any and all devices. I think the maxPacketSize limitation should be removed from the bulk_in and interrupt_in methods.
Sometimes you will need to read a specific, small number of bytes from an endpoint, and the device just doesn't have any more than that to give you. Think simple serial protocols implemented over a pair of bulk endpoints, for instance. Making the host keep polling for more bytes than are actually expected may cause unwanted behaviour. Even if it is safe to keep polling, the maxPacketSize limitation means that the caller cannot express their wish for a transfer to return once it has N bytes, or at a given timeout. They must set either set a long timeout, and wait unnecessarily for more bytes even after N have arrived, or set a short one that works in most cases and then need to handle the case where the device is a little slower.
It would make sense for the Queue API to make use of RAW_IO, and to use multiple-of-maxPacketSize transfers internally, but there is no need to place that limitation on all individually submitted transfers, and doing so may make the library impractical to use for some use cases.
This raises a related issue, though: does a Queue have exclusive use of an endpoint during its lifetime? If so, it's straightforward for Qeueu to enable RAW_IO on the endpoint, and disable it again if the Queue is dropped.
However, the current API appears to allow for individual transfers to be submitted on an endpoint, whilst that endpoint is simultaneously in use by a Queue. That seems like it would only ever cause problems, and probably ought not to be permitted.
Personally I would have been inclined to make the API use an Endpoint type, instances of which would be obtained from an Interface, rather than sticking with the libusb pattern of simply referencing an endpoint as a u8. Then exclusive ownership of a given endpoint would be available in a straightforward and idiomatic way, which would make it possible to deal with the RAW_IO issue much more cleanly.

Sometimes you will need to read a specific, small number of bytes from an endpoint, and the device just doesn't have any more than that to give you. Think simple serial protocols implemented over a pair of bulk endpoints, for instance. Making the host keep polling for more bytes than are actually expected may cause unwanted behaviour. Even if it is safe to keep polling, the maxPacketSize limitation means that the caller cannot express their wish for a transfer to return once it has N bytes, or at a given timeout.

If you submit an IN transfer of maxPacketSize, and the device responds with a packet that is smaller than that, it's a short packet that  ends the transfer and you get the data immediately, right? Or does WinUSB with RAW_IO not behave like other OSs in that regard?
It seems like the only drawback is requiring you to allocate more memory than you actually use if you know the device never sends a full packet, but we're talking about <1024 bytes per transfer here, so not a big deal on the host.

This raises a related issue, though: does a Queue have exclusive use of an endpoint during its lifetime?

Currently, no. If you use multiple queues on an endpoint or submit transfers outside of a queue, the ordering is not defined and you probably shouldn't do this, but it won't do anything bad.

Personally I would have been inclined to make the API use an Endpoint type, instances of which would be obtained from an Interface

This was my initial plan, basically making Queue AKA Pipe AKA Endpoint the only API and rejecting attempts to create more than one per endpoint. However when implementing it I didn't see a need to go out of my way to track and prevent creating multiple when there was no memory safety reason to do so, and worried that forcing people into the Queue pattern was too radical a change. I added the individual transfer API with TransferFuture because it was easy and seemed like what people would expect to see if they didn't want Queue. However, the TransferFuture API is full of footguns around cancellation, so I'd consider going back to only offering Queue and could make it exclusive.

If you submit an IN transfer of maxPacketSize, and the device responds with a packet that is smaller than that, it's a short packet that ends the transfer and you get the data immediately, right? Or does WinUSB with RAW_IO not behave like other OSs in that regard?
It seems like the only drawback is requiring you to allocate more memory than you actually use if you know the device never sends a full packet, but we're talking about <1024 bytes per transfer here, so not a big deal on the host.

Ah, we're thinking at different layers of abstraction. I was thinking in terms of asking for length N causing the library to make as many requests to the OS as needed to fill that length, until hitting a timeout if set.
Since you're treating a short packet as ending a transfer, and also requiring the use of a specific RequestBuffer that the user will have to copy from, rather than letting the user send data straight into their own structures, then requiring transfers to be a multiple of maxPacketSize makes more sense than I initially thought.
There are also cases where one may need to receive exactly N bytes from an endpoint, and where those N bytes may come in multiple short packets, but that can be addressed one layer above this API.

Currently, no. If you use multiple queues on an endpoint or submit transfers outside of a queue, the ordering is not defined and you probably shouldn't do this, but it won't do anything bad.

It may not do anything bad in the sense of memory safety, but it still seems bad - is there any use case where it would do something useful?

This was my initial plan, basically making Queue AKA Pipe AKA Endpoint the only API and rejecting attempts to create more than one per endpoint. However when implementing it I didn't see a need to go out of my way to track and prevent creating multiple when there was no memory safety reason to do so, and worried that forcing people into the Queue pattern was too radical a change. I added the individual transfer API with TransferFuture because it was easy and seemed like what people would expect to see if they didn't want Queue. However, the TransferFuture API is full of footguns around cancellation, so I'd consider going back to only offering Queue and could make it exclusive.

I think you're seeing a false dichotomy here. It's not a question of either u8 or a single "Queue AKA Pipe AKA Endpoint" type. There's no need for Endpoint and Queue to be the same type. I would make them separate.
Requesting an Endpoint from an Interface would just give you an exclusively owned handle to that endpoint, on which you could submit individual transfers. This would be useful in itself, to help manage the use of an endpoint within a program. For instance, you could have TX and RX threads, one owning a bulk IN endpoint and the other a bulk OUT one.
If you wanted to use the Queue pattern, you would construct the Queue around the Endpoint, giving it ownership. If you then wanted to return to submitting individual transfers on that endpoint, Queue could have a method that consumes the Queue and returns the original Endpoint.

I started sketching out what a PR for this might look like.
There's a few decisions to take. The first one is whether to require a program to specifically request RAW_IO.
Personally I would love it if everything just worked, at maximum performance, without downstream developers ever having to think specifically about this nasty little quirk of WinUSB. And unlike libusb, you've made the decision upfront to require that all transfers be a multiple of the endpoint's maximum packet size, which makes it possible for this to be done transparently.
So I'm in favour of this being fully automatic, but making that choice does impose some new complexity: nusb would have to transparently split up large transfers into smaller WinUsb_ReadPipe operations in order to satisfy the maximum transfer size requirement for RAW_IO. Personally I think that's a viable choice, but I'd like to know what you think before pursuing that approach.
If nusb does take that approach, there's a further choice: when should it actually make the necessary SetPipePolicy and GetPipePolicy calls? I think the best option is in PlatformSubmit::submit, just before the first ReadPipe call on an endpoint - and then keeping a map in WindowsInterface of which endpoints have had RAW_IO enabled, and what the maximum transfer size for them is.
Alternatively, the SetPipePolicy and GetPipePolicy calls could be done pre-emptively when an interface is claimed, for all inbound bulk or interrupt endpoints on that interface. I'm less keen on that, as it adds unnecessary calls that can go wrong, but there's an argument for it if you want to keep operations at submission time to an absolute minimum.
This is one area where I feel like including an Endpoint type in the API might have been helpful, because it would give you somewhere to do any per-endpoint setup work and store per-endpoint state. But it's not essential.

So I'm in favour of this being fully automatic, but making that choice does impose some new complexity: nusb would have to transparently split up large transfers into smaller WinUsb_ReadPipe operations in order to satisfy the maximum transfer size requirement for RAW_IO. Personally I think that's a viable choice, but I'd like to know what you think before pursuing that approach.

Yes, I think it would ideally be automatic.
What kind of per-transfer size limits are we talking about here? I remember seeing 4 MB somewhere, which is similar in magnitude to what you might want to limit yourself to on Linux given its 16MB default system wide transfer limit. Wondering if it's viable to punt that to the library user, either by documentation or by exposing the limit in a new API (though is there an API that would make sense for that cross-platform?).
My design philosophy with nusb has been to keep everything as thin of a wrapper around OS capabilities as possible and avoid hidden internal state. So I think it would ideally not split up transfers, but I could be convinced that it's worth it here if the limit is small. Libusb goes too far in trying to cover up OS differences, but it is possible to go too far in the other direction and make it hard to write portable code.

when should it actually make the necessary SetPipePolicy and GetPipePolicy calls?

PlatformSubmit::submit seems reasonable. The one thing is that error handling is a little messy there, because I chose to make transfer submit not able to fail synchronously so users only need one error handling path. So you have to stash the error and fake a completion on the transfer to fail asynchronously. I'm not sure how fallible SetPipePolicy actually is, in cases other than bad args, though, and if it fails unexpectedly you maybe want to log something continue without RAW_IO rather than fully breaking.

This is one area where I feel like including an Endpoint type in the API might have been helpful, because it would give you somewhere to do any per-endpoint setup work and store per-endpoint state. But it's not essential.

Yeah, I've tentatively decided that this is a good idea for v0.2 or v1.0. I kind of want to get the library feature-complete before redesigning the API though just to make sure all constraints are considered (e.g. https://github.com/kevinmehall/nusb/issues/11, https://github.com/kevinmehall/nusb/issues/47).

What kind of per-transfer size limits are we talking about here? I remember seeing 4 MB somewhere, which is similar in magnitude to what you might want to limit yourself to on Linux given its 16MB default system wide transfer limit.  Wondering if it's viable to punt that to the library user, either by documentation or by exposing the limit in a new API (though is there an API that would make sense for that cross-platform?).

In older versions of Windows IIRC it can be as small as 64KB, minus a page or so. These days it's usually 2.1MB (0x1FEC00), but I think it can also be ~256KB for Low/Full speed devices.
The problem with trying to document it is that there is no guarantee of these numbers. There's no defined constants, you can only query what the limit is at runtime for a specific endpoint. We could document the behaviour seen in practice, but Windows could legitimately just decide to start using different limits.

My design philosophy with nusb has been to keep everything as thin of a wrapper around OS capabilities as possible and avoid hidden internal state. So I think it would ideally not split up transfers, but I could be convinced that it's worth it here if the limit is small. Libusb goes too far in trying to cover up OS differences, but it is possible to go too far in the other direction and make it hard to write portable code.

I think that the options are either:

Let the maximum transfer size be unlimited, and split large transfers into smaller parts at the OS level where needed.
Add an API that allows querying the maximum transfer size that can be submitted for a given endpoint, and make it the caller's responsibility to split larger reads up into multiple transfers.

Personally I'm in favour of option 1.
I feel like option 2 just creates some extra needless hoops for the caller to jump through, without really providing any additional control or insight as a result. From the program's point of view, the possible outcomes for an internally-subdivided transfer are exactly the same as for one that's submitted as a unit: it either completes successfully, or it completes partially with an error.
Option 2 may also lead to surprising differences in behaviour when the same program is run on different systems. Consider a program that needs to make a very large read. It queries the maximum transfer size it can use, and splits its transfers accordingly, as required. On the developer's Windows system the program reads at say 20-40MB/s and the max transfer size is 2.1MB. They find they can use the completion of a transfer as a good opportunity to update a progress bar during a large read operation; on Windows it will update smoothly at 10-20Hz or so. Then a user runs that same program on another OS with no transfer size limit, and now the progress bar hangs until the end of the operation. Or they run it on a system with a very small transfer limit, and now it eats a lot of CPU because it's trying to redraw the UI too often.
If we choose option 1, then the behaviour from the point of view of the caller is always consistent. If you submit a large transfer, you get a single event when it completes. If you want more frequent events you submit smaller transfers. The observed behaviour from the caller's point of view is always the same, even if different things may be happening behind the scenes.
In fact it's not necessary to choose just one or the other. We could both provide an API that allows querying the maximum OS transfer size supported for an endpoint, and also give nusb the ability to split up transfers that are larger than this. Then if the caller does not want their transfers to be split, they can query the max size and act accordingly. If they don't care, they can just submit whatever size they want - provided it's a multiple of max packet size - and nusb will deal with it.

PlatformSubmit::submit seems reasonable. The one thing is that error handling is a little messy there, because I chose to make transfer submit not able to fail synchronously so users only need one error handling path. So you have to stash the error and fake a completion on the transfer to fail asynchronously. I'm not sure how fallible SetPipePolicy actually is, in cases other than bad args, though, and if it fails unexpectedly you maybe want to log something continue without RAW_IO rather than fully breaking.

I'm not sure how fallible it is either. But I don't think there's ever a case where we'd have to signal an error there. In the case where SetPipePolicy fails, we can just log a warning and continue without RAW_IO. It's only a performance loss.
On libusb, this issue is much nastier, because potentially they may need to make it possible to disable RAW_IO, in order to go back to submitting odd-size transfers. If SetPipePolicy fails at that point, then the program is completely stuck.

Yeah, I've tentatively decided that this is a good idea for v0.2 or v1.0. I kind of want to get the library feature-complete before redesigning the API though just to make sure all constraints are considered (e.g. #11, #47).

That makes sense. One thing I think it would help with is reducing the amount of locking needed. Currently you may have multiple threads working different endpoints, but they all need to share the WindowsInterface. So just to store a record of which endpoints have had RAW_IO enabled, I found I needed something like raw_io: Mutex<HashMap<u8, usize>> in that struct, and now every submit call has to take that lock.

In older versions of Windows IIRC it can be as small as 64KB, minus a page or so. These days it's usually 2.1MB (0x1FEC00), but I think it can also be ~256KB for Low/Full speed devices.

Rust dropped support for Windows versions older than 10, which seems like a reasonable minimum support target, and Windows 10 is the only version I've tested nusb on.

The problem with trying to document it is that there is no guarantee of these numbers. There's no defined constants, you can only query what the limit is at runtime for a specific endpoint. We could document the behaviour seen in practice, but Windows could legitimately just decide to start using different limits.

Yeah, I wouldn't be comfortable with promising a specific value either, but it seems like the trend is upwards and unlikely that Microsoft would lower the limit.

From the program's point of view, the possible outcomes for an internally-subdivided transfer are exactly the same as for one that's submitted as a unit: it either completes successfully, or it completes partially with an error.

Does WinUSB have a way to atomically cancel subsequent IN transfers after receiving a short packet that normally terminates a transfer? Linux has USBDEVFS_URB_BULK_CONTINUATION for this, but I don't see anything similar as a WinUSB pipe policy.

Consider a program that needs to make a very large read. It queries the maximum transfer size it can use, and splits its transfers accordingly, as required. On the developer's Windows system the program reads at say 20-40MB/s and the max transfer size is 2.1MB. They find they can use the completion of a transfer as a good opportunity to update a progress bar during a large read operation; on Windows it will update smoothly at 10-20Hz or so. Then a user runs that same program on another OS with no transfer size limit, and now the progress bar hangs until the end of the operation. Or they run it on a system with a very small transfer limit, and now it eats a lot of CPU because it's trying to redraw the UI too often.

I've been meaning to write some examples / convenience wrappers on top of Queue that could implement Read / AsyncRead / Write / AsyncWrite. If someone wants to e.g. read a big file from a device, I think they would ideally be using something higher level than expecting to submit it as a single transfer. Individual transfers are a fairly low-level API, and there are lots of different ways to abstract them depending on the nature of their use. I think it could be in scope for nusb to provide abstractions for different common patterns here, but that could be a layer on top of Transfer and Queue.
Anyway, I'm not sure here. I think I'd prefer to start with the simple approach of not splitting transfers, and revisit if it actually becomes a practical problem for someone. But if you've already started that code, I'd be happy to take a look at it.

Rust dropped support for Windows versions older than 10, which seems like a reasonable minimum support target, and Windows 10 is the only version I've tested nusb on.

I agree that targeting Windows 10 for support/testing is reasonable, but note that support was not completely dropped for older versions. Rust is still able to build programs for even much older Windows versions. They just no longer have Tier 1 support.

Does WinUSB have a way to atomically cancel subsequent IN transfers after receiving a short packet that normally terminates a transfer? Linux has USBDEVFS_URB_BULK_CONTINUATION for this, but I don't see anything similar as a WinUSB pipe policy.

That's a great point, and no, not that I'm aware of. In all the cases I've encountered where I've needed RAW_IO, I've been streaming from endpoints where either I never expect a short packet at all, or where a short packet marks the end of the stream and no further data will follow if the device is polled again - or at least unless some control request is sent first.
If you had an endpoint that will send chunks of data one after the other, with each delimited by a short packet, and you wanted to be sure to grab only one chunk and not poll further -- then I think really it's not safe to be queuing up multiple transfers at all. You can do so if you can be certain there is a feature like USBDEVFS_URB_BULK_CONTINUATION in effect, but that seems dangerous to assume for a cross-platform API. Is there a feature like that on macOS? And does the Linux version actually guarantee that the host controller will not poll again, or can it be the case that the next operation is already queued in the hardware, even if the kernel-side queue is atomically cancelled?

I've been meaning to write some examples / convenience wrappers on top of Queue that could implement Read / AsyncRead / Write / AsyncWrite.

That sounds good, and would certainly alleviate a lot of the hoop-jumping.

I think I'd prefer to start with the simple approach of not splitting transfers, and revisit if it actually becomes a practical problem for someone. But if you've already started that code, I'd be happy to take a look at it.

OK. I hadn't gotten as far as implementing that. So I'll go with the simpler option and see how it looks.


Added html header to fetch Msonormal styles from Office document

Pull Request Description
This change will help Outlook client to recreate the message after the link is added in the bottom of the body.
For more explanation and links see my answer to this stackoverflow: https://stackoverflow.com/questions/51603265/line-spacing-increased-issue-when-updating-email-body-with-office-js/78542353#78542353
Fixes #31
Checklist

[x] Changes are limited to a single goal (avoid scope creep)
[x] I confirm that I have read any Contribution and Development guidelines (CONTRIBUTING and DEVELOPMENT) and are following their suggestions.
[x] I confirm that I wrote and/or have the right to submit the contents of my Pull Request, by agreeing to the Developer Certificate of Origin, (adding a 'sign-off' to my commits).

Thanks for your contribution! I edited your comment to reference the issue that this PR fixes 😊

This looks good!! However, after making our Contribution guidelines we decided that commits should contain a reference of the issue that it solves, and they should also be signed off and verified. Could you perhaps make these changes and commit amend your last commit?


Fixed Constructor in CustomAccountFactory

@alfkonee Thank you for fixing this!

@scottaddie U WC

Yes, thanks @alfkonee ... It was a cut-'n-paste that snuck in. 😈 Sneaky Code:tm: 😈
https://github.com/dotnet/AspNetCore.Docs/issues/17650


Compatability with Fluidlogged

Gamebreaking compatability issue with fluidlogged, does not launch

Correction, launching problem was unrelated. Disregard this issue.


Enabling external labels for Jaeger pods

For enabling pod level labeling in Jaeger do we have spec recommended way  ?

The labels you specify as part of the Jaeger CR should be propagated down to the underlying resources, including pods.

I am using spec.metadata.labels to mention labels at pod level as mentioned below.
apiVersion: {{ .Values.apiVersion.Jaeger}}
kind: Jaeger
metadata:
  name: jaeger-cluster
spec:
  metadata:
    labels:
      foo: bar
  strategy: production

But labels are not reflecting at Jaeger pod level

@rubenvp8510 , could you please take a look?

@munipravy should it be
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: jaeger-cluster
spec:
    labels:
      foo: bar
  strategy: production

I don't think we have a spec.metadata.labels.
kubectl explain jaeger.spec.labels
...
FIELD:    labels <map[string]string>
...

kubectl explain jaeger.spec.metadata.labels

error: field "metadata" does not exist


Failed to launch the browser proces

Hey you're doing great , recently i've been receiving this error on my linux vm a lot prenvent it  fro getting the cookies properly :
Protocol error (Security.setIgnoreCertificateErrors): Target closed
Failed to launch the browser process! undefined
[2305436:2305436:0620/091534.303263:ERROR:ozone_platform_x11.cc(244)] Missing X server or $DISPLAY
[2305436:2305436:0620/091534.303356:ERROR:env.cc(258)] The platform failed to initialize.  Exiting.

You are running with docker, right? There are many dependencies. Does this error occur when running a docker image? Which processor is your server using?

You are running with docker, right? There are many dependencies. Does this error occur when running a docker image? Which processor is your server using?

i use github and get the same issue

Can you try again with the latest version?

The library has been updated. It should now run smoothly. I am closing this issue, please let me know if you have any problems by writing a message through this issue. Thank you.


Fixed loading of tabs, implemented delayed loading on re-open (#1061), and tab visit order (#1070)

The bug of forgetting tab urls described in #1061 was due to delayed loading on opening the tab, which caused the URL of the tab not set when quitting the application.
The other problem was solved by only re-loading tabs when they are selected. This makes the whole startup much faster than before. Tabs still load when being opened for the first time from the feed, though. In that respect the old behavior did not change. This helps with displaying the correct title for the tab soon after opening it, and accounts for that users probably want to read the tab content during the session.

Sorry about the titles, I didn’t find a solution for reliably loading just the title of a site without its content. Before my change, tab titles were „loading“ until the tab had reloaded. I could try a website „HEAD“ request to solve that. But also now it’s only the first time after the update. The implementation of the model for the tabs is somewhat implicit so there is no real data structure that could support an ordering. But I can probably do a larger restructuring of the tabbing next week to solve #1070.

Firstly, this looks great - your code is very clean and I'm really happy to have a PR of this quality so thank you!
However, each time a new tab opens I am seeing the following message in the Xcode console:
2018-02-12 15:00:00.513450+0800 Vienna[6623:108837] *** Assertion failure in -[PSMTabBarCell _objectValue:forString:errorDescription:], /BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1561.40.104/AppKit.subproj/NSCell.m:1692

Could you please look into this?
Thanks again :)

Ok the last changes fix some of the oddness of titles and add the feature #1070 (although not in a persistent manner). I have added two booleans into the interface in BrowserPane.m that should be present in the preferences, to make the tabbing behaviour configurable according to the reading preferences of the user. If @josh64x2 or @barijaona could change the preferences it would be nice!

I could not reproduce your observation though, @josh64x2 . Maybe because I freshly installed the pods when I first downloaded the project. The assertion failure you see seems to originate from the PSMTabBar, which could be a newer version in my project due to the fresh installation.

Not sure I understand the latest commits : why is the primary tab treated differently ?
I guess that most of the time, the user expects to return to the article list after having read the details of an article.

The first commit are just fixes to the tab title saving (there were a couple of bugs in my first commit).
The second commit is about the order that tabs are opened when the current one gets closed:
As suggested in #1070 , I implemented, that the last visited tab gets opened once the current one gets closed. This has the benefit that not a random tab that happens to be left or right of the current one gets opened and loaded, which is beneficial to the lazy tab loading I implemented as a solution for #1060 . The first tab is treated differently because I assumed that if a user opened multiple tabs, he changes to the tabs from the reading list to read them. It would be really annoying to return to the article list every time when closing a tab.
The user setting is for users who actually want the old Safari-like behavior: Just opening the tab right of the current one when the current one is closed, and if the current tab was the last one opening the tab that is left of the current one. We could make it default to have the old behavior by disabeling the tab-order option.
The user setting has a second part: When a tab is opened, does it move to the last or the first spot in the order? This setting can be omitted and we can just use a sensible default. It depends on a user´s habits though, if he reads the tabs he has opened from left to right (selectNewItemFirst = NO) or from right to left ('selectNewItemFirst = YES'). The setting only applies if the tab ordering option is enabled.

We could implement actually #1071 in order to move to the article tab faster, which would mitigate the special treatment when closing tabs.

OK this is looking good - I  haven't been able to reproduce the assertion failure I was getting previously so let's just blame it on macOS 10.13 being a bit weird :)
I hope to have some time to work on the preferences this weekend.
Could you please put your commits in a new branch on your fork of the repository so they aren't directly on master?
Thanks 😄

I changed the branch in my fork and recreated the pull request (new request: #1088 )


implement nakamoto consensus, follow the latest valid chain

[ ] follow the longest valid chain
[ ] if there are 2 valid blocks at the same height, wait for the following block
[ ] if there is a chain discovered that can get validated, replace the current one with it

can be started after #97

if there are 2 valid blocks at the same height, wait for the following block
Shouldn't we maybe compare them by hash? (lower is better?) We have to choose something if we would like to mine.

no, this would be a "most work" kind of consensus, as the miner we choose the one we received earlier to maximize possible profit. We will research other consensus mechanisms in the future, if you have any ideas we can discuss them and build a prototype to validate.

ok, I understand now.

closed by #162


i can type text on css

Type: Feature Request
i try to learn css or even html but i can't write on css, system doesn't find "background" i think i'm on the wrong language but i can't find css, and when i need html i need to go manually on hmtl to select and type in it. sorry for my english....
VS Code version: Code 1.83.1 (f1b07bd25dfad64b0167beb15359ae573aecd2cc, 2023-10-10T23:48:05.904Z)
OS version: Windows_NT x64 10.0.22621
Modes:

 I attached screenshots, when I type "back" to find background it doesn't appear, same for a color as if I didn't have the right software, I'm a beginner so I can't find the solution De : Martin AeschlimannEnvoyé le :lundi 30 octobre 2023 11:24À : microsoft/vscodeCc : Kodoiku; AuthorObjet :Re: [microsoft/vscode] i can type text on css (Issue #196917) Please provide a small code sample that shows the problem.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID<EMAIL_ADDRESS>
Pasting your sample in a new test.css file shows the following errors:

@font-face rule must define 'src' and 'font-family' properties
Unknown property: 'mso-style-priority' and Unknown property: 'mso-style-type'`

This looks expected. Maybe you are programming in a variant of css?
Also code completion inside a rule body seems to work:

So from a VS Code standpoint, all seems to work as expected.
For programming help, I can not help you. Check out stackoverflow or other resources.


WIP: ENH: Integrating LAPACK "expert" routines with conditioning warnings for linalg.solve_ family

This is a rework of #6693
As briefly discussed in #6634, in this PR the ?GESVX routine of LAPACK is exposed for generic use. They are the so-called eXpert versions of the already existing ?GESV routine family which are used in sp.linalg.solve (also ?SYSVX, ?HESVX, ?POSVX are also exposed).
The use case for these routines are many-fold

The most important case is to finally change the silent singular matrix handling. With the condition number and error estimates, a warning/error/msg can be emitted (needs-decision).
Ill-conditioned matrices can be checked before inversion steps and nonsensical results can be avoided
cond and rcond functions can now use estimates for comparison
the lu factorization comes with a bonus (as is with ?GESV too but the API throws it away currently)
The numerical accuracy is improved thanks to the balancing and iterative refinement (Lapack prefers the term equilibration for this particular instance).
The right inversion is currently a bit annoying, that is to say if we would like to compute, say, A B⁻¹ , then the user has to explicitly transpose the explicitly transposed equation to avoid using an explicit  inv whose use should be discouraged anyways:
 x = scipy.linalg.solve(B.T,A.T).T
Since expert drivers come with a trans switch that can internally handle whether to solve the transposed or the regular equation, together with a low-level implicit transpose operation this can be handled rather more elegantly. These routines only avoid the A.T off-the-shelf.

There will be a a few phases for this PR to come to fruition and I would really appreciate all the feedback from the wizards.

[x] Make sure the f2py interface is correct.
[x] Make sure that the input-output arguments are handled correctly.
[x] Make sure that the varying number of I/O arguments are not exposed to the user and the decision tree should not lead to confusion. In other words, if out of inexperience a user selects two conflicting keyword arguments (as it is extremely easy to fall into those traps) the behavior should be unambiguous override or err out directly.
[ ] Make sure that the tests cover sufficient examples
[x] Decide on the numerical bound formula to accept numerical singularity
[ ]  Decide on where this functionality goes into, existing sp.linalg.solve as an addition or a standalone solver and so on.

Example use-case, with warning
import numpy as np
import scipy.linalg as la
A = np.array([[1,2,3],[4,5,6],[7,8,9]],dtype=float)
b = np.array([[15,15,15]]).T
la.solve_x(A,b)

/usr/local/lib/python3.5/dist-packages/scipy/linalg/basic.py:224:
RuntimeWarning: Ill-conditioned matrix detected.
Result is not guaranteed to be accurate.
Reciprocal condition number: 1.5419764230904951e-18

array([[-39.],
       [ 63.],
       [-24.]])

Here are the speed comparison calling directly sp.linalg.lapack.dgesvx(A,B) and sp.linalg.lapack.dgesv(A,B) with
A = np.random.rand(n, n)
B = np.random.rand(n, 3)

horizontal axis is n and vertical axis is seconds in the first one. In the second it's just the ratio of two curves. The numbers are averages of 25 runs for each n. (The blue one is the current DGESV and the other one is the proposed DGESVX)

Finally got around to looking at this...
Since we get better accuracy and warnings about ill conditioned matrices, I'm +1 for using dgesvx in solve. (Might be good to come up with an example that highlights the accuracy gains.) I like the keyword that lets the user specify the structure of the matrix, though I'm not sure how to insert it into solve in a backwards-compatible way.

My vote, for what is worth, goes for deprecating the sym_pos keyword as it should probably have never been there in the first place in such a wide-use generic function. In the meantime sym_pos can point to assume_a='pos' internally during the deprecation period and eventually removed. This would allow future additions rather convenient as the API would stay fixed but possible options can be increased.
lower is picked up as is and it would be still backwards-compatible.
The debug keyword is there but I don't know for which reason it is there since it only prints the overwrite keywords.

The unfortunate thing is that this would require putting assume_a last so as to not break existing code, which is not where it should be...
Might be cleaner to have solve_x, deprecate solve, and then make solve_x become solve in 1.0?

Oh for that, I think I am not qualified to make a decision since you guys have been dealing with all kinds of user reported issues. I don't feel like I have the necessary experience about the releases.

Might be cleaner to have solve_x, deprecate solve, and then make solve_x become solve in 1.0?

Can't really do that, both because the time for deprecation would be much too short and (more importantly) because we don't want to change API/behavior like that. Adding a new function and deprecating the old one is fine, but then renaming new -> old is not.

So something like changing the signature to solve(a, b, sym_pos=False, ..., assume_a='gen'), deprecating sym_pos, and then eventually changing it to solve(a, b, assume_a='gen') would be out too?

I would like to ping this for a gentle reminder. Could you please maybe add needs-decision tag to draw attention of others too?
If we decide to continue with this I'll start adding more tests. Otherwise, well, tough luck! 😁

So something like changing the signature to solve(a, b, sym_pos=False, ..., assume_a='gen'), deprecating sym_pos, and then eventually changing it to solve(a, b, assume_a='gen') would be out too?

I'm afraid so.
This PR has signature:
def solve_x(a, b, assume_a='gen', transposed=False, lower=False,
            overwrite_a=False, overwrite_b=False, check_finite=True):

The current signature for solve is:
def solve(a, b, sym_pos=False, lower=False, overwrite_a=False,
          overwrite_b=False, debug=False, check_finite=True):

So we have a debug keyword now that's ugly, and a sym_pos one that's suboptimal but with functionality that will still be useful (because it's equivalent to assume_a='pos'.
The difference between the optimal signature and
def solve(a, b, sym_pos=False, lower=False, overwrite_a=False,
          overwrite_b=False, debug=False, check_finite=True, assume_a='gen'):

is imho not worth breaking backwards compat for or deprecating solve in favor of a new name.
Any other opinions?

If we decide to continue with this I'll start adding more tests

@ilayn I think we're agreed on that this is a good addition, so go ahead with adding tests I'd say. The signature we'll be able to work out.

Just to second what @rgommers already said--definitely +1 on the addition. Kept meaning to respond but then got caught up thinking about the API...

OK, clear then. Could you also please consider whether the name is a proper one? solve_x sounds a bit cheesy and science fiction-ish... (I'm really trying hard not to make a Sci-Fy pun).

Could you also please consider whether the name is a proper one?

I think we're in favor of replacing solve with solve_x by adding the assume_a keyword to the end of the signature of solve? @rgommers?

I think we're in favor of replacing solve with solve_x by adding the assume_a keyword to the end of the signature of solve? @rgommers?

Agreed. Let's consider that decided unless someone disagrees within the next 24 hours.

I've found another discrepancy in the behaviors of both and a bug.
sp.linalg.solve(1,[1, 2, 3])          # it gives *matrix not square error*.
sp.linalg.solve([[1]], [1, 2, 3]      # then it errs with size mismatch.
sp.linalg.solve(np.eye(3), [1,2,3])   # is valid and result still 1D array. should have complained

In the last case, the result can still survive the matrix multiplications and similar ops thanks to the fact that .dot() treats 1D arrays as inner products. However this fails when you assign the result to a slice with broadcasting for example:
x_1d = np.array([1,2,3,4])
x_2d = np.array([[1,2,3,4]]).T
zzz = np.zeros((4,3))
zzz[:, [1,2]] = x_2d # This works with broadcasting
zzz[:, [1,2]] = x_1d # This gives ValueError shape mismatch:

So should we fix the scalar bug and pretend this never happened or should we return a 2D array result compatible with shape of a?
For what its worth this behavior is not optimal and I'm not sure whether this is a good thing from the 1D arrays are numpy's way of working point of view. As a person who constantly fights with 1D array mayhem not fitting anywhere, I think this is not a good behavior but since nobody seems to be bothered with it, I don't have a strong stance.

All green except some thread safety test and I think I've addressed all issues as far as I understand. So I think this is ready for review.
I will try to see what that failing test is. Didn't see why it fails yet.

Is it possible that I have to add threadsafe (in one of the f2py sigs) somewhere to make it pass?

Is there anyone who can replicate this error? It doesn't happen on my virtual machines unfortunately.

Have you tried spinning up a Travis-like virtualbox image using Ubuntu 12.04. For other details you can look here:
https://docs.travis-ci.com/user/ci-environment/
And then follow the Travis build setup. It's a bit annoying to try, but it might be worth it if you want to replicate the error.

@Eric89GXL Indeed, that's what I have tried to do on a VM but still no luck yet. I am not sure what the test is supposed to be testing. I'll just add threadsafe to everything and see whether the problem goes away.

@pv I see that you have committed also to this file, could you please have a look at it when you have time?

OK sporadic addition of threadsafe keyword in the LAPACK routines solved the issue.

Pinging for a gentle reminder about this

I think otherwise this looks fine, and we want it to work like this, so removing the needs-decision flag.

@pv Do you have any opinion why threadsafe actually mattered here ?

My guess is that adding threadsafe did not actually matter, it just re-ran the test. The test is timing based with 10ms delays, so it's possible to get sporadic failure with bad luck, which I think occurred here.
On the other hand, the LAPACK routines should be threadsafe, so there's no issue adding the statement --- and it can be beneficial. I don't recall exactly what it does, but maybe it releases GIL.

If there are no issues left, I think this is ready.

I'd suggest addin a for loop over supported dtypes, so that you also test
the float32 variant.
24.12.2016 12.05 "Ilhan Polat"<EMAIL_ADDRESS>kirjoitti:

If there are no issues left, I think this is ready.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/6775#issuecomment-269077961, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AACI5tNZIKEZ5f-2pgAIyQETY7OVu05Qks5rLO5IgaJpZM4KuyMt
.

@pv Which test do you have in mind?

Enough to cover all the lapack routine variants (sy/po/he/ge).
I also note that the tests added here many contain hardcoded matrices. It probably is more concise to use random matrices instead, and test the solution satisfies assert_allclose(a.dot(x) - b, 0, atol=...), as I guess the tests are probably mostly smoketests  rather than checking eg forward vs. backward error.
It also cam be preferable to avoid code duplication in the test by using for loops eg like
sizes = [...]
assume_as = ['gen', 'sym', 'pos', 'her']
dtypes = [np.float32, np.float64, np.complex64, np.complex128]
for size, assume_a, dtype in itertools.product(sizes, assume_as, dtypes):
    is_complex = dtype in (np.complex64, np.complex128)
    if assume_a == 'her' and not is_complex:
        continue

    err_msg = "{} {} {}".format(size, assume_a, dtype)

    a = np.random.randn(size, size).astype(dtype)
    b = np.random.randn(size).astype(dtype)
    if is_complex:
        a = a + (1j*np.random.randn(size, size)).astype(dtype)

    if assume_a in ('sym', 'her'):
        a = a + a.T.conj()
    elif assume_a == 'pos':
        a = a.dot(a)

    ...
    assert_allclose(a.dot(x), b, atol=1e-12, rtol=1e-12, err_msg=err_msg)

etc

Thanks @pv. Added those and a few trivial ones for codecov.
Regarding the hardcoded tests, I've left them as is to see whether it is in accordance with the old version of solve (1D array shapes and empty array behavior etc.) If this goes through we can later reorganize the tests and make them more to the point and concise.

happy new year ping :)

happy new year ping :)

Typically, this is only done when it is needed to avoid shadowing.
Otherwise, it is not standard practice in scipy.
2.1.2017 1.58 "Ilhan Polat"<EMAIL_ADDRESS>kirjoitti:

@ilayn commented on this pull request.
In scipy/linalg/tests/test_basic.py
https://github.com/scipy/scipy/pull/6775:

       err_msg = ("Failed for size: {}, assume_a: {},"

                  "dtype: {}".format(size, assume_a, dtype_))

       a = np.random.randn(size, size).astype(dtype_)

       b = np.random.randn(size).astype(dtype_)

       if is_complex:

           a = a + (1j*np.random.randn(size, size)).astype(dtype_)

       if assume_a in ('sym', 'her'):

           a = a + a.T.conj()

       elif assume_a == 'pos':

           a = a.conj().T.dot(a) + 0.1*np.eye(size)

       x = solve(a, b)

       tol_ = 1e-12 if dtype_ in (np.float64, np.complex128) else 1e-5

Just to distinguish variables from the signature keywords with standard
python practice
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/scipy/scipy/pull/6775, or mute the thread
https://github.com/notifications/unsubscribe-auth/AACI5tjpQWkhpR18M1EzfMuqQjYPZ2Ntks5rOD2AgaJpZM4KuyMt
.

I think all comments are addressed. Let me know if anything else is needed.

@pv I see your comments but singe merged I don't know how to address them. Should I open a new PR for those and the debug keyword removal discussion ?

Yes, you can open a new PR for those. The PR for the debug keyword should also be separate, so that each PR is focused only on a single topic.


Prompt to rename root node of newly created scene

Fixes https://github.com/godotengine/godot-proposals/issues/9245
Draft because the textbox is misaligned from the actual tree node. Even using call_deferred did not fix it 🤷

Draft because the textbox is misaligned from the actual tree node. Even using call_deferred did not fix it 🤷

"Tree" is my name, "bug" is my game.

Closing as per the proposal.


Can BatchDecodeWithPaddedKVCache be used in cascade inference?

Currently the implementation of cascade inference is two level, composed of SinglePrefillWithKVCache(or SingleDecodeWithKVCache) and BatchPrefillWithPagedKVCacheWrapper (or BatchDecodeWithPagedKVCacheWrapper).  I wonder if the batch prefill or decode attention without paged attention can be used in cascade inference?

Yes I do think so, there are some test cases https://github.com/flashinfer-ai/flashinfer/blob/7e9cc7ff42ca283c317061a877305d09a395fad2/python/tests/test_shared_prefix_kernels.py#L33-L53

Padded KV-Cache is deprecated in https://github.com/flashinfer-ai/flashinfer/releases/tag/v0.0.7.
For cascade inference, it's encouraged to use the new MultiLevelCascadeAttentionWrapper API introduced in https://github.com/flashinfer-ai/flashinfer/releases/tag/v0.1.6


missing toml configs for .xml properties in user-mgt.xml file

The following prorperties in user-mgt.xml file, need their toml equivalent  in doc (1) and (2).
In configuring the authorization manager (refer doc(1))
-dataSource
-isCascadeDeleteEnabled
-testOnBorrow
<AuthorizationManager class=""org.wso2.carbon.user.core.authorization.JDBCAuthorizationManager"">
        <Property name=""AdminRoleManagementPermissions"">/permission</Property>
        <Property name=""AuthorizationCacheEnabled"">true</Property>
       <Property name=""GetAllRolesOfUserEnabled"">false</Property>
 </AuthorizationManager>

<Property name=""CaseSensitiveAuthorizationRules"">true</Property>"
In configuring the system administrator (refer doc(2))
<Realm>
  <Configuration>
   <AddAdmin>true</AddAdmin>
   <AdminRole>admin</AdminRole>
   <AdminUser>
       <UserName>admin</UserName>
       <Password>admin</Password>
   </AdminUser>
   <EveryOneRoleName>everyone</EveryOneRoleName> <!-- By default users in this role see the registry root -->
   <Property name=""""></Property>
   ...............
  </Configuration>
...
</Realm>

[1]https://docs.wso2.com/display/IS580/Configuring+the+Authorization+Manager
[2]https://docs.wso2.com/display/IS580/Configuring+the+System+Administrator

This issue is being closed due to extended inactivity. Please feel free to reopen it if further attention is needed. Thank you for helping us keep the issue list relevant and focused!


Change default values for Layout Mode

Hi! Great package. I'm starting to inspect it and it looks promising.
Is it possible to set a parameter so the Layout Mode is set to Container by default?
Thanks.

For Graphic Walker, we should add configuration parameters to control default settings (such as layout mode, stack mode, and aggregation method).
For GWalkR and PyGWalker, particularly in RStudio or Jupyter Notebook environments, it would be more user-friendly to read these settings from global configuration files rather than passing them as parameters. This approach would keep the function calls as clean and simple as possible.
I'll create a task ticket for Graphic Walker with a two-week deadline. Once completed, we can update GWalkR to use the new configuration features from Graphic Walker.

@bruceyyu you can pass the defaultConfig prop to GraphicWalker to set the default settings.
it contains same data as config and layout settings in spec.
In this case, you can use
{
    "layout": {
        "size": {
            "mode": "full",
            "width": 384,
            "height": 256
        }
    }
}

to set the default layout mode to container.


[Feature] Analyze statement support optional sync/async

What type of PR is this：

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

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

Checklist:

[ ] I have added test cases for my bug fix or my new feature
[ ] I have added user document for my new feature or new function

[FE PR Coverage Check]
:disappointed: fail : 7 / 28 (25.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/StmtExecutor.java
0
21
00.00%
[827, 829, 830, 831, 832, 833, 834, 835, 836, 838, 852, 853, 854, 855, 857, 862, 863, 864, 865, 867, 872]

:large_blue_circle:
com/starrocks/sql/parser/AstBuilder.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/sql/ast/AnalyzeStmt.java
2
2
100.00%
[]

[FE PR Coverage Check]
:disappointed: fail : 7 / 28 (25.00%)
file detail

path
covered_line
new_line
coverage
not_covered_line_detail

:large_blue_circle:
com/starrocks/qe/StmtExecutor.java
0
21
00.00%
[827, 829, 830, 831, 832, 833, 834, 835, 836, 838, 852, 853, 854, 855, 857, 862, 863, 864, 865, 867, 872]

:large_blue_circle:
com/starrocks/sql/parser/AstBuilder.java
5
5
100.00%
[]

:large_blue_circle:
com/starrocks/sql/ast/AnalyzeStmt.java
2
2
100.00%
[]

run starrocks_admit_test


just.library('http') return undefined (windows10 wsl2 ubuntu)

const { http } = just.library('http')
just.print("hello")
just.print(just.memoryUsage().rss)
just.print(http)
Terminal:
hello
10129408
undefined

i need to bring docs up to date. to start from the beginning this should work:
wget https://github.com/just-js/just/archive/refs/tags/current.tar.gz
tar -zxvf current.tar.gz
cd just-current/
# this will download the modules into current directory
make modules
# build the just runtime
make runtime
# install the runtime to /usr/local/bin/just
sudo make install
# build the http module
MODULE=http make module
# install the http module to /usr/local/lib/just
sudo make -C modules/http install

and repeat the last two steps for any other modules you want to use. it used to throw an error when a shared library wasn't found but don't currently. i might change that.
let me know if this works for you. if not, we should be able to figure it out. would be interested to know if it all works on wsl2.

it worked perfectly, thank you

it worked perfectly, thank you

great! glad it is working as expected on wsl2. there is a bash script to build all the modules also. you might want to leave out rocksdb if you don't plan on using it as it takes ages to build.

hi,
in modules/build.sh very errors:
In file included from blake3.cc:1: blake3.h:4:10: fatal error: just.h: No such file or directory     4 | #include "just.h"
if I change to: "../../just.h"
then:
../../just.h:4:10: fatal error: v8.h: No such file or directory     4 | #include <v8.h>
and so on...
I didn't get it with docker either
sorry about my English.
Everton
Em Ter 01/03/22 00:10, Andrew Johnston @.*** escreveu:

it worked perfectly, thank you
great! glad it is working as expected on wsl2. there is a bash script to build all the modules also. you might want to leave out rocksdb if you don't plan on using it as it takes ages to build.
—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you authored the thread.Message ID: @.***>

@Everton-Sales ah yes, missing documentation again... i have lots of work to do!
if you look here you can see the modules expect and environment variable set for JUST_HOME. this should point to the "just-current" directory i referred to above (where you downloaded, extracted and built the just runtime). so if that directory is /home/everton/just-current then run this
export JUST_HOME=/home/everton/just-current
cd /home/everton/just-current/modules
./build.sh

hi,
ok, including  export PATH=$PATH:JUST_HOME :-)
Errors:
In file included from ffi.cc:1:
ffi_just.h:5:10: fatal error: ffi.h: No such file or directory
5 | #include <ffi.h>
In file included from ../../src/include/postgres.h:47,
from chklocale.c:17:
../../src/include/utils/elog.h:71:10: fatal error: utils/errcodes.h: No such file or directory
71 | #include "utils/errcodes.h"

2 warnings:

ip.cc:145:24: warning: variable ‘buf’ set but not used [-Wunused-but-set-variable]
145 |     Local buf = args[3].As();
signing.cc:220:7: warning: variable ‘r’ set but not used [-Wunused-but-set-variable]
220 |   int r = X509_REQ_set_version(x509_req, 0);

yup. ffi is broken because you need to install libffi
apt install -y libffi-dev

and postgres library, for some reason i haven't had time to figure out yet, always fails when built from the makefile. this library is pretty incomplete and there is a different, pure-JS postgres client library that works better, but if you want to fix this and get it working, this should do the trick:
cd modules/pg
cd deps/postgresql-12.3/
make -C src/bin
make -C src/include
make -C src/interfaces/
cd ../..
make clean library
sudo make install

hi,
ok, including  export PATH=$PATH:JUST_HOME :-)
Errors:
In file included from ffi.cc:1:
ffi_just.h:5:10: fatal error: ffi.h: No such file or directory
5 | #include <ffi.h>
In file included from ../../src/include/postgres.h:47,
from chklocale.c:17:
../../src/include/utils/elog.h:71:10: fatal error: utils/errcodes.h: No such file or directory
71 | #include "utils/errcodes.h"

2 warnings:

ip.cc:145:24: warning: variable ‘buf’ set but not used [-Wunused-but-set-variable]
145 |     Local buf = args[3].As();
signing.cc:220:7: warning: variable ‘r’ set but not used [-Wunused-but-set-variable]
220 |   int r = X509_REQ_set_version(x509_req, 0);

hi, in WSL I found a problem with $PATH, other than echo $PATH and the ./build.sh inside "modules" didn't work. I managed to solve it by copying the ./build.sh to the folder above (just or just-current) and modifying it like this:
#!/bin/bash
MODULES=${2:-"blake3 encode epoll ffi fs html http inspector io ip jkvm memory net openssl  profiler seccomp sha1 signal sqlite sys tcc thread udp vm zlib"}
for m in $MODULES
do
MODULE=$m make module
make -C modules/$m install
done

you should inform in the README.md, in "Build and Run" the g++ dependency:
sudo apt instal g++


vxWorks: use rtpInfoGet() to get rtp executable path

r? @n-salim

Do you think it is a good idea to introduce a new function in vxWorks that just return rtp executable path? and if we name the new function as "getexecname", we even don't need to add any code in this file.

That function is currently only standard on Solaris apparently. Adding it on VxWorks would require handling concurrent calls properly so it's not entirely trivial, i.e. it might be better to just solve it in Rust.
I think there are two parts.

Get the name
Store it in a static location

For (1) you can use the existing code. For (2) you can use copy_from_slice. So something like (based on the Windows code):
unsafe fn load_filename() -> *const libc::c_char {
    use libc;
    use core::mem;

    const N: usize = libc::VX_RTP_NAME_LENGTH + 1;
    static mut BUF: [i8; N] = [0; N];

    let mut rtp_desc : libc::RTP_DESC = mem::zeroed();
    if (libc::rtpInfoGet(0, &mut rtp_desc as *mut libc::RTP_DESC) == 0) {
        BUF.copy_from_slice(&rtp_desc.pathName);
        BUF.as_ptr()
    } else {
        ptr::null()
    }
}

BTW there is also an std::env::current_exe function that should have a similar implementation. Currently we define it to (effectively) argv[0], which is overly simplistic, because e.g. if
PATH=/somedir:/romfs
argv[0] = "hello.vxe"

then the actual executable path might be /romfs/hello.vxe.
I think we should change std::env::current_exe to call rtpInfoGet. In this case we return a Rust string so we don't have to muck around with static variables.
Unfortunately we can't define load_filename in terms of std::env::current_exe because apparently backtrace is not allowed to depend on std.

@n-salim
Thanks for the example code, I have updated the code.


Dconf updater error log support

While its functionality is great, it's the matter of time when some dconf value stops working.
System & apps can get update any time, which would prevent custom configuration working.
I propose some solution to have error logging for non-working dconfs & when dconf-updater is prevented in writing the modified values. Possibly, by reading starting values with "dconf read" & comparing that to the end output. If some part of the output is unchanged from the starting values, fail then inform the user through error log.
This way, we will know which dconf values should be corrected in the future.

There is a solution:
Main info
Another way of applying system-wide changes in build-time other than using dconf is to use:

Gschema override

What is the advantage of gschema override?

it's a cleaner implementation which doesn't alter dconf database
it doesn't rely on post-setup systemd service for updating its settings
it supports useful logs for troubleshooting (warning if schema is depreciated, warning if schema key is no longer valid)
it's a solution which most major distributions use for deploying modified system-wide settings
you only need to make 1 file for changes compared to making dconf profile & dconf keyfile

What it lacks compared to dconf?

locking settings support

relocatable schemas support (used for making & populating folders f.e.)
in dconf, relocatable schema appears like a classic schema:
/org/gnome/desktop/app-folders/folders/Utilities
in gsettings, it appears like this:
org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Utilities/
Rare amount of options are like this, so most maintainers will avoid it successfully.

How to use those?
Gschema overrides have very similar format to dconfs with some little differences.
Gschema uses gsettings backend which uses . format instead of dconf's / for schema locations.
While dconf relies on dconf-updater service, gschema override relies on simple command for recompiling gschemas, which is done in build-time as a script after gschema override is placed (this is where useful logs are printed):
glib-compile-schemas /usr/share/glib-2.0/schemas
Gschema override is placed in this location:
/usr/share/glib-2.0/schemas
It can be named like this:
01-mysettings.gschema.override
It can be also named without a number:
mysettings.gschema.override
It is important to pick the name of gschema, which will assure that it won't get bypassed by other gschemas.
Alphabetical naming has advantage compared to numerical you seen in example above:
00-99 (99 takes advantage)
a-z (z takes advantage)
So, if you name your gschema like this, you will be assured it will always work:
zz-mysettings.gschema.override
What can you do to have all these advantages?
Use gschema overrides as much as possible, use dconf-updater only for setting locks & unsupported gschema override settings.


[1.10 RFToolsDimensions] version rftoolsdim-1.10-4.30beta46.jar "Wrong Version error"

I have added this mod into the modpack FTB Unstable 1.10 and every time I start up the game the console states that rftoolsdim-1.10-4.30beta46.jar is asking for a version other than 1.10. This issue happens every time until I remove rftoolsdim-1.10-4.30beta46.jar from the mods folder.
this is the log from the folder: http://pastebin.com/Nj7TzgPB
this is the log from the FTB console: http://pastebin.com/ayxSYLVV

Is this still happening after updating all the mods? I cannot reproduce this at all


New Crowdin updates

Netlify is broken (404 on homepage)
@pierreboc @cdeleeuwe -> can you give a look?

@cdeleeuwe the build is green (sometimes), but the homepage is 404
we should add a CI test that checks that some pages are not 404:

/home (home)
/fr/home (translated home)
/news (the news category)
/news/1 (a news)
etc

@cdeleeuwe the build is green (sometimes), but the homepage is 404
we should add a CI test that checks that some pages are not 404:

/home (home)
/fr/home (translated home)
/news (the news category)
/news/1 (a news)
etc

@moul I just made a PR #308 which checks if all files referenced in the sitemap are generated. If not, it should fail the build.

Ok Nice! it's just merged; ill close this PR to let Crowdin trigger a new one


Option to ignore fields which are not annotated

Most of the time, my json classes have many fields which have nothing to do with json. If I do not add @JsonKey(ignore: true) to them, they will be null after deserialization.
It would be really useful to have an option in JsonSerializable to only use fields which are explicitly annotated with @JsonKey

Could you provide an example?

test.dart:
import 'package:json_annotation/json_annotation.dart';

part 'test.g.dart';

@JsonSerializable(createToJson: false)
class TestJsonModel {
  @JsonKey(name: "myName")
  String onlyJsonField;

  int status = 5;

  String note = "This is not a json field";

  bool edited = false;

  static TestJsonModel fromJson(Map<String, dynamic> json) {
    return _$TestJsonModelFromJson(json);
  }
}

test.g.dart:
// GENERATED CODE - DO NOT MODIFY BY HAND

part of 'test.dart';

// **************************************************************************
// JsonSerializableGenerator
// **************************************************************************

TestJsonModel _$TestJsonModelFromJson(Map<String, dynamic> json) {
  return TestJsonModel()
    ..onlyJsonField = json['myName'] as String
    ..status = json['status'] as int
    ..note = json['note'] as String
    ..edited = json['edited'] as bool;
}

The fields "status", "note" and "edited" are not from json but used by the app. This is why they should neither be serialized nor parsed.
But I didn't add @JsonKey(ignore: true) so they will be null after deserialization.
It would be helpful to set @JsonSerializable(createToJson: false, onlyUseAnnotated: true) so json_serializable only considers annotaded fields.

Ah! That should be doable, in theory, but I worry about the added complexity. Will ponder...

Yes, please. A way to whitelist would be very useful for introducing persistence to classes.

Turns out this is pretty easy to implement. PR in flight...

Thank you! :+1:


Fix unit test error in jetcd

What is the purpose of the change

upgrade jectd version to adapt new version of netty
upgrade grpc version to adatp new version of jetcd
fix ASF header in dubbo-registry-dns pom file

Ci failed on jdk 11 because of some environment-related issues.


Offsets are not generating

On a dump, offset files are not found in generated folder.

Make sure config is in the folder like the binary.


Supplement as main identifier

@ronaldtse what do you think?
But I didn't remove backward compatibility, still possible to add supplements to main identifier.
closes #130

Thank you @mico !


Fix TimeoutException: Future timed out after [30 seconds] on BlazeClient213Suite testing

Fix TimeoutException: Future timed out after [30 seconds] on BlazeClient213Suite testing
I usually get the following failures when I run the tests locally.

BlazeClient213Suite.behave and not deadlock on failures with parTraverse
BlazeClient213Suite.Blaze Http1Client should behave and not deadlock on failures with parSequence

fail with TimeoutException: Future timed out after [30 seconds], this PR may fix it.

Are we sure this won't be flaky again at a 50-second timeout?  We never got to the bottom of what locks it up.

@rossabaker I tested about 20 times and never had any issues once I put that 50 second timeout.
Just in case, let me have more tests on it.

Also I'll create a PR to the main once the test is done and if I'm confident this solves the issue.

Alright, we can give it a shot, and always reflag them as flaky if they don't work.

Drat: https://github.com/http4s/http4s/pull/4864/checks?check_run_id=2642699996


Kubernetes 组件

On the page https://kubernetes.io/zh/docs/concepts/overview/components/
it seems that the comment of the term service mentioned in the part of kube-proxy is inappropriately shown considering the following html code.
data-original-title="将运行在一组 {{< glossary_tooltip text="Pods" term_id="pod" >}} 上的应用程序公开为网络服务的抽象方法。"
So basically the code here may be replaced with
data-original-title="将运行在一组Pods上的应用程序公开为网络服务的抽象方法。"
according to the code above and the English version
data-original-title="A way to expose an application running on a set of Pods as a network service.".

/language zh

Looks like this has been fixed.
/close


[build] Fix up test_rom / flash_ctrl deps

Missed adding these.

Handles merge skew between #11907 and #12081

since the head of tree software build is broken, merge this now after software build is fixed.


IDs in PDF output overlaps with contents

IDs in PDF output overlaps with contents.
Low Prio

I think this issue is PDF-related and Sphinx-Needs can not do much here (as it only uses the standard docutils nodes.)
I would say this can be fixed by using https://github.com/useblocks/sphinx-simplepdf and maybe providing a custom.css


Reset via API

I'm having an issue w/ my powerwall that it stops discharging during the evening.  It goes from 100% to 70-80% and then goes into standby.  The only way i've found to kick it into discharging again is to do a reset on the gateway.
I'm looking for a way to do that via the API and I am not finding one that works via the APIs that have been documented so far.  The most promising one is /solar_powerwall/reset, but it requires a POST with a JSON payload and I'm not sure what it takes.
When sending no valid payload, i get:
{
"code": 400,
"error": "unexpected end of JSON input",
"message": "Unable to unmarshal body"
}
I dont' want ot keep going out there every night and resetting manually so wondering if anyone has found a way to do the same type of "reset" that you do on the gateway via the api (or any other automated mechanism.
Thanks

hmm, have you tried contacting Tesla support about the issue?
<EMAIL_ADDRESS>


Python: Added metadata specifying connection stems from MSK code

Motivation and Context

Description

MongoDB drivers are used in various flavors and languages. Making sure we exercise our due diligence in identifying the "origin" of the library calls makes it best to understand how our Atlas servers get accessed.
Additionally, bumped the motor version to 3.3.2 to support the DriverInfo tracking behavior.

Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

Hi @Jibola, is this work still needed? I am closing this PR as there has been no action since Dec 2023. If the work is still required, please re-open it with any required changes after pulling in main. Thank you.

Hi @Jibola, is this work still needed? I am closing this PR as there has been no action since Dec 2023. If the work is still required, please re-open it with any required changes after pulling in main. Thank you.

Hi, it is ready. I've actually been waiting for review on the PR. I'll re-open.


demultiplexing fails after Config

Hello!
I am trying to run the demultiplexing workflow but am running into the following error in the Job Manager:

The workflow seems to fail immediately following the Config task and can't seem to see an empty pooling_ids variable. I am using this workflow only for cell-hashing data, so I shouldn't have any genetic pooling information. My sample-sheet and input json are attached as well.
Thanks!
cumulus_naive_sample_sheet_demux.csv
demultiplexing_inputs.json.txt

Hello @majorkazer ,
This is a known issue which has been resolved in pull request #201 . However, since we are working on workflow inputs changes, we haven't updated demultiplexing workflow snapshot.
I just updated it, and please use snapshot 32 to see if the issue goes away.
Sincerely,
Yiming

Hi @yihming,
Thanks for updating the workflow snapshot! Everything seems to be working now.
Best,
Sam


Decouple minio from minio-client

origianlly posted by @zhenik https://github.com/fredrikhgrelland/terraform-nomad-minio/pull/27#discussion_r496524224
Why?

Intentions are not automated when consul_acl_default_policy=deny (User must do it explicitly between mc=> minio)
Batch job does not healthcheck (in failure case -> retries -> retries limit reached -> job dead), (in success -> job dead)
Infrastructure and Provisioning tasks  have common context (coupled, mixed)

Why not

bucker creation from the box

#37 duplicaate


No folder picker on Android

Thanks for all your effort.  This is referring to all the little web apps you provide in your rep (ffmpeg, duplicate checker, etc.). Everything's working fine so far, apart from those functions that are supposed to open folders/folder view. Picking files from the file picker is no problem, but opening folders is impossible on my Samsung device since I would never get the actual folder picker, but always the file picker as well. When trying to open a folder it would consequently launch the file picker with no option to actually select the folder I'm in. Basically, I'm stuck in the picker view, only being able to return to browser by using the phones "back" button or by selecting a file. I suppose it needs updating the picker function to open the dedicated folder picker (which looks identical and just differs from the file picker in that it would display a "select" option when inside a folder). Am I really the only one getting this?
Edit: almost forgot to tell my browser - I'm using Brave Browser which as you surely know is Chromium-based, but it doesn't stop the application telling me to get a Chromium Browser. It seems the app doesn't recognize Brave, even with the default Brave User Agent applied.

Hello! First of all, thank you so much! I'm happy that you like these tools
The folder picker unfortunately is currently unsupported on all browsers on Android. However, it seems that the Chromium team is working on bringing the File System API on Android, so I hope that, with this addition, we'll be able to access to folders directly.
While I'll wait for this API to be deployed in the future versions of Chrome on Android, I'll look if other native solutions are possible

On the latest version of Chrome Canary, the folder picker is implemented, however it crashes after picking files. There's still no support for the File System API, so it's only possible to read the folder, and not to write into it. However, it's still a great step forward
https://github.com/user-attachments/assets/fb889810-06f4-4875-b51e-7183acea45fb

Coolio, nice to hear it's at least being worked on. Actually I'm surprised this hasn't been solved long ago, it's equally important as the file picker itself in my opinion.
Regarding the screencast you posted, I don't quite get why the attempt to just,read a file makes the picker crash, although reading allegedly is supported now? Anyway, thanks again for your work!

It's still being worked on, it needs a lot of refinement before shipping on a stable release, but at least they are finally doing it. I agree that this should have been solved a long time ago - there's no reason not to have directory support on mobile browsers


feat: Add config to wrap jump_next and jump_prev

Fixes #139

Slightly cleaner way to wrap jump navigation. Thanks @ben-krieger for the inspiration!


Create JsCalculator.html

Approved. Thanks for your contribution.  Looking forward to read more of your code soon.


Fix chacha20 test

When the data is not block aligned we need a temporary space for storing a chacha20 block. Also, we can no longer assume the destination buffer's .off is zero as this can now be user provided.

thanks, I only saw this now. Is the strategy that we merge https://github.com/mirage/mirage-crypto/pull/203 first? (I suspect we need something similar for the GCM and CCM code paths)

Hmm yes maybe. In https://github.com/mirage/mirage-crypto/pull/203 I suggested a change that is similar to this one.