jinja2.exceptions.TemplateNotFound: alias.html

Describe the bug
While running mkdocs build I get an exception:
$ mkdocs build
INFO     -  Cleaning site directory
INFO     -  Building documentation to directory: C:\Users\lameg\kubekind\site
WARNING  -  mkdocstrings_handlers: 1 aliases were still unresolved after 2 iterations
ERROR    -  mkdocstrings: Template 'alias.html' not found for 'python' handler and theme 'material'.
ERROR    -  Error reading page 'index.md': alias.html
Traceback (most recent call last):
  File "C:\Users\lameg\miniforge3\lib\runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "C:\Users\lameg\miniforge3\lib\runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "C:\Users\lameg\miniforge3\Scripts\mkdocs.exe\__main__.py", line 7, in <module>
  File "C:\Users\lameg\miniforge3\lib\site-packages\click\core.py", line 1137, in __call__
    return self.main(*args, **kwargs)
  File "C:\Users\lameg\miniforge3\lib\site-packages\click\core.py", line 1062, in main
    rv = self.invoke(ctx)
  File "C:\Users\lameg\miniforge3\lib\site-packages\click\core.py", line 1668, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "C:\Users\lameg\miniforge3\lib\site-packages\click\core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "C:\Users\lameg\miniforge3\lib\site-packages\click\core.py", line 763, in invoke
    return __callback(*args, **kwargs)
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocs\__main__.py", line 192, in build_command
    build.build(config.load_config(**kwargs), dirty=not clean)
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocs\commands\build.py", line 292, in build
    _populate_page(file.page, config, files, dirty)
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocs\commands\build.py", line 174, in _populate_page
    page.render(config, files)
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocs\structure\pages.py", line 175, in render
    self.content = md.convert(self.markdown)
  File "C:\Users\lameg\miniforge3\lib\site-packages\markdown\core.py", line 264, in convert
    root = self.parser.parseDocument(self.lines).getroot()
  File "C:\Users\lameg\miniforge3\lib\site-packages\markdown\blockparser.py", line 90, in parseDocument
    self.parseChunk(self.root, '\n'.join(lines))
  File "C:\Users\lameg\miniforge3\lib\site-packages\markdown\blockparser.py", line 105, in parseChunk
    self.parseBlocks(parent, text.split('\n\n'))
  File "C:\Users\lameg\miniforge3\lib\site-packages\markdown\blockparser.py", line 123, in parseBlocks
    if processor.run(parent, blocks) is not False:
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocstrings\extension.py", line 121, in run
    html, handler, data = self._process_block(identifier, block, heading_level)
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocstrings\extension.py", line 209, in _process_block
    rendered = handler.render(data, options)
  File "C:\Users\lameg\miniforge3\lib\site-packages\mkdocstrings_handlers\python\handler.py", line 215, in render
    template = self.env.get_template(f"{data.kind.value}.html")
  File "C:\Users\lameg\miniforge3\lib\site-packages\jinja2\environment.py", line 1010, in get_template
    return self._load_template(name, globals)
  File "C:\Users\lameg\miniforge3\lib\site-packages\jinja2\environment.py", line 969, in _load_template
    template = self.loader.load(self, name, self.make_globals(globals))
  File "C:\Users\lameg\miniforge3\lib\site-packages\jinja2\loaders.py", line 126, in load
    source, filename, uptodate = self.get_source(environment, name)
  File "C:\Users\lameg\miniforge3\lib\site-packages\jinja2\loaders.py", line 218, in get_source
    raise TemplateNotFound(template)
jinja2.exceptions.TemplateNotFound: alias.html

To Reproduce
Steps to reproduce the behavior:
git clone git@github.com:joaompinto/kubekind.git
cd kubekind
pip install mkdocs mkdocstrings mkdocstrings[python]
mkdocs build

Expected behavior
A clear and concise description of what you expected to happen.
Information (please complete the following information):

OS:  Windows 10
mkdocstrings 0.19.0

Same error here, any new ideas?

Ok, could work around this error by NOT using indirect imports (hope this is the correct term)
Lets have an example
/myProj
-__init__.py
    -/main
        -__init__.py
        -main.py
    -/sub1
        -__init__.py
        -sub1.py <-- "sub1Class" in here

content of /myProj/main/__init__.py
from myProj.sub1.sub1 import sub1Class

and in the mkdoc md file i referenced the class as
::: myProj.main.sub1Class
    :docstring:
    :members:

which provoked the error.
when changin the class reference to
::: myProj.sub1.sub1.sub1Class
    :docstring:
    :members:

the error was gone

Sorry for the delay and thank you for the workaround. I'll eventually get to this as it's clearly a bug.

Thanks a lot. i'll try to find some time the next days to setup a simplified project-repo to reproduce the error.

Ok, looks like my claim was wrong. I could NOT reproduce the error via indirect imports.
https://github.com/motey/mkdocstrings-451

hmmm still happening, I arrived here after checking out #404, no solution for now :(

The original issue reported by @joaompinto  seems to happen because __init__.py modules are missing from both resources and storage. The underlying tool, Griffe, considers it an error and skips the modules in these folders (Griffe does not accept namespace packages inside of regular packages).
This is shown by the logs:
% griffe dump kubekind -o/dev/null -LDEBUG
INFO       Loading package kubekind
DEBUG      Found kubekind: loading
DEBUG      Loading path kubekind/__init__.py
DEBUG      Loading path kubekind/kind.py
DEBUG      Loading path kubekind/__main__.py
DEBUG      Skip kubekind/resources/container.py, it is not importable. Missing __init__ module?
DEBUG      Skip kubekind/resources/pod.py, it is not importable. Missing __init__ module?
DEBUG      Skip kubekind/storage/volumemount.py, it is not importable. Missing __init__ module?
DEBUG      Skip kubekind/storage/emptydir.py, it is not importable. Missing __init__ module?
INFO       Finished loading packages

So the easy solution is to add the missing __init__.py modules.
@motey @HacKanCuBa can you confirm the issue is caused by missing __init__.py modules as well on your side?
If not, could you provide a public repository from which I can replicate the issue? Thanks.

mkdocs build -v

Hmmm interesting, I do not see that griffe issue in my log:
...
INFO     -  Cleaning site directory
INFO     -  Building documentation to directory: /home/hackan/Workspace/blake2signer/docs/site
DEBUG    -  An external link to 'https://blake2signer.hackan.net/en/stable/' is included in the
            'nav' configuration.
DEBUG    -  An external link to 'https://blake2signer.hackan.net/en/latest/' is included in the
            'nav' configuration.
DEBUG    -  An external link to 'https://readthedocs.org/projects/blake2signer/' is included in
            the 'nav' configuration.
DEBUG    -  Reading markdown pages.
DEBUG    -  Reading: index.md
DEBUG    -  Running 1 `page_markdown` events
DEBUG    -  Running 1 `page_content` events
DEBUG    -  Reading: bases.md
DEBUG    -  Running 1 `page_markdown` events
DEBUG    -  mkdocstrings: Matched '::: blake2signer.bases.Base'
DEBUG    -  mkdocstrings: Using handler 'python'
DEBUG    -  mkdocstrings: Collecting data
DEBUG    -  griffe: Found blake2signer: loading
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/__init__.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/signers.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/utils.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/interfaces.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/compressors.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/errors.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/encoders.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/bases.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/serializers.py
DEBUG    -  griffe: Loading path /home/hackan/Workspace/blake2signer/blake2signer/mixins.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/hashers/__init__.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/__init__.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/hashers/blake3_package.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/hashers/blakehashers.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/test_hashers.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/test_signer.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/test_serializersigner.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/test_timestampsigner.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/test_utils.py
DEBUG    -  griffe: Loading path
            /home/hackan/Workspace/blake2signer/blake2signer/tests/bases.py
DEBUG    -  griffe: Alias blake2signer.Blake2SerializerSigner was resolved to
            blake2signer.signers.Blake2SerializerSigner
DEBUG    -  griffe: Alias blake2signer.Blake2Signature was resolved to
            blake2signer.signers.Blake2Signature
DEBUG    -  griffe: Alias blake2signer.Blake2SignatureDump was resolved to
            blake2signer.signers.Blake2SignatureDump
DEBUG    -  griffe: Alias blake2signer.Blake2Signer was resolved to
            blake2signer.signers.Blake2Signer
DEBUG    -  griffe: Alias blake2signer.Blake2TimestampSigner was resolved to
            blake2signer.signers.Blake2TimestampSigner
DEBUG    -  griffe: Alias resolution error for blake2signer.hashers.blake3 -> blake3.blake3
DEBUG    -  griffe: Alias blake2signer.hashers.has_blake3 was resolved to
            blake2signer.hashers.blake3_package.has_blake3
DEBUG    -  griffe: Alias blake2signer.hashers.BLAKE2Hasher was resolved to
            blake2signer.hashers.blakehashers.BLAKE2Hasher
DEBUG    -  griffe: Alias blake2signer.hashers.BLAKE3Hasher was resolved to
            blake2signer.hashers.blakehashers.BLAKE3Hasher
DEBUG    -  griffe: Alias blake2signer.hashers.HasherChoice was resolved to
            blake2signer.hashers.blakehashers.HasherChoice
DEBUG    -  griffe: Iteration 1 finished, 9 aliases resolved, still 1 to go
DEBUG    -  griffe: Alias resolution error for blake2signer.hashers.blake3 -> blake3.blake3
DEBUG    -  griffe: Iteration 2 finished, 0 aliases resolved, still 1 to go
WARNING  -  mkdocstrings_handlers: 1 aliases were still unresolved after 2 iterations
DEBUG    -  mkdocstrings: Updating renderer's env
DEBUG    -  mkdocstrings: Rendering templates
...

This is from my open-source project, you can build the docs yourself if needed: https://gitlab.com/hackancuba/blake2signer/

Clone the repo: git clone git@gitlab.com:hackancuba/blake2signer.git
Go into project dir, ignore main project: cd blake2signer
Go into docs subdir: cd docs
Install deps: poetry install (a .venv dir is automatically created locally by Poetry)
Run mkdocs: poetry run mkdocs build -v

Can you try again with Griffe installed from master branch? poetry run pip install git+https://github.com/mkdocstrings/griffe
I've fixed several things, did not get the chance to release yet.

Can you try again with Griffe installed from master branch? poetry run pip install git+https://github.com/mkdocstrings/griffe
I've fixed several things, did not get the chance to release yet.

Interestingly, the log changed a bit, but yet it still throws the warning (or the error when I force it to reference directly the offending file).

So, what's the issue? You don't want the X aliases were still unresolved after N iterations message to be logged as a warning? We can turn it to a DEBUG one :slightly_smiling_face:

haha no, that's not the issue. if i want to show docs for the object in question, it crashes instead of giving a warning (see the second part of my prev comment)

I see, thanks for the explanation! (I'll still change the warning to a debug statement)
So, Griffe does not try to load external packages when resolving aliases. If you want to force it to load blake3, so that you are able to document its objects directly or through aliases (objects from blake3 imported in your own code), you'll have to add at least one autodoc instruction beginning with blake3, for example:
::: blake3.some.small.object
    options:
      shot_root_toc_entry: false

<!-- you can then hide it with something like
<style>.doc-object:has(> #blake3.some.small.object) {display: none;}</style>
-->

I'm planning on adding a configuration option to tell Griffe to (pre)load additional modules without having to resort to that workaround :slightly_smiling_face:

yes, thanks!
BTW, I think a warning is perfectly fine there, I would certainly leave it as it is, because it is indicating an actual issue :)

Yeah you're right, I don't understand right now why the warning is not more often displayed though. Anyway, bad news: blake3 (which is compiled) is lying about the parent module of blake3.blake3.blake3: it says it's builtins. Not sure what hackery they actually do :confused: I guess I'll have to special case it in Griffe, but that doesn't make me so happy :joy:

Yeah you're right, I don't understand right now why the warning is not more often displayed though. Anyway, bad news: blake3 (which is compiled) is lying about the parent module of blake3.blake3.blake3: it says it's builtins. Not sure what hackery they actually do 😕 I guess I'll have to special case it in Griffe, but that doesn't make me so happy 😂

hahaha damn. hmmm, well, the Zen says that no special case is special enough :P
I could manually add some docs, and be done w/ it :)

BTW, thanks so much for this!

 You can also open a new issue with just the link to this comment, this way I don't forget about it :slightly_smiling_face:

I have bad news: I did a quick test w/ latest blake3 and griffe@master, and this is still happening.
I'll keep digging, and open an issue directly in griffe. Thanks for everything!

Meh :confused: OK, thanks for reporting back, I'll continue to investigate as well.

I wonder if this is because @oconnor663 set the parent to module to blake3 instead of blake3.blake3 :thinking:

Or we simply hit the design flaw where modules and members of the same cannot coexist, while this is possible in Python itself.

Well, it's the former. If we patch the module of the blake3 class to be blake3.blake3 instead of blake3, it's correctly inspected instead of being marked as an alias to blake3.blake3.
If we don't, Griffe thinks that blake3.blake3.blake3 is an alias to blake3.blake3, the alias is correctly resolved, but then this module does not have the members of the class (obviously), resulting in a collection error.

If blake3 patches the module (again :pray: :bow: :heart:), then you can enable the md_in_html Markdown extension in mkdocs.yml and use this:
<div style="display: none;" markdown=1>

::: blake3
    options:
        members: false
        show_root_heading: false
        show_root_toc_entry: false

</div>

::: blake2signer.hashers

I'm pretty new to the behavior of __module__, so it's certainly possible I did the wrong thing here. But intuitively it seems correct that the module should be blake3. That's consistent with the following toy example:
blake3.py
class blake3:
    pass

main.py
from blake3 import blake3
print(repr(blake3.__module__))

$ python3 main.py
'blake3'

I don't think anyone expects main.py to print blake3.blake3, but then I'm confused reading the thread above. What am I missing?

See also the pure-C port, which uses Python's C API directly. There we set .tp_name = "blake3.blake3", and Python infers based on the dots that __module__ should be "blake3".

Your toy example is correct, however your code/project has one more layer:
blake3/  # <- module == blake3
    __init__.py  # <- imports blake3 class from compiled blake3 below
    blake3.cpython-311-x86_64-linux-gnu.so  # <- module == blake3.blake3

Generally, it seems that objects do have the full, canonical path to the module they are defined in as value for __module__. Some examples:
>>> from griffe import load_git  # indirect import
>>> load_git.__module__
'griffe.git'

>>> from griffe.agents.base import BaseVisitor  # direct import
>>> BaseVisitor.__module__
'griffe.agents.base'

Ah interesting. It looks like that's an implementation detail of the Maturin build tool. I've opened a discussion question about best practices here: https://github.com/PyO3/maturin/discussions/1365. Please chime in if you have any thoughts about Maturin/PyO3, or if you can clarify exactly how the mkdocs tool is getting confused. (I'm not familiar with it.)

The Maturin maintainer has asked for repro steps here: https://github.com/PyO3/maturin/discussions/1365#discussioncomment-4454070. Could someone here add a mkdocs repro to that thread?

Just published blake3 v0.3.3 with __module__ set to blake3.blake3. Could you give this another try?

Seems to be working fine! I'll let @HacKanCuBa confirm :slightly_smiling_face:

md_in_html

Indeed, it does work when I do something like explained here :D 🥳
It still fails if I use ::: blake2signer.hashers.blake3 instead of ::: blake3, but this is good enough 😅

As I tried to explain before, ::: blake2signer.hashers.blake3 will not make Griffe load the blake3 package, so you won't have any information about the blake3 class.
The idea is that later, you'll be able to use something like this:
# mkdocs.yml
plugins:
- mkdocstrings:
    handlers:
      python:
        preload: [blake3]

...so that you don't have to rely on this hidden div hack :slightly_smiling_face:


Maps section stuck on loading

My map section is stuck on loading

mqtt:
  host: 192.168.1.xx
  port: 1883
  ssl: false
  username: xxx
  password: xxx

# This gets added to the x,y,z to derive a gps location
gps:
  latitude: xx.897957
  longitude: -xx.xx6560
  elevation: 146

# How long before device considered stale
timeout: 30
# How long before device is considered away
away_timeout: 120

optimization:
  enabled: true
  interval_secs: 3600
  limits:
    absorption_min: 2.5
    absorption_max: 3.5
    tx_ref_rssi_min: -70
    tx_ref_rssi_max: -50
    rx_adj_rssi_min: -15
    rx_adj_rssi_max: 20

weighting:
  algorithm: gaussian
  props:
    sigma: 0.10

# Floors w/ the points to draw it in meters
floors:
  - id: ground
    name: Ground Floor
    rooms:
      - name: Office
        points:
          - [0, 9.22]
          - [5.79, 9.22]
          - [5.79, 5.97]
          - [0, 5.97]
          - [0, 9.22]
      - name: Garage
        points:
          - [2.97, 5.97]
          - [5.79, 5.97]
          - [5.79, 0]
          - [2.97, 0]
          - [2.97, 5.97]
      - name: Foyer
        points:
          - [0, 5.97]
          - [2.97, 5.97]
          - [2.97, 0]
          - [0, 0]
          - [0, 5.97]

  - id: first
    name: First Floor
    # Bounds (x,y,z) of map in meters
    rooms:
      - name: Kitchen
        points:
          - [0, 8.28]
          - [5.79, 8.28]
          - [5.79, 4.62]
          - [0, 4.62]
          - [0, 8.28]
      - name: Living Room
        points:
          - [0, 4.62]
          - [5.79, 4.62]
          - [5.79, 0]
          - [0, 0]
          - [0, 4.62]

  - id: second
    name: Second Floor
    rooms:
      - name: Bedroom
        points:
          - [0, 8.28]
          - [5.79, 8.28]
          - [5.79, 4.62]
          - [0, 4.62]
          - [0, 8.28]
      - name: Other Rooms
        points:
          - [0, 4.62]
          - [5.79, 4.62]
          - [5.79, 0]
          - [0, 0]
          - [0, 4.62]

# Locations of espresense nodes in meters
nodes:
  - name: Bedroom
    point: [0, 2, 0]
    floors: ["second"]
  - name: Garage
    point: [2, 0, 1]
    floors: ["ground"]
  - name: Office
    point: [1, 0, 0.5]
    floors: ["ground"]
  - name: Living Room
    point: [0.25, 0.4, 0.3]
    floors: ["first"]
  - name: Kitchen
    point: [0, 3, 0.85]
    floors: ["first"]

# Devices to track
devices:
  - id: "iBeacon:879c94c5xxxxxxxxxxxxxxxxxxxx-0"
  - id: "irk:21365xxxxxxxxxxxxxxxxxx"

Figured it out, need bounds


Updating README.md

Just a little ajustment.

... namely that you surrounded the "ctrl-c" commands in backtacks.  Which is fine, thanks

Hey, sorry! Commit renamed 👍


Add a nice set-up

There is no easy way to set everything up.

last commit adds something about that.
test with
python3 -m pip install --index-url https://test.pypi.org/simple/ muvi-maker-by-jannisnecker

Se #9


UI/UX for Manage Lots View

Create UI/UX flow for the manage lots view that accommodates 10+ lots.

This issue is being closed due to platform migration and may be revisited at a later date.


fix(query): update version of Flux in promqltests

GoLand is auto-updating these files, and it was causing annoyances.

I filed this issue to ensure we don't forget in the future:
https://github.com/influxdata/influxdb/issues/16090


[ROCm] Re-enabling unit-tests that are now passing on ROCm platform

/cc @cheshire @chsigg @nvining-work

@deven-amd  Can you please check @kkimdev's comments and keep us posted ? Thanks!

@cheshire @chsigg gentle ping


text-splitters: fix text_splitter keep_seprator git bug

Description: fix text_splitter keep_seprator git bug:

both _split_text_with_regex and self._merge_splits functions dill with the self._keep_separator param. So remove the _keep_separator relate process in self._merge_splits;
To minimize the impact of code changes, Just keep the self._merge_splits second separator param to "". I can further modify the _merge_splits function to remove separator related codes by a further patch.

Issue: #23394
from langchain.text_splitter import RecursiveCharacterTextSplitter

if __name__ == "__main__":
    # Wrong behaviour, using \s instead of regular space
    splitter_keep = RecursiveCharacterTextSplitter(
        separators=[r"\s"],
        keep_separator=False,
        is_separator_regex=True,
        chunk_size=15,
        chunk_overlap=0,
        strip_whitespace=False)
    assert splitter_keep.split_text("Hello world")[0] == r"Helloworld"

    # Expected behaviour, keeping regular space
    splitter_no_keep = RecursiveCharacterTextSplitter(
        separators=[r"\s"],
        keep_separator=True,
        is_separator_regex=True,
        chunk_size=15,
        chunk_overlap=0,
        strip_whitespace=False)
    assert splitter_no_keep.split_text("Hello world")[0] == r"Hello world"

wrong fix up now, I will fix by another patch...


RSpec/ChangeByZero cop and compound operators

Hello,
I see that there was an issue with this use case that was fixed in #1324 and released in 2.13.0 . However, I ran into the following error even after updating to 2.15.0:
An error occurred while RSpec/ChangeByZero cop was inspecting ...foo.../xyz_spec.rb:90:54.
undefined method `method_name' for #<RuboCop::AST::AndNode:0x000000015aceea18>
Did you mean?  method
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-rspec-2.15.0/lib/rubocop/cop/rspec/change_by_zero.rb:115:in `compound_expectations?'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-rspec-2.15.0/lib/rubocop/cop/rspec/change_by_zero.rb:103:in `check_offense'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-rspec-2.15.0/lib/rubocop/cop/rspec/change_by_zero.rb:91:in `block in on_send'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-rspec-2.15.0/lib/rubocop/cop/rspec/change_by_zero.rb:82:in `expect_change_with_arguments'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-rspec-2.15.0/lib/rubocop/cop/rspec/change_by_zero.rb:90:in `on_send'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:136:in `public_send'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:136:in `block (2 levels) in trigger_restricted_cops'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:160:in `with_cop_error_handling'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:135:in `block in trigger_restricted_cops'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:134:in `each'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:134:in `trigger_restricted_cops'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-1.38.0/lib/rubocop/cop/commissioner.rb:70:in `on_send'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-ast-1.23.0/lib/rubocop/ast/traversal.rb:158:in `block in on_send'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-ast-1.23.0/lib/rubocop/ast/traversal.rb:155:in `each'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-ast-1.23.0/lib/rubocop/ast/traversal.rb:155:in `each_with_index'
...foo.../.rvm/gems/ruby-2.7.6/gems/rubocop-ast-1.23.0/lib/rubocop/ast/traversal.rb:155:in `on_send'

The spec causing this error has the following expectation:
expect {
  method_being_tested
}.to change(ModelA, :count).by(-1).and change(ModelB, :count).by(0)

Additional version info:
1.38.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.23.0, running on ruby 2.7.6) [arm64-darwin21]

My mistake, the spec had a typo in it. It had:
.to change(ModelA, :count).by(-1) and
instead of
.to change(ModelA, :count).by(-1).and
(Missing dot before and)

Thank you for your report.
Please let us know if you notice anything else.


tensorflow

Issue type
Others
Have you reproduced the bug with TensorFlow Nightly?
Yes
Source
source
TensorFlow version
2.8
Custom code
Yes
OS platform and distribution
wondows 10
Mobile device
No response
Python version
3.9
Bazel version
No response
GCC/compiler version
No response
CUDA/cuDNN version
No response
GPU model and memory
No response
Current behavior?
Traceback (most recent call last):
File "C:\Python312\Lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 70, in
from tensorflow.python._pywrap_tensorflow_internal import *
ImportError: DLL load failed while importing _pywrap_tensorflow_internal: A dynamic link library (DLL) initialization routine failed.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "c:\Users\Bernabas\Documents\game_ai_tool\api\app.py", line 9, in
from ai_model.model import GameAIModel
File "c:\Users\Bernabas\Documents\game_ai_tool\ai_model\model.py", line 3, in
import tensorflow as tf
File "C:\Python312\Lib\site-packages\tensorflow_init_.py", line 38, in
from tensorflow.python import pywrap_tensorflow as _pywrap_tensorflow  # pylint: disable=unused-import
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "C:\Python312\Lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 85, in
raise ImportError(
ImportError: Traceback (most recent call last):
File "C:\Python312\Lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 70, in
from tensorflow.python._pywrap_tensorflow_internal import *
ImportError: DLL load failed while importing _pywrap_tensorflow_internal: A dynamic link library (DLL) initialization routine failed.
Failed to load the native TensorFlow runtime.
See https://www.tensorflow.org/install/errors for some common causes and solutions.
If you need help, create an issue at https://github.com/tensorflow/tensorflow/issues and include the entire stack trace above this error message.
Standalone code to reproduce the issue
# api/app.py

import sys
import os

# Add the parent directory to the Python path
sys.path.append(os.path.abspath(os.path.join(os.path.dirname(__file__), '..')))

from ai_model.model import GameAIModel
from flask import Flask, request, jsonify

app = Flask(__name__)

# Initialize your model
model = GameAIModel()
model.load_weights('path_to_your_saved_model.h5')

@app.route('/generate_game', methods=['POST'])
def generate_game():
    data = request.json
    user_input = data['input']
    # Preprocess the input as required
    response = model(user_input)
    # Postprocess the output as required
    return jsonify(response)

if __name__ == '__main__':
    app.run(debug=True)

Relevant log output
Traceback (most recent call last):
  File "C:\Python312\Lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 70, in <module>
    from tensorflow.python._pywrap_tensorflow_internal import *
ImportError: DLL load failed while importing _pywrap_tensorflow_internal: A dynamic link library (DLL) initialization routine failed.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "c:\Users\Bernabas\Documents\game_ai_tool\api\app.py", line 9, in <module>
    from ai_model.model import GameAIModel
  File "c:\Users\Bernabas\Documents\game_ai_tool\ai_model\model.py", line 3, in <module>
    import tensorflow as tf
  File "C:\Python312\Lib\site-packages\tensorflow\__init__.py", line 38, in <module>
    from tensorflow.python import pywrap_tensorflow as _pywrap_tensorflow  # pylint: disable=unused-import
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Python312\Lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 85, in <module>
    raise ImportError(
ImportError: Traceback (most recent call last):
  File "C:\Python312\Lib\site-packages\tensorflow\python\pywrap_tensorflow.py", line 70, in <module>
    from tensorflow.python._pywrap_tensorflow_internal import *
ImportError: DLL load failed while importing _pywrap_tensorflow_internal: A dynamic link library (DLL) initialization routine failed.

Failed to load the native TensorFlow runtime.

Please search for similar issues here. This shows up quite frequently and it's caused by your CPU not having support for AVX instructions.

So, is there a possible way I can solve it?
I'm building a software which requires a tensorflow package. Can I get a
package which can help me in replace of tensorflow?
On Sat, Jul 20, 2024, 8:06 PM Mihai Maruseac @.***>
wrote:

Please search for similar issues here. This shows up quite frequently and
it's caused by your CPU not having support for AVX instructions.
—
Reply to this email directly, view it on GitHub
https://github.com/tensorflow/tensorflow/issues/72120#issuecomment-2241170668,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BHWE24ONH6VUBYVAHJCMMRTZNJYWPAVCNFSM6AAAAABLDIZ2JGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBRGE3TANRWHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please see #36167. Closing this as duplicate of that issue. Please search past issues in the future, instead of duplicating.


[dashboard] Create dashboard for v2

Expected Behavior

Current Behavior

Possible Solution

Context

Client version used:
Node version used:
Chain used:
Browser Name and version:
Operating System and version (desktop or mobile):
Link to your project:

Today: Learned about proxies, got Hasura dashboard running locally.
Next steps: hopefully get deployed. And then see what tooling/notifications I can easily build on top of Hasura

Need to add Hasura user to db entry script.. @bohendo can you advise here? I see where the postgres user is assigned, but I don't see where permissions are granted
https://docs.hasura.io/1.0/graphql/manual/deployment/postgres-permissions.html#postgres-permissions

Hasura working, proxy WIP
https://github.com/ConnextProject/indra/pull/374

Wrestled with proxy for awhile today. Didn't go well. Keeps resolving to Dai Card instead of /hasura/. All changes are pushed
cc @bohendo when you're back and rested up.

currently failing CI. appears to be trying to reference a network that doesn't exist. still digging here.
https://circleci.com/gh/ConnextProject/indra/7272?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

Merged, closing


Migrating from flutter_driver When use integration_test,it cause 'Flutter Driver extension is taking a long time to become available'.

code sample
// This is a basic Flutter widget test.
//
// To perform an interaction with a widget in your test, use the WidgetTester
// utility that Flutter provides. For example, you can send tap and scroll
// gestures. You can also use WidgetTester to find child widgets in the widget
// tree, read text, and verify that the values of widget properties are correct.
import 'package:flutter_test/flutter_test.dart';
import 'package:integration_test/integration_test.dart';

import 'package:integration_test_example/main.dart' as app;

import '_example_test_io.dart' if (dart.library.html) '_example_test_web.dart'
    as tests;

void main() {

  group('integration test', () {
    setUpAll(() async {
      IntegrationTestWidgetsFlutterBinding.ensureInitialized();
    });

    testWidgets('verify text', (WidgetTester tester) async {
    // Build our app and trigger a frame.
      app.main();
      await tester.pumpAndSettle();

      await Future<void>.delayed(const Duration(seconds: 1));

      await tester.tap(find.text("RaisedButton"));
      await tester.pumpAndSettle();

      await Future<void>.delayed(const Duration(seconds: 1));

      expect(find.text('First'), findsOneWidget);
    });
  });
}

When I follow the example and tried to modify the driver code to the new integration_test, it could not run.
https://flutter.cn/docs/testing/integration-tests

logs
VMServiceFlutterDriver: Connecting to Flutter application at http://<IP_ADDRESS>:64672/p1y7o1D34Ks=/
VMServiceFlutterDriver: url:http://<IP_ADDRESS>:64672/p1y7o1D34Ks=/--------------webSocketUrl:ws://<IP_ADDRESS>:64672/p1y7o1D34Ks=/ws-----------
VMServiceFlutterDriver: Isolate found with number:<PHONE_NUMBER>40703
VMServiceFlutterDriver: Isolate is paused at start.
VMServiceFlutterDriver: Attempting to resume isolate
flutter: 00:00 +0: integration test (setUpAll)
flutter: 00:00 +0: integration test (setUpAll) [E]
flutter:   'package:integration_test/integration_test.dart': Failed assertion: line 130 pos 12: 'WidgetsBinding.instance is IntegrationTestWidgetsFlutterBinding': is not true.
flutter:   dart:core-patch/errors_patch.dart 46:39                                                        _AssertionError._doThrowNew
  dart:core-patch/errors_patch.dart 36:5                                                         _AssertionError._throwNew
  package:integration_test/integration_test.dart 130:12                                          IntegrationTestWidgetsFlutterBinding.ensureInitialized
  Users/william/Desktop/integration_test-1.0.1/example/integration_test/example_test.dart 19:44  main.<fn>.<fn>
  package:test_api/src/backend/declarer.dart 310:70                                              Declarer._setUpAll.<fn>.<fn>.<fn>
  dart:async/future.dart 512:26                                                                  Future.forEach.<fn>
  dart:async/future.dart 554:26                                                                  Future.doWhile.<fn>
  package:stack_trace/src/stack_zone_specification.dart 126:26                                   StackZoneSpecification._re<…>
flutter: 00:00 +0 -1: integration test (tearDownAll)
flutter: 00:00 +1 -1: Some tests failed.
VMServiceFlutterDriver: Flutter Driver extension is taking a long time to become available. Ensure your test app (often "lib/main.dart") imports "package:flutter_driver/driver_extension.dart" and calls enableFlutterDriverExtension() as the first call in main().

Hi @songtangjie
Can you please provide your flutter doctor -v  and a complete reproducible minimal code sample in a GitHub repository
Thank you

Hi @songtangjie
Can you please provide your flutter doctor -v  and a complete reproducible minimal code sample in a GitHub repository
Thank you

I'm seeing the same issue under 1.22.5
Flutter 1.22.5 • channel stable • https://github.com/flutter/flutter.git
Framework • revision<PHONE_NUMBER> (3 weeks ago) • 2020-12-10 11:54:40 -0800

Strangely, it only seems to manifest when trying to run the tests under Firebase Test Lab devices?

I'm seeing the same issue under 1.22.5
Flutter 1.22.5 • channel stable • https://github.com/flutter/flutter.git
Framework • revision<PHONE_NUMBER> (3 weeks ago) • 2020-12-10 11:54:40 -0800

Strangely, it only seems to manifest when trying to run the tests under Firebase Test Lab devices?

Actually seems to be a duplicate of #72063?

Actually seems to be a duplicate of #72063?

Hi @zmeggyesi
Thanks, I wanted to double-check. With confirmation, I feel safe to close this as duplicate https://github.com/flutter/flutter/issues/72063
Please follow up on that issue, I'm closing the current one as a duplicate.
If you disagree, please write in the comments and I will reopen it.
Thank you

Hi @zmeggyesi
Thanks, I wanted to double-check. With confirmation, I feel safe to close this as duplicate https://github.com/flutter/flutter/issues/72063
Please follow up on that issue, I'm closing the current one as a duplicate.
If you disagree, please write in the comments and I will reopen it.
Thank you


Fix limitation related to filtering tags by name:value pairs

A limitation was added to the documentation in #1618. That limitation is:

If you try to exclude :name => 'foo' and :name => 'bar', you will only end up excluding :name => 'bar'.

It would be nice if the filtering implementation is improved so that limitation no longer applies, and that using those excludes (equivalent to --tag ~name:foo --tag ~name:bar on the CLI) then rspec excludes tests that are tagged with :name => 'foo' or :name => 'bar'. rather than just :name => 'bar'.

@maxlinc is this a dup of https://github.com/rspec/rspec-core/issues/1622?

I'm going to say yes and close as a duplicate, especially given the conversation is being held there :)


Remove author tags in engine (registry-rendering)

Refer to this link for build results (access rights to CI server needed):
http://jenkins.terasology.org/job/TerasologyPRs/330/
Hooray Jenkins reported success with all tests good!


Enable E2E tests for products out of stock

We have prepared E2E test for edge cases that require a product to be out of stock. We need to set the product to this state and enable tests.

Some document with edge case products should be created. Would be very helpful in future E2E tests development.

@gladius-mtl Would be good to place this information in our docs.
## Helpful E2E test development information

Products for test cases:

- use product 'Alpha 350' with id `1446509` for placing orders (has almost unlimited stock)
- use tripod with id `29925` for testing product out of stock

Created follow-up doc ticket GH-246 to incorporate the suggested input into our documentation.
This issue can now be moved to QA (or next logical state).

Done. Test provided, all builds pass properly.


Vulnerability roundup 76: openconnect-8.02: 1 advisory

search, files

[ ] CVE-2019-16239 (nixos-19.03)

Scanned versions: nixos-19.03: 2c61951df92. May contain false positives.

Fixed by update to 9.05 in 19.09. https://github.com/NixOS/nixpkgs/commit/1e724d939ae24b16cfdba98c620145bafb86e9a9, probably not worth to backport to 19.03.


param save performance

Investigate bson encoder write performance, and likely start buffering writes.

perf counters

save, find, get, commit, failures

throttle param changed publications
look for param abusers

some modules are updating params multiple times

Nice work!

Fixed.


updated some old publications

👷 Deploy Preview for gladia processing.

Name
Link

🔨 Latest commit
a6906ea0cd6e5a57a6730194dbdc922296cd116e

🔍 Latest deploy log
https://app.netlify.com/sites/gladia/deploys/668a486cd1916200084c2b6c


Sprint1

@LukasBudach Thanks a ton for the very helpful feedback! Please let me know if you want to go through another review round or if we are good to merge.


How to get hardware opacity?

Hi!
For my hardware configuration each time I change the opacity style of the object (i.e. LV_OPA_50) the pixels that object is drawn with must contain it's alpha value in color.alpha member (not being mixed with background color, etc.), i.e in the 4th byte of the pixel, that gets sent to framebuffer.
What changes do I need to make to lvgl or its configuration to make that work?

Hi,
Do you mean something like this?
https://github.com/littlevgl/lvgl/issues/262

Not exactly. What I basically need is 3 opacity levels for different objects: full (for active screen), semi (for some background objects) and none (for active objects).
First I do as in the example you referenced.
lv_obj_set_style (lv_scr_act(), &lv_style_transp); and the screen indeed gets transparent.
Then I do
obj=lv_obj_create (lv_scr_act (), NULL);
lv_style_copy (&some_style, &lv_style_plain);
some_style.body.main_color = LV_COLOR_BLACK;
some_style.body.grad_color = LV_COLOR_BLACK;
some_style.body.opa = LV_OPA_70;
lv_label_set_style (hibar, &bar_style);
And no matter what opacity value I put into 'some_style.body.opa' it doesn't get respected and leaves the object completely opaque.

I see. The alpha channel of ARGB8888 can't be user directly right now but it should work:

In lv_color.h modify the ret.alpha = 0xFF; part in lv_color_mix() function to ret.alpha = (uint16_t)((uint16_t) c1.alpha * mix + (c2.alpha * (255 - mix))) >> 8;
Set some_style.body.main_color.alpha = 0x30;

And that worked. Thank you very much!

Awesome!


[BEAM-3060] HDFS large cluster configuration. Jenkins job updated to use large cl…

…uster.
All files have meaningful description. This PR switches Jenkins job to use hdfs large cluster in all jenkins jobs that use hdfs. Large cluster is configured as 1 namenode and 3 datanodes. StatefulSet introduced in kubernetes 1.9 is used instead of ReplicationControlller as better solution for solving cluster auto-configuration issues. Docker image with hadoop 2.7.1 is hosted in public docker hub and being pulled from it.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

It will help us expedite review of your Pull Request if you tag someone (e.g. @username) to look at it.

Run Seed Job

Run Java TextIO Performance Test HDFS

@chamikaramj It's ready for review.
I expected the error with deletion so I created an issue in JIRA describing the reason why we need to upgrade kubectl to at least version 1.9.3 link to jira. I didn't expected that we are using kubernetes server version lower than 1.9 which is an issue because we can't use new kubernetes features like StatefulSets(they bring lots of improvement over ReplicationsControllers and simplifies hadoop configuration a lot.)
I created a JIRA issue for this https://issues.apache.org/jira/browse/BEAM-4390 I also mentioned about security issues found on 20 of May that need to be pached.
@chamikaramj who may have access to GCP UI and can help with upgrading of kubernetes cluster in apache-beam-testing project?

Run Java TextIO Performance Test HDFS

Run Java CompressedTextIO Performance Test HDFS

Works like a charm! Alan Myrvold update kubernetes cluster so I finally tested it on our Jenkins.
@chamikaramj let me know if I can help with the review.


Dockerized DB file doesn't seem to create the access_keys relation

Encountered this when running the Compose file in https://github.com/near/local . When using the suggested test query from this README file, http://localhost:3000/publicKey/ed25519:EKveJ28ocxfHXQEfH42AowPL7HgXHkKp3kmMoSXNjiRF/accounts, the contract-helper-app returns:
error: relation "access_keys" does not exist

From digging through the code, my best guess is it's coming from this query: https://github.com/near/near-contract-helper/blob/fa70f1d6e953551acc4f37f3cbed0ba5c025b775/middleware/indexer.js#L83
And is happening because the https://github.com/near/near-contract-helper/blob/master/scripts/create_dev_dbs.sh that the Dockerized DB uses doesn't create the access_keys relation.

Solved: access_keys actually comes from the migration done in https://github.com/near/near-indexer-for-explorer


Development: Add domain objects for standardized competencies

🔥 Contains a database migration, do not deploy! 🔥
Checklist
General

[x] I tested all changes and their related features with all corresponding user types on a test server.
[x] Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
[x] I chose a title conforming to the naming conventions for pull requests.

Server

[x] Important: I implemented the changes with a very good performance and prevented too many (unnecessary) database calls.
[x] I strictly followed the server coding and design guidelines.
[x] I added multiple integration tests (Spring) related to the features (with a high test coverage).
[x] I added pre-authorization annotations according to the guidelines and checked the course groups for all new REST Calls (security).
[x] I documented the Java code using JavaDoc style.

Motivation and Context
Adds the domain objects for #8001
Description

Adds the tables, domain objects, repositories, services and resources for standardized competencies.
Adds a BaseCompetency object from which all competencies inherit.

Steps for Testing
Run locally and see that the migration works and Artemis starts up.
Test the following endpoints with Postman:

POST api/admin/standardized-competencies/knowledge-areas (create a knowledge area)
POST api/admin/standardized-competencies (create a standardized competency)
GET api/standardized-competencies/:id (get a standardized competency)
GET api/standardized-competencies/knowledge-areas/:id (get a knowledge area)

Testserver States

[!NOTE]
These badges show the state of the test servers.
Green = Currently available, Red = Currently locked

Review Progress
Performance Review

[x] I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance

Code Review

[x] Code Review 1
[x] Code Review 2

Manual Tests

[x] Test 1
[x] Test 2

Test Coverage
Server

Class/File
Line Coverage
Confirmation (assert/expect)

BaseCompetency.java
100%
✅

Competency.java
79%
✅

KnowledgeArea.java
100%
✅

Source.java
92%
✅

StandardizedCompetency.java
89%
✅

SourceRepository.java
100%
✅

KnowledgeAreaRepository.java
100%
✅

StandardizedCompetencyRepository.java
100%
✅

KnowledgeAreaService.java
100%
✅

StandardizedCompetencyService.java
100%
✅

AdminStandardizedCompetencyResource.java
100%
✅

StandardizedCompetencyResource.java
100%
✅

Summary by CodeRabbit

New Features

Enhanced Knowledge Area management system for creating and retrieving knowledge areas with parent-child relationships and associated competencies.
Added Source entity to define sources with attributes like title, author, and URI, linked to standardized competencies.
Implemented Standardized Competency management for creating and validating standardized competencies, including versioning and relationships.

Tests

Expanded integration tests for creating and managing standardized competencies and knowledge areas, with authorization checks for different user roles.

Blocked by the spring boot upgrade.


Refresh UE? autocomplete widgets, after using rgthree pan / zoom nodes

The rgthree suite has some nodes that allow to pan / zoom the workflow.
There is the Fast Groups Muter, that also can take you the group's location in the workflow.
And there is also a "bookmark" node, which takes us to it's position, with a pre-selected zoom level, via keybind.
https://github.com/rgthree/rgthree-comfy?tab=readme-ov-file#bookmark-
When we use them, the UE? autocomplete widgets don't refresh fast enough.
So we can still see them, in the position and size that they had before.
And we can also click on them, like a regular widget, to show the text input popup, and the autocomplete balloon.
So it's not just a visual artifact.
After panning manually a bit, this goes away.
But the point of using these rgthree nodes, is to get to that exact place in the workflow automatically.
So having to pan manually afterwards, makes them far less useful.

Interesting. Does it happen with any other modes? In particular, anything with a multiline text input would be interesting to test.

This is the only issue I noticed using the rgthree nodes.
The large field for the prompt text does not have this issue.
What I noticed, sometimes, is that when I'm making changes in more complex workflows, the autocomplete widgets still appear in the top left corner, like before.
There are multiple ones, on top of each other.
And then, they also disappear after planning / zooming, like before.
But I'm not entirely sure about what actions trigger that.
One thing I noticed is that using Ctrl+Z ( Undo ) can trigger that.

Does it happen with any other modes? In particular, anything with a multiline text input would be interesting to test.

In a complex workflow, the main issue can also happen, even without using the rg3 zoom / pan nodes.
Here I have a workflow with "priory boost" up to 5.
So there is a lot of text in the EU? widgets.
When I zoom in manually, I can still see the widgets in the screen's corner, from a previous zoom level.

On a side note,
And sorry for bringing up up this again,
But, are you sure that, in the long term, wouldn't it just be easier to have a custom autocomplete, instead of trying to hunt down all these widget errors ?
ComfyUI-Custom-Scripts uses this MIT implementation, and I never noticed any issues.
https://github.com/pythongosssss/ComfyUI-Custom-Scripts?tab=readme-ov-file#autocomplete
https://github.com/pythongosssss/ComfyUI-Custom-Scripts/blob/main/web/js/common/autocomplete.js

OK, the current autocomplete widget does have an advantage.
It can display a larger number of characters.

All single line string nodes, from different suites, seem to have the same limit on the characters displayed.
Could it be a Comfy UI limitation ?

To further improve the way this works in UE? widgets,
Maybe the text input pop up could be disabled if the "|" character is detected in the current string.
Because, in these cases, it's better to just edit the text directly in the widget, like we did before.

OK, the current autocomplete widget does have an advantage.
It can display a larger number of characters.   All single line string nodes, from different suites, seem to have the same limit on the characters displayed. Could it be a Comfy UI limitation ?

Yes.
The single-line text widgets on ComfyUI are built-in (not by Comfy, but from the underlying LiteGraph code) with a fixed width. To add the autocomplete to these directly is not at all simple.
So going to a custom widget is basically unavoidable. And that (not the use of the html autocomplete) is what causes some of the UI complications. So swapping out to use a different autocomplete would add complexity without removing any. The other autocompletes knocking around in the custom node world are (AFAIK) working in the multi-line text area, which is a custom widget added by Comfy. And I really don't want to use a multi-line widget for the regexes!
Closing the autocomplete on detection of a specific character is fairly easy, but I wonder if it would be better to make the escape key do it (like is common in web UIs) but make it persistent (so if you press escape, the autoprompt goes away and doesn't come back!)

I really don't want to use a multi-line widget for the regexes

I agree. The text is not as visible in the multi line widget, so single line is better for me.

if you press escape, the autoprompt goes away and doesn't come back

So the autocomplete would be disabled for that UE node ?
That would work well.
For multi regex, we don't really need autocomplete.


Explicitly set redirect: follow on the precaching requests.

R: @addyosmani @gauntface
The default mode for redirect is 'follow', as per the Fetch API specification.
However, as per #220, that default behavior doesn't appear to be universally applied, in particular in older versions of Chrome and in more recent versions of Firefox.
This PR changes precaching requests to explicitly set redirect: 'follow' to ensure that the behavior is consistent instead of relying on the browser default. Since that was what I had expected the behavior to be already (in browsers following the spec), I think this should be a "safe" change, and will roll it out with an accompanying minor version bump.
Fixes #220

@jeffposnick would you be willing to write a test to ensure this isn't reverted at a later date? If not I'm happy to commit to this branch and fix it before merging this PR.
Would also be good to then raise an issue with Firefox if this issue is still being exhibited.


[FR] The relization of pipeline.

This page lists the requirements for The relization of pipeline.
for more details, see #476
Requirements:

[ ] Render template:

[ ] RBAC:

[ ] PredefinedTask

[ ] CustomTask

[ ] Pipeline

[ ] Trigger

[ ] PredefinedTask:

[ ] Git clone:

[ ] Lint

[ ] UT

[ ] Build image

[ ] Upload image

and so on

[ ] Reconciler for Render Tekton Resource:

[ ] Kurator pipeline cli:

[ ] Get pipeline excution log and status

[ ] Install Tekton, optional

[ ] Docs:

[ ] How to create github secret

[ ] How to create OCI registry secret

[ ] How to config a gateway service to route trigger

[ ] How to use PredefinedTask

[ ] How to use CustomTask

[ ] How to manage your supply chain security

/assign

PredefinedTask Rendering:
PredefinedTask directly render default parameter values for existed task, eliminating the need for user configuration. This method is efficient for standard tasks, reducing setup complexity and expediting the process.  It is based on class Tekton catalog task
CustomTask Rendering:
CustomTask rendering automates the entire task setup, requiring no parameter input from the user. It's designed for complex tasks, providing a ready-to-use configuration with all necessary details included. It is means that, user need provide enough info about the task excution.
Pipeline Integration:
Both PredefinedTask and CustomTask are engineered for direct integration into Pipelines, no more need any parameter passing.


encoding/json: incorrect usage of sync.Pool

https://golang.org/cl/84897 introduces a denial-of-service attack on json.Marshal via a live-lock situation with sync.Pool.
Consider this snippet:
type CustomMarshaler int

func (c CustomMarshaler) MarshalJSON() ([]byte, error) {
	time.Sleep(500 * time.Millisecond) // simulate processing time
	b := make([]byte, int(c))
	b[0] = '"'
	for i := 1; i < len(b)-1; i++ {
		b[i] = 'a'
	}
	b[len(b)-1] = '"'
	return b, nil
}

func main() {
	processRequest := func(size int) {
		json.Marshal(CustomMarshaler(size))
		time.Sleep(1 * time.Millisecond) // simulate idle time
	}

	// Simulate a steady stream of infrequent large requests.
	go func() {
		for {
			processRequest(1 << 28) // 256MiB
		}
	}()

	// Simulate a storm of small requests.
	for i := 0; i < 1000; i++ {
		go func() {
			for {
				processRequest(1 << 10) // 1KiB
			}
		}()
	}

	// Continually run a GC and track the allocated bytes.
	var stats runtime.MemStats
	for i := 0; ; i++ {
		runtime.ReadMemStats(&stats)
		fmt.Printf("Cycle %d: %dB\n", i, stats.Alloc)
		time.Sleep(time.Second)
		runtime.GC()
	}
}

This is a variation of https://github.com/golang/go/issues/23199#issuecomment-353193866 of a situation suggested by @bcmills.
Essentially, we have a 1-to-1000 ratio of a routines that either use 1KiB or 256MiB, respectively. The occasional insertion of a 256MiB buffer into the sync.Pool gets continually held by the 1KiB routines. On my machine, after 300 GC cycles, the above program occupies 6GiB of my heap, when I expect it to be 256MiB in the worst-case.
\cc @jnjackins @bradfitz

It's been nearly a year, and no real attention to this issue.
So what are the options for fixing this?
The simplest would be to set an arbitrary size limit for buffers to recycle. Whatever number is selected will hurt performance for someone, I'd wager.
When using a json.Encoder, an additional configuration parameter could be exposed (i.e. SetMaxBufferSize). That complicates sharing buffer pools across encoder instances, though.
Providing a package-level variable is an option, too, but an ugly one that should absolutely be avoided (I just mention it for completeness sake).
Eliminating the need internal buffering in the json encoder could be another option. It wouldn't solve this problem for everyone, but it would provide recourse for those who are affected enough to care. Incidentally, this was the exact issue that I think brought this up (https://go-review.googlesource.com/c/go/+/135595).

@flimzy, one approach would be to keep statistics on the output size, and only return a buffer to the pool if it isn't a statistical outlier. The problem there is that the statistical computations need to be cheap enough that they don't swamp out the benefit from using sync.Pool in the first place.
Another (simpler?) approach would be to pull a buffer from the pool, use it, and abandon it instead of returning it to the pool according to some probability distribution computed from the final high-water mark and the actual buffer size. (One simple distribution would be: 1.0 if the buffer is within 2x of the final high-water mark, or 0.0 otherwise.)

@flimzy, are you running into an issue related to this in production? Seeing how it performs badly in production may be helpful data in coming up with a reasonable approach for this.
When I filed this issue, it was just a theoretical issue I saw. It was not a concrete problem I was experiencing.

@dsnet: No, I'm not. I'm interested in resolving this issue because it seems to be a blocker for making headway on some other json-encoder related issues that are affecting me: https://go-review.googlesource.com/c/go/+/135595, and by extension https://github.com/golang/go/issues/33714

Thanks for the feeback, @bcmills
I like the simplicity of your second approach.  I think we need to be careful not to discard buffers to aggressively, in the case of applications that naturally have a large disparity of JSON payloads.  A simple example comes to mind: A REST API that responds with {"ok":true} for PUT requests, but with 10s or 100s of kb responseses for a 'GET'. Perhaps considering 10k (or another arbitrary limit) as the high-water mark, if it was smaller than that.
I can still imagine certain applications where this would be sub-optimal, but maybe this is a reasonable starting point, to be tuned later

As I consider this further, I have to wonder: Is this really a DoS attack vector? If it were for json.Unmarshal, I can see it being easily exploited (just send a huge payload to your favorite Go-powered REST API).  But as this is for json.Marshal, for this to be exploited, it would mean that several other possible validation opportunities were disregarded.
I don't mean to suggest this doesn't warrant some amount of attention, I just suspect the danger is over-stated.

Another approach would be to remove the package level encodeStatePool and allow the caller to optionally supply one when creating an encoder. The reasoning here is that the caller has more knowledge about the distribution of payloads and the edge cases that a package-level statistical count would struggle with.

Another approach would be to remove the package level encodeStatePool and allow the caller to optionally supply one when creating an encoder.

This does seem like the only approach to cover all use cases optimally. Is there any precedent for something similar elsewhere in the stdlib to use for guidance?

I have created https://golang.org/cl/195217 as the simplest change I could think of to address the concerns raised in #27735.  My main concern with this implementation is that it would become possible for a third-party library to starve the buffer pool by, for instance, never returning anything to the pool.
The other realistic approach, IMO, is to expose the encodeStatePool object to the public API. This will have a larger footprint on the public API, and will require all users of json.NewEncoder wishing to use the new functionality, to propagate their own pool throughout their code (including to any third-party libraries which do JSON encoding), to avoid using lots of fragmented pools.
Even with the drawbacks, the latter may be the better approach, but I started with the former because it is so simple, it seemed worth the minor effort to put it in front of reviewers.

I've been thinking of ways to guarantee bounds on the worst-case behavior, and this is a prototype idea:
// bufferPool is a pool of buffers.
//
// Example usage:
//
//	p := getBuffer()
//	defer putBuffer(p)
//	p.buf = appendFoo(p.buf, foo)        // may resize buffer to arbitrarily large sizes
//	return append([]byte(nil), p.buf...) // single copy of the buffer contents
//
var bufferPool = sync.Pool{
	New: func() interface{} { return new(pooledBuffer) },
}

type pooledBuffer struct {
	buf     []byte
	strikes int // number of times the buffer was under-utilized
}

func getBuffer() *pooledBuffer {
	return bufferPool.Get().(*pooledBuffer)
}

func putBuffer(p *pooledBuffer) {
	// Recycle large buffers if sufficiently utilized.
	// If a buffer is under-utilized enough times sequentially,
	// then it is discarded, ensuring that a single large buffer
	// won't be kept alive by a continuous stream of small usages.
	switch {
	case cap(p.buf) <= 1<<16: // always recycle buffers smaller than 64KiB
		p.strikes = 0
	case cap(p.buf)/2 <= len(p.buf): // at least 50% utilization
		p.strikes = 0
	case p.strikes < 4:
		p.strikes++
	default:
		return // discard the buffer; too large and too often under-utilized
	}
	p.buf = p.buf[:0]
	bufferPool.Put(p)
}

In the worst-case scenario, we can ensure a bound on the minimal utilization based on the % threshold (e.g., 50% in the example above) and maximum number of sequential recycles below that threshold (e.g., 4x in the example above).
For the constants chosen above, the worst case sequence of utilization would be:

50%, 0%, 0%, 0%, 0%, 50%, 0%, 0%, 0%, 0%, 50%, 0%, 0%, 0%, 0%, ...

On average, that's a worst case utilization of 10%, which is far better than the theoretical worst-case of 0% if the code naively recycles buffers without any limits.
Advantages of the algorithm:

It's simple; easy to analyze and reason about.
It's fast; only requires basic integer arithmetic.
It doesn't depend on any global state where statistics are concurrently gathered.
For usages of all the same approximate size (regardless of how big or small), this ensures buffers are always recycled.

Happy to hear suggestions for improvements.

@dsnet I like this. It's elegant and low cost. What is the reasoning behind dropping <64k buffers?

The idea of keeping statistics locally is a nice one. We do lose some amount of information every time we throw away an over-sized buffer. An alternative, which might be helpful if we kept more sophisticated statistics, would be to nil out buf and return the pooledBuffer object to the pool. Then on Get we could pre-allocate a new buf with a better initial size.
Even with these simple stats, it might even be worth zeroing and returning pooledBuffer to avoid an allocation. Maybe even include a small byte array struct field in pooledBuffer that we could initialize buf to use, providing an allocation-free path when a small buf is needed.

@dsnet I like this. It's elegant and low cost. What is the reasoning behind dropping <64k buffers?

It's not dropping 64k buffers, but always choosing to recycle them in the pool. That specific code path isn't strictly necessary, but for buffers below a certain size it probably doesn't hurt to always recycle them regardless of the utilization.

An alternative, which might be helpful if we kept more sophisticated statistics, would be to nil out buf and return the pooledBuffer object to the pool. Then on Get we could pre-allocate a new buf with a better initial size.

Interesting idea. I think a useful statistic to obtain would perhaps be the maximum length encountered over the last N usages. If we evict a buffer due to low utilization, we can allocate a new one based on a recently seen maximum length.

https://go.dev/cl/455776 is now complete and has minimal impact on existing benchmarks. It more or less completely solves this issue. I'd love to get a review or some sort of official confirmation that it's on the radar.

@dsnet It's been awhile! Friendly ping, any change we can get this change on track for go 1.21? (https://go.dev/cl/455776)

Thank you very much for implementing this and exploring it as a solution.
I was in the process of reviewing this a few weeks ago and was saddened by the amount of logic being added (300LOC for the logic, and another 300LOC for the tests). I believe that a segmented buffer is probably the right approach in the long term, but much of the complexity stems from the existing logic in json assuming that it's outputting to a bytes.Buffer. Thus, your segmented buffer is forced to implement non-trivial methods like Truncate, WriteByte, WriteString, and WriteTo. Had the rest of json been changed to only rely on append-to mechanisms (e.g., #53685), then the segmented buffer implementation can be reduced to <200LOC (for both logic and tests). This is due to no fault of your implementation, but rather the rest of the package that it's trying to interface with.
I see several possible paths forward:

Cleanup the rest of json to stop depending on so many methods of bytes.Buffer and instead rely mostly on append-to operations. However, @mvdan, @johanbrandhorst, and I have been discussing completely replacing the underlying syntactical encoder/decoder with a different implementation in the future, so this may not be worth the effort.
Just implement a simple capacity limit on buffers returned to the pool. Something like https://go-review.googlesource.com/c/go/+/136035, where we just accept the loss of performance for larger outputs.
Still use tiered sync.Pools, but maintain a single contiguous buffer (instead of segmented ones). When we grow, we copy the contents to a larger buffer twice the size. Such a buffer is much simpler to implement the methods of Truncate, WriteByte, or WriteString. Also, since the unused capacity is never larger than the length, we could consider just returning the results of Bytes without cloning it. This would avoid the final clone that we do before we return the buffer to the user in Marshal.

Seems much riskier (more logic changed, more chances for bugs) -- json output is much more complex than tracking how many bytes are in a buffer.
capping the size doesn't solve the problem in general, it helps a range of sizes but removes the benefits of the cache from other sizes.
In running benchmarks to select the buffer sizes used in my change, it became obvious that allocating really large buffers is sometimes really slow. This would be substantially worse performance variance than what I have implemented. (Ironically this was my original suggestion and the current approach was your counter-suggestion :) )

I found that the existing json tests exercised ~every code path already and the specific tests I added are just for ease in debugging and peace of mind.
The code could be made shorter by using generics to cover both Write and WriteString with one function; it is also probably overly optimized and could be made simpler and only slightly slower. OTOH the tests could be extended with a randomized test that proves same behavior as the stock bytes.Buffer.
For my use case (kube-apiserver) I really need to keep all the speed from caching and also to not be 5xing memory usage for certain request patterns, as the current code does. Is there anything I can do to this change to make it acceptable? My other options aren't great.

I discussed it with @mvdan, and we think option 1 is the best path forward. I don't think it's that hard to switch the encoder to use append-like APIs. I'll send out a CL for that.
Thus, the segmented buffer will only need to implement the following methods:

Grow, AvailableBuffer, Write, Reset, Bytes

You'll notice that AvailableBuffer is not currently present on bytes.Buffer, but may be added in #53685.
You could optionally implement the following wrappers:
func (b *buffer) WriteString(s string) (int, error) {
    return b.Write(append(b.AvailableBuffer(), s...))
}
func (b *buffer) WriteByte(c byte) error {
    _, err := b.Write(append(b.AvailableBuffer(), c))
    return err
}

or they can instead be methods on encodeState.

I'm not sold on using AvailableBuffer like that here, because if the thing being written doesn't fit in the buffer there will be an allocation. But there is a fairly easy way to use it that doesn't have that problem, I think.

You're correct that there could be an allocation outside of the segmented buffer, but the number of allocations asymptotically approaches zero so long as the buffer grows exponentially (which it does).
For the cases where the appended bytes could be large, we call Grow beforehand, which guarantees sufficient capacity to prevent an allocation. I did this for the logic prior to calling appendCompact and the appending of base64 encoded data since we know those sizes. We could also consider doing it for strings. All other writes are small (e.g., bools and numbers), where the probability of an allocation is small and low cost.

I don't think it's ideal but it can be made to work by truncating the existing buffer and allocating a one-off buffer of the requested size or bigger. Likewise when there are only a few bytes left in the current buffer, I would truncate it and make another when AvailableBuffer is called.
I found that the best performance was with many smallish buffers (< 64k IIRC) rather than continuing to double the size. So, the allocations are not exponentially rare when the output is big enough.

OK, I read the above CLs -- is there more coming or shall I rebase on top of those?

Even if the buffer is not exponentially grown, so long as we explicitly call Grow before large writes, I believe the performance will still be fine. Writing of single-byte delimiters, bools, and numbers are sufficiently small that even with a 4k buffer, the probability of an occasional small allocation is okay.

OK, I read the above CLs -- is there more coming or shall I rebase on top of those?

That's all for what's relevant for your change.

I've rebased and it's working, but it's much slower than it was so I've got more work to do before I push a new revision.

I have perf back to baseline, but git codereview mail does not like the fact that I've pulled your changes locally and rebased on top of them (it thinks I'm trying to impersonate you :) ), how do I appease it?

OK I think I figured out my rebase problem and https://go.dev/cl/455776 is ready for a pass. It is not much smaller because the b.Write(append(b.AvailableBuffer(), s...)) style one-liners are significantly slower than the code I'd gotten to. WriteByte in particular is called so often that all the details matter a lot.

I'm still a bit saddened by the amount of code being added. I sent out https://go.dev/cl/471200 as a simpler alternative implementation.
Here's the performance comparison:
name \ time/op                v0                v1             v2
LargeOutput-24                1.85s ± 3%        1.56s ± 3%     1.35s ± 9%
CodeEncoder-24                394µs ± 1%        408µs ± 2%     379µs ± 1%
CodeEncoderError-24           437µs ± 1%        450µs ± 1%     423µs ± 1%
AllocationWastage-24          396µs ± 2%        719µs ± 3%     482µs ± 4%
CodeMarshal-24                534µs ± 1%        722µs ± 7%     633µs ± 4%
CodeMarshalError-24           694µs ± 2%        905µs ± 4%     789µs ± 3%
MarshalBytes/32-24            170ns ± 3%        173ns ± 3%     162ns ± 2%
MarshalBytes/256-24           387ns ± 2%        456ns ± 1%     378ns ± 2%
MarshalBytes/4096-24         3.93µs ± 2%       3.98µs ± 1%    3.89µs ± 1%
MarshalBytesError/32-24       372µs ± 1%        361µs ± 1%     370µs ± 1%
MarshalBytesError/256-24      372µs ± 1%        363µs ± 1%     371µs ± 1%
MarshalBytesError/4096-24     379µs ± 1%        369µs ± 3%     377µs ± 2%
EncodeMarshaler-24           22.8ns ± 2%       25.1ns ±12%    24.7ns ± 5%
EncoderEncode-24             12.5ns ± 3%       13.2ns ± 1%    15.0ns ±19%

name \ wasted_b/op            v0                v1             v2
AllocationWastage-24          2.25M ± 0%        0.16M ± 0%     0.16M ± 0%

where:

v0 is 8e5f56a2e3a027e886d78f36675c275b9c845da0
v1 is https://go.dev/cl/455776
v2 is https://go.dev/cl/471200

Comparing v2 relative to v1, we get:
name                            old time/op      new time/op   delta
LargeOutput-24                  1.56s ± 3%       1.35s ± 9%   -13.49%  (p=0.000 n=8+10)
CodeEncoder-24                  408µs ± 2%       379µs ± 1%    -7.08%  (p=0.000 n=10+9)
CodeEncoderError-24             450µs ± 1%       423µs ± 1%    -5.92%  (p=0.000 n=8+9)
AllocationWastage-24            719µs ± 3%       482µs ± 4%   -32.87%  (p=0.000 n=9+10)
CodeMarshal-24                  722µs ± 7%       633µs ± 4%   -12.37%  (p=0.000 n=9+10)
CodeMarshalError-24             905µs ± 4%       789µs ± 3%   -12.80%  (p=0.000 n=10+9)
MarshalBytes/32-24              173ns ± 3%       162ns ± 2%    -6.37%  (p=0.000 n=10+9)
MarshalBytes/256-24             456ns ± 1%       378ns ± 2%   -17.03%  (p=0.000 n=10+10)
MarshalBytes/4096-24           3.98µs ± 1%      3.89µs ± 1%    -2.34%  (p=0.000 n=9+10)
MarshalBytesError/32-24         361µs ± 1%       370µs ± 1%    +2.59%  (p=0.000 n=9+10)
MarshalBytesError/256-24        363µs ± 1%       371µs ± 1%    +2.22%  (p=0.000 n=10+9)
MarshalBytesError/4096-24       369µs ± 3%       377µs ± 2%    +1.92%  (p=0.002 n=10+10)
EncodeMarshaler-24             25.1ns ±12%      24.7ns ± 5%      ~     (p=0.343 n=10+10)
EncoderEncode-24               13.2ns ± 1%      15.0ns ±19%   +13.39%  (p=0.003 n=8+10)

There's generally a performance improvement over the more complicated https://go.dev/cl/455776 implementation.
The apparent performance degradation of EncoderEncode seems to be largely in the noise.
I feel bad sending out an alternative CL after you (@lavalamp) clearly spent a lot of time on your CL. I'm okay with you taking attribution credit for the CL if you want. After all, my CL would not have come about until you spent the grunt work to prove that segmented buffers were a viable solution.

I found that the best performance was with many smallish buffers

I found this comment curious, so I spent some time investigating why this might be the case.
The cause is that as buffers grow larger, they are recycled through the sync.Pool more infrequently with longer time periods between each use. Consequently, there's a higher probability that the larger buffers have been GC'd before it even got a chance to be reused. At the same time, there's benefits to larger buffer sizes as hardware is often optimized for long sequential memory accesses. Thus, there are two goals that are competing against each other. We do want to grow the buffer sizes over time, but also not too quickly that larger buffers are likely to be GC'd too early.

I put my benchmark results in a comment on the CL, they are directionally the same.
I am happy with any solution as long as the problem gets solved :)

Thus, there are two goals that are competing against each other.

Yeah, the most striking thing was that variance was super high with large buffers, so it makes sense that there are competing effects.

@dsnet Have you seen the approach taken by https://github.com/valyala/bytebufferpool? It also attempts to collect some stats.

Is there any update on this issue?


Inverted Half Pyramid

Output :
Enter a number: 5
5 5 5 5 5
4 4 4 4
3 3 3
2 2
1

rename the file as Q36.java


Create tutorial with jupyter notebook

Create a tutorial with a jupyter notebook to explain the library basic objects and functionality.
This notebook can be rendered by sphinx and used in the documentation.

#103 closes this issue.


Quick accent en-dash appears to be linked to Hebrew rather than special characters

Microsoft PowerToys version
0.87.0
Installation method
PowerToys auto-update
Running as admin
None
Area(s) with issue?
Quick Accent
Steps to reproduce
Check available characters for "-"
Choose a character set
Disable Hebrew
Check available characters for "-"
✔ Expected Behavior
En-dash (U+2013) should be visible.
❌ Actual Behavior
En-dash (U+2013) disappears from the list.
Would have expected it to be linked to special characters.
Other Software
No response

Hi @Arzza , In special characters, En-dash (U+2013) is still in there, but if you press the comma (",") key. Does this help? /needinfo

@jaimecbernardo the en dash does not appear for me under the hyphen-minus key or the comma key. i have all character sets enabled.

actually i'm seeing much stranger behavior now. after trying Quick Accent on the comma key, i tried the hyphen again, and suddenly there were only two characters appearing on that key: the en dash and the hebrew punctuation maqaf.
i double-checked my Quick Accent settings and found that about half of the options were turned off, including Special Characters. i fixed that and now i'm seeing the behavior reported above: the en dash appears both on the hyphen key (where it is tied to the Hebrew script) and on the comma key (where it is tied to Special Characters).

That's very weird, indeed 🤔  Has it been stable after that? Or is it jumping around in terms of Settings?

i cannot reproduce the unstable options, but i can describe what happened more precisely:

used Quick Accent on hyphen-minus, no en dash
used Quick Accent on comma, no en dash there either
opened settings to check my character set options, saw "[-] All available" at the top level. i misinterpreted the colored hyphen as "all options selected" instead of "some options selected."
used Quick Accent again, saw almost all symbol characters missing.
checked settings again & opened the character set dropdown this time. about a third of the options were unchecked, all at the end of the list.
i clicked "All available" which changed from a hyphen to a checkmark, and selected all character sets.
tested Quick Accent again, found the en dash on hyphen-minus and comma.
temporarily disabled Hebrew script, found en dash missing from hyphen-minus.

summary:
en dash is not attached to the scripts & keystrokes i would expect
opening the settings page the first time seems to have corrupted my options
i suspect the settings glitch is related to a migration between Quick Accent upgrades, but i can't reproduce to verify

Yes, en-dash appears on comma tied to special characters, but it's not the
key I'd expect to see it on
On Thu, 19 Dec 2024 at 08:39, B. Szonye @.***> wrote:

i cannot reproduce the unstable options, but i can describe what happened
more precisely:

used Quick Accent on hyphen-minus, no en dash
used Quick Accent on comma, no en dash there either
opened settings to check my character set options, saw "[-] All
available" at the top level. i misinterpreted the colored hyphen as "all
options selected" instead of "some options selected."
used Quick Accent again, saw almost all symbol characters missing.
checked settings again & opened the character set dropdown this
time. about a third of the options were unchecked, all at the end of the
list.
i clicked "All available" which changed from a hyphen to a
checkmark, and selected all character sets.
tested Quick Accent again, found the en dash on hyphen-minus and
comma.
temporarily disabled Hebrew script, found en dash missing from
hyphen-minus.

summary:
en dash is not attached to the scripts & keystrokes i would expect
opening the settings page the first time seems to have corrupted my options
i suspect the settings glitch is related to a migration between Quick
Accent upgrades, but i can't reproduce to verify
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/36370#issuecomment-2552315616,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJIFYOKQHTWO6VRX6DH464T2GHTRXAVCNFSM6AAAAABTXEHGLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJSGMYTKNRRGY
.
You are receiving this because you were mentioned.Message ID:
@.***>


[Translation zh-tw] Fundamentals > Accessibility

Check out a review request at GitLocalize

:tada: This has been pushed live to https://developers.google.com/web/


chore: bdd-spring-1585146471 to 0.0.1

chore: Promote bdd-spring-1585146471 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


[feature request] An option to get machine-readable output from zenn article:new

Summary
Now zenn article:new puts 📄\e[32m<slug>.md\e[39m created..
But I want an output which can be parsed with pipe.
e.g.
$ zenn article:new --no-pretty
ecba19abfa3c41371a4a

or
$ zenn article:new --no-pretty
articles/ecba19abfa3c41371a4a.md

Argument

Option name

--silent like a curl
--porcelain like a git status
--machine-readable
--pretty (default: true)

Output

filename articles/ecba19abfa3c41371a4a.md
slug ecba19abfa3c41371a4a

arg doesn't support "--no-(boolean flag)" format.
So --pretty (default: true) should not be in the options.

I see,
it makes easy to do something like this.
https://zenn.dev/kyoh86/articles/c02511740d70365a1420
I will merge your PR.

@catnose99 thanks, it's fixed by #66

@kyoh86
New CLI has been released.
Upgrade with npm install zenn-cli@latest to reflect the changes.


SearchMetroTextBox style, IsReadOnly

What steps will reproduce this issue?
SearchMetroTextBox
I want to make it to read-only but can click on the search button.
Write problem description here
When I put the textbox to read only the same does not allow me to click the search button
Expected outcome
Write expected outcome here
Clicking the search button with the active isReadOnly property
--
Environment

MahApps.Metro v1.3.0
Windows 10
Visual Studio 2015
.NET Framework 4.61

@punker76 I agree with @robertorp that the clear button should be enabled even if the TextBox is readonly. Only if it's disabled, the button should be disabled too.
Currently, the button is disabled here and here respectively.

@thoemmi I'm with you with the MetroButtonTextBox but not for the textbox style, cause it clears the text if you click the button. I think this will maybe surprise the user?

😕 Yes, you're right. However, think of a "Browse" button. The user should not be able to enter the filename directly, therefore the textbox is readonly. But if the user clicks on the button, a File Open dialog should open.
So the button should be enabled even if the textbox is readonly, only if TextBoxHelper.ButtonCommand is set. 😎

@robertorp This feature will be available in 1.4.0


HV-1455 Be more consistent about when sanity checks are applied

https://hibernate.atlassian.net/browse/HV-1455

Quick explanation: right now, we are a bit inconsistent about when the sanity checks are applied: sometimes it's after testing that there are no constraints, sometimes it's after. We should be consistent in 2 ways:

for all the different methods
for all the different types of sanity checks

LGTM. Thanks, @gsmet!


Feature Request: Goto tab by number

In chrome and most other browsers/editors, we can go to a particular tab by pressing the Command key and the number. For example: If we press Command+1 we will go to the first tab, Command+2 takes to the second tab, etc.
It will be good if visual studio provides a way (either by default or after configuring) to move to a particular tab by number, using along with a keyboard shortcut.
Stackoverflow link where I asked this initially: http://stackoverflow.com/questions/41951206/visual-studio-code-go-to-a-tab-by-number

All there:


Vite | Build | Client/SSR Duplicate Asset Error

Description
When migrating from esbuild to Vite, I encountered a small issue when creating the Vite production builds. Even though dev was working as expected, there was an error during the writeBundle step of the SSR build.
After debugging locally, I found a quick check that should resolve the issue I was facing.
Expected Behavior
Vite builds for production once the development server is working.
Actual Behavior
The client bundle builds appropriately, but the SSR bundle fails with this error
x Build failed in 2.07s
Error: [remix] dest already exists.
    at doRename (/workspaces/superbud-ecomm/node_modules/fs-extra/lib/move/move-sync.js:32:34)
    at Object.moveSync (/workspaces/superbud-ecomm/node_modules/fs-extra/lib/move/move-sync.js:17:10)
    at Object.handler (/workspaces/superbud-ecomm/node_modules/@remix-run/dev/dist/vite/plugin.js:875:28)
    at async Promise.all (index 0)
    at async PluginDriver.hookParallel (file:///workspaces/superbud-ecomm/node_modules/rollup/dist/es/shared/node-entry.js:19525:9)
    at async file:///workspaces/superbud-ecomm/node_modules/rollup/dist/es/shared/node-entry.js:20521:13
    at async catchUnfinishedHookActions (file:///workspaces/superbud-ecomm/node_modules/rollup/dist/es/shared/node-entry.js:19942:16)
    at async Module.build (file:///workspaces/superbud-ecomm/node_modules/vite/dist/node/chunks/dep-whKeNLxG.js:67445:22)
    at async viteBuild (/workspaces/superbud-ecomm/node_modules/@remix-run/dev/dist/vite/build.js:212:5)
    at async Promise.all (index 0)
    at async build (/workspaces/superbud-ecomm/node_modules/@remix-run/dev/dist/vite/build.js:245:3)
    at async Object.viteBuild (/workspaces/superbud-ecomm/node_modules/@remix-run/dev/dist/cli/commands.js:183:5)
    at async Object.run (/workspaces/superbud-ecomm/node_modules/@remix-run/dev/dist/cli/run.js:252:7) {
  code: 'PLUGIN_ERROR',
  plugin: 'remix',
  hook: 'writeBundle'
}

This error was thrown on writeBundle step, when a server asset was trying to be moved to the client asset directory, even though the client asset already existed.
Root Cause
This could also mean there is an issue with the getViteManifestAssetPaths or the clientViteManifest, because the manifest doesn't appear to have all the assets listed that actually exist in the assets folder.
Testing
I didn't see any tests for the plugin file, so I didn't include any here. This is also a two line change

If our logic is correct you shouldn't be seeing this error. Would you be able to share a minimal reproduction?

Thanks for the quick response @markdalgleish. Yes - let me do a little more digging and whip something up.

okay - @markdalgleish I added you to a stackblitz project with version of my branch where I am able to reproduce the error. https://stackblitz.com/edit/vitejs-vite-wdeefj
Dev will build and run but 404 without appropriate environment variables. Running npm run build should display the error I get.
Reproduction Steps

Open stackblitz project
Wait for startup procedures to complete.
In the terminal, run npm run typecheck. This might fail due to sharp not being able to be installed in the web container. That is okay. This script also generates automated code that the project needs.
In the terminal, run npm run build or npx remix vite:build

@markdalgleish Ping to see if there are any updates.

@PrescottJRynewicz Thanks for providing a repro. I was able to work out the root cause of this issue and fix it here: https://github.com/remix-run/remix/pull/9305


docs top-level organisation

This is just recording a first impression of the docs page:
Starting with "deployment" felt a bit strange to me - I would have expected "how to use" first.
On reading through the docs I think I understood the thought process behind the layout a bit better (this follows the standard pattern for a python package: install, how to use, how to develop)... however, many users of the AiiDA lab will actually never install it - they just log in.
For a python package, you typically have roughly two different types of users

some users are going to install and use the package
some users are going to want to develop the package

Both of these user types have in common that they are likely familiar with python and bash.
For the AiiDAlab, the situation is quite a bit more diverse:

some users are going to log into an existing instance and use the AIiDAlab (may not know any python or bash)
some users are going to want to develop apps
some users may want to run a docker container locally
administrators will want to deploy a multi-user instance
some admins/users will want to develop the AiiDAlab itself

It seems to me that in writing the docs we need to pay particular attention to ensure that the user group 1. is guided well and knows where to look for information.
I'll continue thinking a bit about this, input welcome.

One possibility would be to organise the docs by the target readership

Users
App developers
Server administrators
AiiDAlab developers

fixed in e0c9ca18475e882b63fb9ad089b0e96c6adaf7bd


New Probe Match in CS v1895

Hi the latest ColourSpace Version 1895 changed default Probe Match patch colours to 242 8 bit so you may adjust the Patchset that you provide for Legal to 224 and Full to 242

@BlackJoker90 Would you make a PR for this?

Fixed in #20 and #21


Adding delete stat to C++/CX test app

@jasonsandlin,
Thanks for your contribution as a Microsoft full-time employee or intern. You do not need to sign a CLA.
Thanks,
Microsoft Pull Request Bot


Handlebar creation for obtaining full path to the index pages inside subfolders

What is missing?

Panini handlebar to provide relative path of the page including folder name
Why is it important?

This would provide a better option for situations when using folder_name hierarchy as opposed to file_name hierarchy
Possible Solution

Create a handlebar helper that might provide. Something like {{root}} + {{url}} that would obtain a path like this: {{root}}/subfolder/subfolder/
Context

At the moment the only solution for this website structure is doing each page manually. Previously I was using file_name.html hierarchy and was able to pass the issue using #ifpage and #unlesspage which doesn't work in this hierarchy as all the pages are index.html.
Your Environment

Foundation version(s) used: 6.4.3
Browser(s) name and version(s): irrelevant
Operating System and version (desktop or mobile): irrelevant

Checklist (all required):

[ x] I have read and follow the CONTRIBUTING.md document.
[ x] There are no other issues similar to this one.
[ x] The issue title is descriptive.
[ x] The template is correctly filled.

Panini handlebar

Then this is the wrong repository. Please file this issue at https://github.com/zurb/panini/issues


Custom Sorter and Grouper Issue in SAPUI5

SAPUI5 version:1.79.2
URL (minimal example if possible):
https://jsbin.com/tuvedafibe/edit?html,output
Steps to reproduce the problem:

Input into id with 'any string',
Input into group with '1',
Input into type with '1',
Click on the add button,

What is the expected result?
The new value add into list should be grouped in the right place.
What happens instead?
Even though list already has group '1' exists, new value will always be added into the bottom of list.

I need to group by one field in the data and sort by another field, so that I can make sure item with bigger type will be always in the bottom of list.

As documented for the sap.ui.model.Sorter API,

.. Note: Grouping is only possible (and only makes sense) for the primary sort property.


Put together a slightly different worker model

Description
Mocked up what a csharp GDK worker might look like.

Rebased the branch - logging appears to be broken and some functionality that was added since this PR was opened needs to be added back in

Superseded by #981


catppuccin-cursors incorrect symlinks

Describe the bug
The Catppuccin-{color}-{variant}-Cursors symlink inside of ~/.icons is incorrect.
Well.. It is not directly incorrect. Rather the symlink at the location it's pointing to is incorrect.
Meaning ~/.icons ---> .../homa-manager-files/.icons -/-> .../catppuccin-cursors/share/icons
The link between:
.../homa-manager-files/.icons -/-> .../catppuccin-cursors/share/icons
is broken as it points to a folder that doesn't exist. (it should link to an all lower case folder)
Steps To Reproduce
Steps to reproduce the behavior:

Install catppuccin-cursors with home-manager
Select / Apply the cursors in your display manager.
It doesn't work / It will fallback to the default cursor as it can't find the catppuccin ones.

Expected behavior
The catppuccin cursors should be used by the window manager.
Screenshots

Additional context
I'm using Hyprland with hyprcursor but also have everything setup for xcursor usage.
Notify maintainers

@isabelroses
Metadata
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.9.3-zen1, NixOS, 24.11 (Vicuña), 24.11.20240605.e8057b6`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - channels(kurisu): `""`
 - nixpkgs: `/nix/store/8s55w0927lh3mdbkxf434zb0c5hqsz8z-source`

Add a :+1: reaction to issues you find important.

How did you install and configure it?

Using home-manager by settings:
let
  cursor-theme = "Catppuccin-Mocha-Dark-Cursors";
  cursor-package = pkgs.catppuccin-cursors.mochaDark;
in
{
  # ....

  home.sessionVariables = {
    NIXOS_OZONE_WL = "1";
    ANDROID_SDK_ROOT = "/home/kurisu/Android/Sdk";
    ANDROID_HOME = "/home/kurisu/Android/Sdk";
    XCURSOR_THEME = cursor-theme;
    # and some other variable (similar to xcursor) for Hyprlands hyprcursor.
    # tho I don't know it's exact name and I forgot to push it to gh so I can't look it up now
  };

  home.pointerCursor = {
    name = cursor-theme;
    package = cursor-package;
    size = 24;

    x11.enable = true;
    gtk.enable = true;
  };

  gtk = {
    enable = true;
    iconTheme = {
      name = "Papirus-Dark";
      package = pkgs.papirus-icon-theme;
    };
  };

  # ....
}

In that case it seems like your config should be updated?
home.pointerCursor.name = "catppuccin-mocha-dark-cursors";

lower case :)

Whoops that might make sense >.>

Yeah. Catppuccin developers are doing that all the time 😅

Same thing happened with catppuccin-gtk. As I mentioned there, sure we could standardise case/naming/etc within nixpkgs, but it'd be even more confusing for a new user to read the upstream code/docs and find that nixpkgs is doing something completely different. Hence I'd suggest we (continue to) follow upstream.

Catppuccin is standardizing on lowercase and american spellings, so we should just follow that imho

There is no standard; we just use whatever upstream calls it and don't rename anything in nixpkgs.


Binned Entropy Implementation is wrong

Currently the binned_entropy is wrong because pl.Series's hist function's behavior differs wildly from NumPy's np.histogram. The generated bins are wildly different. I am not sure if this is a bug on Polar's side, or this is just how they intend people to use the hist function on Series. Personally, I don't think it is a Polars error, but rather a "quirk". Another detail which took me a while to notice is that NumPy's histogram seems to be left_closed, while default behavior of Polars's right_closed.

I compared the current result vs. tsfresh's result, which replies on NumPy's histogram function, we can see the result is wrong.

I made a rewrite, which works on pl.Exprs, which I think is more preferable for the future of the package.
def binned_entropy_rewrite(x:pl.Expr, bin_count: int = 10) -> pl.Expr:
    step_size = 1/bin_count
    breaks = np.linspace(step_size, stop = 1 - step_size, num = bin_count - 1)
    scaled_x = (x - x.min()) / (x.max() - x.min()) # This steps slows down the calculation
    # Left closed because we want to micmic NumPy's histogram's behavior
    return scaled_x.cut(breaks, left_closed=True).value_counts().struct.field("counts").entropy().suffix("_binned_entropy")

If we want to work lazily, we will not be able to set the break points before scanning through the data. However, if can map the values of x into [0,1] by using min-max scaling which preserves the distribution (bins) within the break point ranges.
The only downside to this approach is that it seems to be much slower than NumPy (tsfresh) implementation as of now. On a Series/array of size 100_000, this took 3.7ms while tsfresh took 0.6ms. I currently don't see how to improve this further at this moment.

@abstractqqq let's go for your lazy / pl.Expr implementation. The time difference is marginal. The speed ups across other features should make up for the performance hit here.


Card in send-to-reader queue should be sent immediately

[x] Add new route to send each card in 'send to reader' list to the reader then move card to the 'Slush' list
[x] amend existing routes to move cards to this queue rather than doing this themselves

Closed by #30


Accept Codecov API token as a provider argument

Hello and thanks for this useful tool!
Would it be possible (or would a pull request be accepted) to make this provider accept the Codecov API token as an argument rather than getting it from an environment variable?
This would enable using a Terraform reference to provide the token, like
provider "ucodecov" {
  token = jsondecode(data.aws_secretsmanager_secret_version.codecov_secret.secret_string)["api-token"]
}

...similar to how it's implemented by terraform-provider-github.
Thanks!

Sounds nice to have similar API (use env var as a default) to terraform-provider-github.
PR is welcome!


Add missing properties to Shell related controls

This PR adds properties to the bindings file that were missing.
Also fixes some converters.
Note: Some changes to the bindings file feel hacky.
Really would like to rework that later.

Looks good to me.
You already marked the parts which you wanna take a look again.
Don't have more on this.


How can I put this tree-select in sidebar

I want to put this tree-select in sidebar, however, I cannot call the st.sidebar.****
Can anyone help me, I am a newer to Streamlit.
Thanks

with st.sidebar:
    return_tree = tree_select(nodes)