Update dependency mkdocs to ~=1.6.0

This PR contains the following updates:

Package
Type
Update
Change

mkdocs (changelog)
packages
minor
~=1.5.3 -> ~=1.6.0

Release Notes

mkdocs/mkdocs (mkdocs)
v1.6.0
Compare Source
Local preview

mkdocs serve no longer locks up the browser when more than 5 tabs are open. This is achieved by closing the polling connection whenever a tab becomes inactive. Background tabs will no longer auto-reload either - that will instead happen as soon the tab is opened again. Context: #3391

New flag serve --open to open the site in a browser.
After the first build is finished, this flag will cause the default OS Web browser to be opened at the home page of the local site.
Context: #3500

Drafts

[!warning]
Changed from version 1.5:
The exclude_docs config was split up into two separate concepts.

The exclude_docs config no longer has any special behavior for mkdocs serve - it now always completely excludes the listed documents from the site.
If you wish to use the "drafts" functionality like the exclude_docs key used to do in MkDocs 1.5, please switch to the new config key draft_docs.
See documentation.
Other changes:

Reduce warning levels when a "draft" page has a link to a non-existent file. Context: #3449

Update to deduction of page titles
MkDocs 1.5 had a change in behavior in deducing the page titles from the first heading. Unfortunately this could cause unescaped HTML tags or entities to appear in edge cases.
Now tags are always fully sanitized from the title. Though it still remains the case that Page.title is expected to contain HTML entities and is passed directly to the themes.
Images (notably, emojis in some extensions) get preserved in the title only through their alt attribute's value.
Context: #3564, #3578
Themes

Built-in themes now also support Polish language (#3613)

"readthedocs" theme

Fix: "readthedocs" theme can now correctly handle deeply nested nav configurations (over 2 levels deep), without confusedly expanding all sections and jumping around vertically. (#3464)

Fix: "readthedocs" theme now shows a link to the repository (with a generic logo) even when isn't one of the 3 known hosters. (#3435)

"readthedocs" theme now also has translation for the word "theme" in the footer that mistakenly always remained in English. (#3613, #3625)

"mkdocs" theme
The "mkdocs" theme got a big update to a newer version of Bootstrap, meaning a slight overhaul of styles. Colors (most notably of admonitions) have much better contrast.
The "mkdocs" theme now has support for dark mode - both automatic (based on the OS/browser setting) and with a manual toggle. Both of these options are not enabled by default and need to be configured explicitly.
See color_mode, user_color_mode_toggle in documentation.

[!warning]
Possible breaking change:
jQuery is no longer included into the "mkdocs" theme. If you were relying on it in your scripts, you will need to separately add it first (into mkdocs.yml) as an extra script:
extra_javascript:
  - https://code.jquery.com/jquery-3.7.1.min.js

Or even better if the script file is copied and included from your docs dir.

Context: #3493, #3649
Configuration
New "enabled" setting for all plugins
You may have seen some plugins take up the convention of having a setting enabled: false (or usually controlled through an environment variable) to make the plugin do nothing.
Now every plugin has this setting. Plugins can still choose to implement this config themselves and decide how it behaves (and unless they drop older versions of MkDocs, they still should for now), but now there's always a fallback for every plugin.
See documentation. Context: #3395
Validation
Validation of hyperlinks between pages
Absolute links

Historically, within Markdown, MkDocs only recognized relative links that lead to another physical *.md document (or media file). This is a good convention to follow because then the source pages are also freely browsable without MkDocs, for example on GitHub. Whereas absolute links were left unmodified (making them often not work as expected or, more recently, warned against).

If you dislike having to always use relative links, now you can opt into absolute links and have them work correctly.
If you set the setting validation.links.absolute_links to the new value relative_to_docs, all Markdown links starting with / will be understood as being relative to the docs_dir root. The links will then be validated for correctness according to all the other rules that were already working for relative links in prior versions of MkDocs. For the HTML output, these links will still be turned relative so that the site still works reliably.
So, now any document (e.g. "dir1/foo.md") can link to the document "dir2/bar.md" as [link](/dir2/bar.md), in addition to the previously only correct way [link](../dir2/bar.md).
You have to enable the setting, though. The default is still to just skip any processing of such links.
See documentation. Context: #3485
Absolute links within nav
Absolute links within the nav: config were also always skipped. It is now possible to also validate them in the same way with validation.nav.absolute_links. Though it makes a bit less sense because then the syntax is simply redundant with the syntax that comes without the leading slash.
Anchors
There is a new config setting that is recommended to enable warnings for:
validation:
  anchors: warn

Example of a warning that this can produce:
WARNING -  Doc file 'foo/example.md' contains a link '../bar.md#some-heading', but the doc 'foo/bar.md' does not contain an anchor '#some-heading'.

Any of the below methods of declaring an anchor will be detected by MkDocs:

#### Heading producing an anchor
#### Another heading {#custom-anchor-for-heading-using-attr-list}

[](){#markdown-anchor-using-attr-list}

Plugins and extensions that insert anchors, in order to be compatible with this, need to be developed as treeprocessors that insert etree elements as their mode of operation, rather than raw HTML which is undetectable for this purpose.
If you as a user are dealing with falsely reported missing anchors and there's no way to resolve this, you can choose to disable these messages by setting this option to ignore (and they are at INFO level by default anyway).
See documentation. Context: #3463
Other changes:

When the nav config is not specified at all, the not_in_nav setting (originally added in 1.5.0) gains an additional behavior: documents covered by not_in_nav will not be part of the automatically deduced navigation. Context: #3443

Fix: the !relative YAML tag for markdown_extensions (originally added in 1.5.0) - it was broken in many typical use cases.
See documentation. Context: #3466

Config validation now exits on first error, to avoid showing bizarre secondary errors. Context: #3437

MkDocs used to shorten error messages for unexpected errors such as "file not found", but that is no longer the case, the full error message and stack trace will be possible to see (unless the error has a proper handler, of course). Context: #3445

Upgrades for plugin developers
Plugins can add multiple handlers for the same event type, at multiple priorities
See mkdocs.plugins.CombinedEvent in documentation. Context: #3448
Enabling true generated files and expanding the File API
See documentation.

There is a new pair of attributes File.content_string that becomes the official API for obtaining the content of a file and is used by MkDocs itself.
This replaces the old approach where one had to manually read the file located at File.abs_src_path, although that is still the primary action that these new attributes do under the hood.

The content of a File can be backed by a string and no longer has to be a real existing file at abs_src_path.
It is possible to set the attribute File.content_string or File.content_bytes and it will take precedence over abs_src_path.
Further, abs_src_path is no longer guaranteed to be present and can be None instead. MkDocs itself still uses physical files in all cases, but eventually plugins will appear that don't populate this attribute.

There is a new constructor File.generated() that should be used by plugins instead of the File() constructor. It is much more convenient because one doesn't need to manually look up the values such as docs_dir and use_directory_urls. Its signature is one of:
f = File.generated(config: MkDocsConfig, src_uri: str, content: str | bytes)
f = File.generated(config: MkDocsConfig, src_uri: str, abs_src_path: str)

This way, it is now extremely easy to add a virtual file even from a hook:
def on_files(files: Files, config: MkDocsConfig):
    files.append(File.generated(config, 'fake/path.md', content="Hello, world!"))

For large content it is still best to use physical files, but one no longer needs to manipulate the path by providing a fake unused docs_dir.

There is a new attribute File.generated_by that arose by convention - for generated files it should be set to the name of the plugin (the key in the plugins: collection) that produced this file. This attribute is populated automatically when using the File.generated() constructor.

It is possible to set the edit_uri attribute of a File, for example from a plugin or hook, to make it different from the default (equal to src_uri), and this will be reflected in the edit link of the document. This can be useful because some pages aren't backed by a real file and are instead created dynamically from some other source file or script. So a hook could set the edit_uri to that source file or script accordingly.

The File object now stores its original src_dir, dest_dir, use_directory_urls values as attributes.

Fields of File are computed on demand but cached. Only the three above attributes are primary ones, and partly also dest_uri. This way, it is possible to, for example, overwrite dest_uri of a File, and abs_dest_path will be calculated based on it. However you need to clear the attribute first using del f.abs_dest_path, because the values are cached.

File instances are now hashable (can be used as keys of a dict). Two files can no longer be considered "equal" unless it's the exact same instance of File.

Other changes:

The internal storage of File objects inside a Files object has been reworked, so any plugins that choose to access Files._files will get a deprecation warning.

The order of File objects inside a Files collection is no longer significant when automatically inferring the nav. They get forcibly sorted according to the default alphabetic order.

Context: #3451, #3463
Hooks and debugging

Hook files can now import adjacent *.py files using the import statement. Previously this was possible to achieve only through a sys.path workaround. See the new mention in documentation. Context: #3568

Verbose -v log shows the sequence of plugin events in more detail - shows each invoked plugin one by one, not only the event type. Context: #3444

Deprecations

Python 3.7 is no longer supported, Python 3.12 is officially supported. Context: #3429

The theme config file mkdocs_theme.yml no longer executes YAML tags. Context: #3465

The plugin event on_page_read_source is soft-deprecated because there is always a better alternative to it (see the new File API or just on_page_markdown, depending on the desired interaction).
When multiple plugins/hooks apply this event handler, they trample over each other, so now there is a warning in that case.
See documentation. Context: #3503

API deprecations

It is no longer allowed to set File.page to a type other than Page or a subclass thereof. Context: #3443 - following the deprecation in version 1.5.3 and #3381.

Theme._vars is deprecated - use theme['foo'] instead of theme._vars['foo']

utils: modified_time(), get_html_path(), get_url_path(), is_html_file(), is_template_file() are removed. path_to_url() is deprecated.

LiveReloadServer.watch() no longer accepts a custom callback.

Context: #3429
Misc

The sitemap.xml.gz file is slightly more reproducible and no longer changes on every build, but instead only once per day (upon a date change).

Configuration
📅 Schedule: Branch creation - "before 4am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Self-Hosted Renovate Bot. Find all logs here.

 You will get a PR once a newer version is released. To ignore this dependency forever, add it to the ignoreDeps array of your Renovate config.
If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.


one-click-installer: syntax error for cmd_macos.sh

Hello! Looks like an awesome project.
I tried to follow the readme in one-click-installers-tts-6.0 and because I just created a fresh conda env with AARM64 PyTorch, I thought it'd be nice to use the cmd_macos.sh installer.
However, this fails with a syntax error on zsh (default mac os shell, I'm on a MacBook Air M2):
% sh cmd_macos.sh
cmd_macos.sh: line 12: syntax error near unexpected token `('
cmd_macos.sh: line 12: `bash --init-file <(echo "source \"$CONDA_ROOT_PREFIX/etc/profile.d/conda.sh\" && conda activate \"$INSTALL_ENV_DIR\"")'

Although I can't say for sure, I'd like to point out that it's meant to set
up the entire conda stack for you, so there might be some strangeness if
it's trying to create from within conda (I'm not familiar with nested
condas).
Once I get back I can investigate if there's a zsh syntax error.
On Sun, Nov 26, 2023, 1:42 AM audiocommander @.***>
wrote:

Hello! Looks like an awesome project.
I tried to follow the readme in one-click-installers-tts-6.0 and because
I just created a fresh conda env with AARM64 PyTorch, I thought it'd be
nice to use the cmd_macos.sh installer.
However, this fails with a syntax error on zsh (default mac os shell, I'm
on a MacBook Air M2):
% sh cmd_macos.sh
cmd_macos.sh: line 12: syntax error near unexpected token ('cmd_macos.sh: line 12: bash --init-file <(echo "source "$CONDA_ROOT_PREFIX/etc/profile.d/conda.sh" && conda activate "$INSTALL_ENV_DIR"")'
—
Reply to this email directly, view it on GitHub
https://github.com/rsxdalv/tts-generation-webui/issues/218, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTRXI4KYQCRDKHIRHMWFH3YGIUZFAVCNFSM6AAAAAA72HRRFCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGAYTANZUGM2DIMQ
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

thanks! no worries and no stress. This isn't meant as a desperate call for help but rather an info that the installers don't seem to work straight of the box (if I didn't mess it up). I'm not a trained computer scientist but I do have quite some experience in coding and feel like I do have a stable background in setting up my conda envs. Maybe I can help, this project looks pretty cool.

Thank you! If you are interested, you can take a look at the setup files.
They install python and pytorch as well as ffmpeg. Next, there is the
projects python install script which attempts to install as many
requirements files as possible.
Furthermore, for high compatibility, running a Linux container with pytorch
CPU would probably give you the most access to all the different models,
though it is painfully slow.
On Sun, Nov 26, 2023, 3:37 AM audiocommander @.***>
wrote:

thanks! no worries and no stress. This isn't meant as a desperate call for
help but rather an info that the installers don't seem to work straight of
the box (if I didn't mess it up). I'm not a trained computer scientist but
I do have quite some experience in coding and feel like I do have a stable
background in setting up my conda envs. Maybe I can help, this project
looks pretty cool.
—
Reply to this email directly, view it on GitHub
https://github.com/rsxdalv/tts-generation-webui/issues/218#issuecomment-1826405818,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTRXI3VXUUKJTALF4KYGULYGJCINAVCNFSM6AAAAAA72HRRFCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRWGQYDKOBRHA
.
You are receiving this because you commented.Message ID:
@.***>

Great!
Well, I believe I could install pretty much everything in order to run server.py successfully and I'm looking at a gradio site in my browser. Cool!
I will see if I find out more in the next days (haven't tested, I can only guess not everything will work out of the box).
Right now I can already say that the main problem with the install and update scripts is, that they uninstall working Metal-enabled PyTorch versions (2.2.0) and install oder CPU-only versions (2.0.0). I'm not sure about if xformers will even work on mac, but I could install something that was alright enough for audiocraft.
I think the only way to install PyTorch with Metal support is by using this (Apple recommended) command. At least some quick tests on my MacBook Air M2 run nicely and show that metal can be enabled with pytorch:
conda install pytorch torchvision torchaudio -c pytorch-nightly

Just had one major hiccup with gradio, but downgrading to 3.48.0 worked:
conda install gradio==3.48.0

(avoiding pip when conda install is available seems like a good strategy for me)
...will report more when I managed to play around a bit. I'm assuming that there are more things not yet working. But as I have already running bark in another env, I guess that most of it should theoretically work. Not blazingly fast but definitely not painfully slow. Enough to have some nerd fun with it...

So as far as the installing torch 2.0.0 goes - it's hard to prevent it from happening. Most of the projects used here "just do it" so I need a workaround to prevent it from happening. And if I'm not mistaken, some models might not work with newer torch versions, I think it was tortoise.
A solution could be to just install the new torch at the very end. Though, already the installation time is 50% reinstalling packages just to make all of the projects "happy".

Also, the project has now been upgraded to 3.48.0 hopefully reducing the issues for users.

The project now reinstalls the newest version of PyTorch for non-cuda installs at the end of each update. Hopefully that resolves the issue.


The site literally doesn't work

I was casually playing when I learned that i could use a Luigi model. Upon switching to Luigi, my game freezes. I could see new chat messages but I couldn't send my own. I refreshed the page went to it in a new tab, restarted the browser... I feel like I've tried everything at this point. I have attached a picture with an inspection tab. Please fix my issue as soon as possible. https://drive.google.com/file/d/1iPghDnOxSMKf_JodkFYoX9WLZhyDJSCl/view?usp=sharing

Object.keys(window.myMario.skinData).forEach((skinType) => {
        localStorage[`skinData-${skinType}`] = JSON.stringify(window.myMario.skinData[skinType])
})

Object.keys(window.myMario.skinData).forEach((skinType) => {
        localStorage[`skinData-${skinType}`] = JSON.stringify(window.myMario.skinData[skinType])
})

Thank you for the code, but where do I put it?

We have the same things bro.

Object.keys(window.myMario.skinData).forEach((skinType) => {
        localStorage[`skinData-${skinType}`] = JSON.stringify(window.myMario.skinData[skinType])
})

Thank you for the code, but where do I put it?

Put it in your JavaScript console. you can find it by the keybind ctrl+shift+i and then hit "Console" if it isn't already there


text on connections does not move behind the connection

When adding several flows to one screen. if these flows have nodes with the same id, the text on some connections does not move behind the connections.

thanks


OOP school library: add basic UI

Description
This pull request introduces a console-based School Library App implemented in Ruby. The project is organized into two main files:

app.rb: Contains the methods for handling each menu option, including listing books and people, creating persons (students and teachers), creating books, creating rentals, listing rentals for a given person ID, and exiting the program.

main.rb: Creates an instance of the App class and starts the app, using the methods defined in app.rb to handle menu options.

Usage
To use this application, follow these steps:

Open your terminal or command prompt.
Navigate to the directory where you saved Ruby files.
Execute ruby main.rb to start the application.
Interact with the application using the menu options provided.

Testing
The application has been tested for basic functionality, including menu navigation, creating persons, creating books, creating rentals, and listing rentals.

Thanks for the insights and reviews
It now works

@Eccb7 It was not working because your person data was empty, because you were using the person ID instead of using the array index number, which causes nil because that ID doesn't exist. With my above suggestion now it will work, I checked it thoroughly.
Happy Coding 🥂

Hi @skyv26
I very much appreciate for the clarity above :pray:

@Eccb7 Look at your screenshot, instead of passing the index number you passed the actual ID of the person. As per the requirement, you should pass the index number of the array not the actual ID, that's the reason why as a code reviewer we gave require changes because we strictly follow the guidelines and based on that your functionality was not fulfilling, what we were expecting.

Hey @skyv26
???


runtime: failed to restore the stack

At commit 164de4e395254e57c00108e852e7861b02954d93 (uncommitted, but on Gerrit) I see failed to restore the stack when running the race detector:
$ go test -v -race -short net/http
...
=== RUN TestProxyFromEnvironment
--- PASS: TestProxyFromEnvironment (0.00s)
=== RUN TestIdleConnChannelLeak
==================
WARNING: DATA RACE
Write by goroutine 56:
  net/http_test.TestIdleConnChannelLeak()
      /home/bradfitz/go/src/net/http/transport_test.go:1832 +0x272
  testing.tRunner()
      /home/bradfitz/go/src/testing/testing.go:452 +0xfc

Previous read by goroutine 39:
  [failed to restore the stack]

Goroutine 56 (running) created at:
  testing.RunTests()
      /home/bradfitz/go/src/testing/testing.go:560 +0xc96
  testing.(*M).Run()
      /home/bradfitz/go/src/testing/testing.go:490 +0xe7
  net/http_test.TestMain()
      /home/bradfitz/go/src/net/http/main_test.go:19 +0x35
  main.main()
      net/http/_test/_testmain.go:534 +0x20c

Goroutine 39 (finished) created at:
  net/http.(*Transport).dialConn()
      /home/bradfitz/go/src/net/http/transport.go:684 +0x1172
  net/http.(*Transport).getConn.func4()
      /home/bradfitz/go/src/net/http/transport.go:544 +0x76
==================
--- PASS: TestIdleConnChannelLeak (0.02s)
=== RUN TestTransportClosesRequestBody
--- PASS: TestTransportClosesRequestBody (0.00s)

/cc @dvyukov

This is a known implementation limitation.
I can only suggest to:

run with GORACE=history_size=7 (as per manual https://golang.org/doc/articles/race_detector.html)
reduce test size in various aspects
run the test a million of times grepping for the second stack (e.g. using the stress utility)


contracts: Remove OnKilledAccount implementation

Contracts now longer rely on this callback to tell them when they are removed. Instead, they can only self destruct  using ext_terminate.
Even without this change the now removed implementation wasn't called anymore in our default substrate runtime.
closes #4952

Yes I am already on it. The two failing tests are:
self_destruct_works
This is legit and might be caused by the early exit in AccountsDB::commit which should be removed (at least the test is green with it removed). I still do not understand why because the destruction and the account balance should be in different changesets? I might be wrong.
account_removal_removes_storage
I think this test makes no longer sense as as we specifically removed this functionality. Only ext_terminate can remove the storage.

Turns out that AccountDB merges the change sets which makes the early exit in AccountsDB::commit incorrect with the removal of OnKilledAccount. I removed the check.

The CI fail seems unrelated to the change. @pepyakin Any idea why this is failing?

Apparently, this has something to do with https://github.com/paritytech/substrate/pull/5366. I am not sure though what to do about it, except waiting for https://github.com/paritytech/polkadot/pull/938 to be landed.

Apparently, this has something to do with #5366. I am not sure though what to do about it, except waiting for paritytech/polkadot#938 to be landed.

yea, should be fixed now.


Tweak new AA implementation to get similar performance as the old one on Win32

This PR tries to restore performance of the AA after changing it to "state-of-the-art" dense hash map.

Thanks, that's a lot of useful stuff. It's a pity that you redid the effort to split the arrays, but that's a nogo given the cost of a cache miss.

Here is a pretty simple benchmark that becomes 30% slower with this patch, my CPU has 6MB L3 cache.
void main(string[] args)
{
    int[int] aa;
    foreach (_; 0 .. 10)
        foreach (i; 0 .. 1_000_000) // 16MB for bucket array
            ++aa[i];
}

Here is a pretty simple benchmark that is 30% slower with this patch, my CPU has 6MB of L3 cache.

Thanks. My CPU is similar (i7-2670QM), but shows only a 10% slowdown for Win64. On Win32 I had to double the size to get simliar results. Should we add this test to the benchmark suite?
The more common use case is to have smaller arrays, though. I concede that in a program that does different stuff in between AA operations, a double cache miss is more likely to happen.

Should we add this test to the benchmark suite?

Tests that run a few seconds are somewhat unproductive. Actually the stomper test was supposed to show this, but it's magnitude is much smaller as >50% of the time is spend polluting the cache.

The more common use case is to have smaller arrays, though. I concede that in a program that does different stuff in between AA operations, a double cache miss is more likely to happen.

It's more common, but both are common enough to matter. Can we split that off into a second pull request?

We could ditch the 32-bit hash value and only save 3 extra bits (above the mask) in the lower pointer bits.
That'll work with the 16-byte alignment of the GC and should still detect most collisions before comparing the key, but it means recomputing the hash on growth.

Thanks, that's a lot of useful stuff. It's a pity that you redid the effort to split the arrays, but that's a nogo given the cost of a cache miss.

I've rebased without the split arrays. The improvements are pretty small without it, though.

We could ditch the 32-bit hash value and only save 3 extra bits (above the mask) in the lower pointer bits.
That'll work with the 16-byte alignment of the GC and should still detect most collisions before comparing the key, but it means recomputing the hash on growth.

Interesting idea (there are 4 unused lower bits in the entry pointer, and 16 upper bits on 64-bit).

Tests that run a few seconds are somewhat unproductive.

If I reduce the iteration count to 4, but for 2_000_000 entries, it runs for 1.5s on my (slower) system. That's less than other benchmarks.
Apropos large number of entries: the new AA limits the number of entries to 2^^32 even on 64-bit. As the Impl struct is already slightly larger than 32 bytes, I think there is no real gain from that limitation and we should remove it.

Apropos large number of entries: the new AA limits the number of entries to 2^^32 even on 64-bit. As the Impl struct is already slightly larger than 32 bytes, I think there is no real gain from that limitation and we should remove it.

Makes sense, as long as the hot stuff fits into a single cacheline. I packed everything when there was still an inline init array.

I ran dfmt on the change and replaced CRLF with LF in rt.util.mem.

Yay, another bad decision sponsored by dmd's outdated backend.

The memcpy/… changes are probably a slight regression

The length is a runtime value, so that isn't entirely true.

The length is a runtime value, so that isn't entirely true.

I concur with David.  This will result in a slight regression for GDC (no cross-module inlining just yet).

Also, memset is recognised as a builtin in GDC, and so already would inline as outlined in this hack at no additional cost!
@MartinNowak - Revert?

Also, mempy/memset is recognised as a builtin in GDC, and so already would inline as outlined in this hack at no additional cost!

I tried both LDC and GDC for Win64: I don't get any inlining for memset/memcpy. What's the supposed code? If it is rep stosb or similar it has horrible setup time for small memory blocks. See also https://issues.dlang.org/show_bug.cgi?id=14458
Maybe we should version the code for DMD and other compilers?

If you are concerned, maybe you could inline it?  newitemT used to do this:  https://github.com/D-Programming-Language/druntime/commit/79bc91b41334c1805f557ef2f1606de31c6764d1#diff-50840eb79e3292d148af41006e3af980L1115
I see no problem with libc as it usually provides SSE2/3/4 optimized functions, so should have the same overhead as the D arrayops library.

I see no problem with libc as it usually provides SSE2/3/4 optimized functions, so should have the same overhead as the D arrayops library.

Most of the optimizations in memset/memcpy are geared towards large memory chunks, while keys are likely to be just one or two words (maybe also values). It's too bad GDC and LDC don't do cross module inlining, so they don't gain little by the "inlinable" copy and set operations. Maybe we should make them private helpers inside aaa.d, and fall back to memset/memcpy for sizes > 16.

I ran dfmt on the change and replaced CRLF with LF in rt.util.mem.

Sorry for that. I'll try to integrate checkwhitespace into my workflow...
Is dfmt the defacto standard style now? I don't see many modules using a space after cast().

Sorry for that. I'll try to integrate checkwhitespace into my workflow...

It's now being run automatically on the autotester.

Is dfmt the defacto standard style now?

No.

It's now being run automatically on the autotester.

I don't see any target in the druntime/phobos makefiles. I think it is only checked for dmd so far, isn't it?

Yeah, you're right.  I thought this was a dmd pull request.

Is dfmt the defacto standard style now?

No, but it saves me time b/c I no longer fiddle with formatting.


Logging model events without a logged in user

I would like to log the activity of events that happen on a model just like your example.  Since the create, update, delete functions are being called by an API there is no logged in user.  I'm getting this error when making my API call.
exception 'ErrorException' with message 'Argument 1 passed to BFCampaigns\SourceCode::Spatie\Activitylog\{closure}() must implement interface Spatie\Activitylog\logsActivityInterface, instance of BFCampaigns\SourceCode given' in /app/vendor/spatie/activitylog/src/Spatie/Activitylog/LogsActivity.php:10

Is there a way to assign events without a logged in user to some default system user account?

Here is my implementation inside of my model class
	public function getActivityDescriptionForEvent($eventName)
	{
	    if ($eventName == 'created')
	    {
	        return 'Source Code (' . $this->source_code . '): "' . $this->entry_name . '" was created';
	    }

	    if ($eventName == 'updated')
	    {
	        return 'Source Code (' . $this->source_code . '): "' . $this->entry_name . '" was updated';
	    }

	    if ($eventName == 'deleted')
	    {
	        return 'Source Code (' . $this->source_code . '): "' . $this->entry_name . '" was deleted';
	    }

	    return '';
	}

Your model needs to implement the LogsActivityInterface interface as shown in the log model events section of the README.
By default the code will fall back to an empty string if no user id can be obtained from the Auth provider.
I just made a pull request that enables you to customize this fallback value from the config. With this, you may default to either '' or 0 to indicate "anonymous" or you could create a user model for your system tasks and insert its id.

Worked perfectly, thank you.

No problem!


Add gradle wrapper to project template

Introduce use of gradle wrapper in project template to ensure repeatable builds. Manage gradle wrapper scripts and binary using Flutter tool cache. Update gradle and android gradle plugin versions to address #9842 and #10236.
Notes:

Upgrades new Flutter projects to use gradle wrapper + gradle version 3.3 + android gradle plugin version 2.3.3. This is the configuration used by Android Studio in latest stable version 2.3.3.
PR is morally a retake of #9882, but without distributing the gradle wrapper scripts and binaries using the Flutter repo. Instead, these files are managed by the cache, similar to the engine dependency.
cache.dart has been refactored to avoid duplication across now three cached artifacts (material fonts, engine, gradle wrapper).
There should be no implications for existing Flutter projects.
New projects will get the standard complement of gradle wrapper files in their android folder. These files should be checked into version control.
#10927 is left for a separate task.

cc @abarth @Hixie


Add support for transfer transactions

As raised in https://discord.com/channels/905194001349627914/1235606151488602142
the TransactionPrep function doesn't handle native transfer in which data won't be provided.

Hey @Chengxuan, can I work on this issue?

@MukulKolpe Sure. I'll assign the issue to you. Thanks for helping!

@MukulKolpe are you still picking up this issue?


Add HealthCheck API to Swagger - v2

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[x] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[x] SDK of .NET (need service team to ensure code readiness)
[x] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[x] SDK of Go
[ ] PowerShell
[x] CLI
[x] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of "no breaking changes"
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[x] Check this box if any of the following appy to the PR so that the label "ARMReview" and "WaitForARMFeedback" will be added by bot to kick off ARM API Review.  Missing to check this box in the following scenario may result in delays to the ARM manifest review and deployment.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[x] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

This PR includes a change to add diagnostic API to the swagger spec. This change won't break anything.

Why this is not a Breaking Change Justification -
This API (HealthCheck)  is a diagnostic API which will be used internally by engineering team and the support team. It will not impact any existing API or services in PROD

Why this is not a Breaking Change Justification - This API (HealthCheck) is a diagnostic API which will be used internally by engineering team and the support team. It will not impact any existing API or services in PROD

The breaking change review board is responsible to review your justification and do the approvement.
Please follow this process:
Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.


Native bridge cleanup: Timer

In tabris.Timer, rename the event Run to lowercase run.

Implemented on all platforms.


streaming music platform

Is OrbitDB suitable for streaming music platform and which data model schema better to choose for that?

Sure! Streaming the actual music would prolly come from IPFS. As for the data model schema, that really depends on what your data model is :) For example, you might find success in modeling various schemas through the Documents database model.


[Monitor][Ingestion] Adjust upload error handling

This uses a callback approach where the default callback is 'strict' which raises the first error encountered. Since there is no concurrency, we can tell the user what index in the list of logs failed.
TODO:

Update changelog
Add samples with custom error callbacks

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-monitor-ingestion


skip assert when a model returns tensor

The assertion triggers false positively.
This happens when I use a loss function that returns tensor (not tuple, dict, ...).

/test

/test

/test


JWM: emacs window refuses to be maximized

Should be forwarded to JWM developers?

Apparently Emacs' failure to maximize in JWM is not exactly a bug.
See the fullscreen section at
http://www.gnu.org/software/emacs/manual/html_node/elisp/Size-Parameters.html#Size-Parameters.
Therefore you can make Emacs maximize properly by adding
(setq frame-resize-pixelwise t)
to your .emacs file.


Fixes 1447: add postgres tasking system

Summary

Adds a postgres tasking system to for handling introspect events.
Adds the tasks, tasks/queue, tasks/client, and tasks/worker packages.

tasks/queue

A queue used by client/worker to enqueue and handle the tasks

tasks/client

TaskClient is an interface to enqueue tasks. Right now it's really just a wrapper around queue.Enqueue(task). This is used in the handler layer to enqueue introspect tasks for the create, update, and introspect endpoints.

tasks/worker

worker_pool.go has an interface TaskWorkerPool which is consumed by cmd/content-sources/main.go to configure and start the workers.
worker.go is the individual worker started/stopped by WorkerPool. This is only meant to be used by WorkerPool, not directly. I separated them to potentially allow more control over the individual workers.

Testing steps

Still working on a few things
If you add new_tasking_system: True to your config.yaml, it will use this for introspect instead of kafka.
Should work right now for all endpoints that trigger introspect (create, update, introspect).
For now, if you want to test the tasking system more thoroughly I suggest modifying the introspect handler to do other things, then trigger it via the introspect endpoint.

Todo:

[x] Finish cleaning up repository handler
[x] Add links to the code in the tasking system architecture doc (I'll try this after merge)
[x] Add more tests
[x] Refactor pgqueue db connection such that a transaction can be used to write tests.

https://issues.redhat.com/browse/HMS-1447

could you add a README in the docs directory detailing the arch of the tasking system and explaining its features?

I was trying to add integration/queue tests, but it's actually a lot to think about because the database connection works differently for pgqueue.go, and so decent change probably has to be made there to pass a transaction through to it.
I've pushed up everything else, which should be good to go.

Overall looks good, thoughts on incorporating these metrics into the tasking system?  https://github.com/content-services/content-sources-backend/blob/main/pkg/instrumentation/metrics.go#L105-L117
to capture latency (time from queued and then picked up) and tasking failures (failures with processing, not with external factors like failed repo syncs)

Those should be there already. Are they working?
Latency: https://github.com/content-services/content-sources-backend/blob/68e92b7975ae5518c5dc237b9b2097e75ce7c599/pkg/tasks/worker/worker.go#L81
Result: https://github.com/content-services/content-sources-backend/blob/68e92b7975ae5518c5dc237b9b2097e75ce7c599/pkg/tasks/worker/worker.go#L107-L110

ohhh!  nice work, i overlooked it, let me check!

yes, working great!!

/retest

[test]

/retest


SERVICE_IP interpolation issue

I have a weird issue that I am facing while trying to configure a SERVICE_CHECK_SCRIPT using the SERVICE_IP interpolation just added to the master branch.
Here is my issue -
I have registrator running. It has an IP address of <IP_ADDRESS>. I started up the registrator container with the -internal flag pointing at the host node consul instance.
I have a second container with a service in it. The service is running on port 8080, which is exposed at 8001 to the host. The container has an IP address of <IP_ADDRESS>.
I am using Weave on each host so I can directly ping and resolve the container service <IP_ADDRESS>:8080 from the host machine.
In my service container I declare -
SERVICE_CHECK_SCRIPT=curl $SERVICE_IP:$SERVICE_PORT
If i check the consul logs using consul monitor -log-level=debug on the host. I see -
curl: (7) couldn't connect to host```

The SERVICE_PORT has been interpolated to the exposed port of the actual service (which is fine). However the SERVICE_IP has been interpolated to the IP address of the Registrator container rather than the service container.

If I look at the consul UI backend. I can see the service has been registered correctly with consul as <IP_ADDRESS>:8080 (So I know that Consul and Weave are working properly).

Could this be an issue / bug with the interpolation code, or some slight oddity in my setup ?

I suspect your shell is eating up the variables before Registrator gets to see them. Try
SERVICE_CHECK_SCRIPT='curl $SERVICE_IP:$SERVICE_PORT'
or
SERVICE_CHECK_SCRIPT=curl \$SERVICE_IP:\$SERVICE_PORT
When I decided to use the $SERVICE_ placeholders, I didn't encounter this issue, as my usecase was different; in retrospect, it may have been a bad decision. Depending on the project maintainers' opinions on intra-release compatibility, we may want to change this to something else (eg. #SERVICE_IP#), as I see this becoming a very common question.

I have the same issue without using the -internal flag.

I've added SERVICE_EXPOSED_IP and SERVICE_EXPOSED_PORT

It doesn't seem to work for my case actually. It creates new services.

It may actually be working. Try it ;) I have a problem with consul template constantly restarting my service but it may not be related

My other bugs were completely unrelated. I confirm that my pull request helps here. To sum up:
SERVICE_IP: host ip
SERVICE_PORT: mapped port (usually 49***)
SERVICE_EXPOSED_IP: internal container IP (should be renamed to SERVICE_CONTAINER_IP maybe for clarity)
SERVICE_EXPOSED_PORT: port exposed in the Dockerfile, like 80 for http

Shouldn't this just be fixed in that the service.Origin.IP should be the container IP and not the IP of the registrator container? What would be the purpose of interpolating in it's IP?

It seems to be this line: https://github.com/gliderlabs/registrator/blob/master/bridge/bridge.go#L196-L198
Not sure why the bridge IP is being placed into the service information.

If we start interpolating more than a single variable, than I would really only want a PR that uses Go templating to avoid managing multiple representations of data.
However the service checking stuff is really rough and is likely to change, so I'm not sure how far down this particular rabbit hole we should go if folks have a fork/branch that works now.

Or more specifically, should these lines use service.IP and service.Port and not service.Origin...
https://github.com/gliderlabs/registrator/blob/master/consul/consul.go#L20-L21

+1 same problem here. Really looking forward to the new service-checking stuff!

Tracking this here now: https://github.com/gliderlabs/registrator/issues/233


[Bug]: No transfering card and any activity of when closing channel

Describe the bug
I have closed my channels but I have no indication that I have closed them:

No trace in history
No transfering card

Reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

Screenshots / Recording

Operating system
GrapheneOS
Bitkit version
v118
Log output
No response

I just tried the same and I do briefly get the suggestion and I do see the activity soonafter. Note the tx link in actiivty being wrong is a known UI issue.
https://github.com/synonymdev/bitkit/assets/74595920/2d622611-618e-41d8-9f08-86fac28de9f9

I'm not able to reproduce this so far but the transfer card not being there for mutual closes is expected behavior as to https://github.com/synonymdev/bitkit/issues/1818. The funds are immediately spendable so no need to show a pending time.

It is possible that JC's tx had not yet made it into the mempool and that's why no activity. @JeanlChristophe do you see it now?

I didn't made a transaction by myself, I closed my channels. But the funds disapear also. 5 days after I still didn't received those sats and theyre is no history of it.

LDK logs might help here, do you have a copy @JeanlChristophe?

Also looking into it, his logs are here
bitkit_ldk_logs_1716891357076.zip

Potentially due to getting throttled. This was before the changes went into effect.

Unfortunately I still have the same issue today with another wallet.
https://github.com/synonymdev/bitkit/assets/46056211/0a7cc8d3-adab-4f7f-957e-1769395d7e02

See also: https://github.com/synonymdev/bitkit/issues/1933

Verified in v130 d8f96e7d6475d2eef04ae08f9d9dd2c8894a8218.
We've done multiple channel closes today and activity always shown.


Fixed Password Reset Issue

Fixed the password reset issue

Sorry but I cannot accept this change. If you have found an issue, please describe the problem. Also you have commented out important parts of this project, which makes it impossible for me to accept this change.


Workspace mementos are not properly looked up anymore

Because we lowercase the ID even though it gets stored only in normal case.

@bpasero how to verify?

Sorry forgot, I just did from selfhosting on todays build.


fix: add debtLimit for addVaultType

Fix for https://github.com/Agoric/agoric-sdk/pull/4948#issuecomment-1083649895

Open to ideas on how to avoid breaking in the future. One option is to export a test-utils package from agoric-sdk and have a function that makes test contracts.


Microsoft Teams no longer supported on Version 5

Describe the bug
Launching Microsoft Teams channels yields the message "The page cannot be displayed because an internal server error has occurred."
To Reproduce
Steps to reproduce the behavior:
(Prerequisite - have Microsoft Teams established as a Service)

Click on the Teams channel/logo
View error message.

Expected behavior
Display of my Teams chats.
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: Win 10
Browser Chrome Version 72.0.3626.109 (Official Build) (64-bit)

It was a Microsoft Team server issue. Not Franz related

Yes, Teams is working fine for me on 5.0 across two different tabs/tenants.

Thanks for the feedback - Teams was working fine for me, but I use Franz so I don't have to keep signing in and out of multiple Teams.  It was just not working on Franz but has been resolved.


Unknown blueprint: page-object-helper

Hello.
When I run in terminal:
ember g page-object-helper login
I got an answer:
Unknown blueprint: page-object-helper
In file https://github.com/san650/ember-cli-page-object/blob/master/app/blueprints/page-object-helper.js#L1 imported not existing module.

Hi @DenQ , thanks for reporting this error.
The blueprint was removed for the 1.0 but for some reason we didn't delete app/blueprints/page-object-helper.js file. Maybe we can bring it back and make it generate a dummy descriptor. @DenQ @juanazam @jeradg thoughts?
Also, page object helpers are just functions or descriptors if you need more advanced functionalities.
Here's an example of a custom descriptor (I think we don't have documentation for this on the http://ember-cli-page-object.js.org/ site yet.)
import { findElement } from 'ember-cli-page-object';

export default function disabled(selector, options = {}) {
  return {
    isDescriptor: true,

    get() {
      return findElement(this, selector, options).is(':disabled');
    }
  };
}

I usually put my page object's helpers on /tests/pages/helpers/, you can do the same without the blueprint for now.

@san650: I like the idea of having a generator for properties/actions/descriptors. We could even have a couple of different blueprints for different custom property/action use cases.

http://ember-cli-page-object.js.org/docs/v1.3.x/migrating#customhelper
I'm :+1: on creating the descriptor blue print.


Solidify viewport descriptor (aka View) support

This is a proposal, for exposition.
The basic idea is that deck will take a list of "view descriptors" in preference to viewports.

This will allows deck to auto calculate the actual viewport sizes without passing in exact width and height to every viewport.
Percentage widths and heights  (and x, y) can also be supported for viewports, significantly simplifying complex viewport layouts in apps.
Going forward, we can add new parameters to each view, such as layer filters etc, while keeping our Viewport classes laser focused on projection related tasks.
Also the view descriptors can take viewState objects, closing the loop on that line of development.

Will on a new PR on 4.2-dev


EC2 summary is confusing a bit

In my report I got:
(14) running on-demand EC2 VPC instances
(13) EC2 VPC reservations
but actually out of 14 instances just 5 are not reserved, so report should say something like 5 on-demand and 9 reserved instances

this should be alleviated further by #25 which will list the count of unreserved instances


reenable all tests on Windows

@bors r+

:pushpin: Commit e7b39e382a71882546528693ea8ed8125580fcde has been approved by RalfJung

:hourglass: Testing commit e7b39e382a71882546528693ea8ed8125580fcde with merge b0975a7dd5e9b0ba25c14db0771b48fc1dda59d3...

@bors r+ retry

:pushpin: Commit f8c6eb5e8c98d1ff623361d287c6e5af1943ba65 has been approved by RalfJung

:hourglass: Testing commit f8c6eb5e8c98d1ff623361d287c6e5af1943ba65 with merge c81625030c42c7431185cde821c3dff7ac3c0681...

@bors retry
AppVeyor did not show up

:hourglass: Testing commit f8c6eb5e8c98d1ff623361d287c6e5af1943ba65 with merge b5ddc94bf02c641e5acbb08ae742014f40347f10...

:sunny: Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing b5ddc94bf02c641e5acbb08ae742014f40347f10 to master...


Refactor Web MaterialXView

Changes

Create Viewer, Editor, Material and Scene classes to organize functionality
Change material and geometry changes to not reload the entire page causing everything to be re-initialized. Instead perform incremental updates.
Small fix to get any UI names if looking up an interface input

Example

Sample session capture to show how material and geometry can be independently re-loaded.

Sample capture of geometry change while material changes are preserverd

This looks really promising, thanks @bernardkwok!  Could you post a link to a deployment of the updated site, so that we can get a sense of how it works in practice?

This looks really promising, thanks @bernardkwok! Could you post a link to a deployment of the updated site, so that we can get a sense of how it works in practice?

The deployment can be tried out here.](https://kwokcb.github.io/MaterialX/).

This looks excellent, thanks @bernardkwok.  I'll give it a day or two for others to comment, but my instinct is to merge this change ASAP.


Added support for a JSON health endpoint

Rebased #31 on top of the current master to get it finally merged.

@codingjoe I refactored the view to return the status with the Accept: application/json header and added tests for the JSON output. I'll rebase the commit chain on top of the 2.0 rewrite later to keep the old attributions here.

Up-to-date PR in #80.


[Discussion] refactor getCurrentCell and getCell (Multi-Grammar Bug)

The Discussion
While implementing markdown results (#1628), I skipped multi-grammar files in my testing. It appears that I have broken previous functionality because of my implementation (#1636). I began attempting a fix under #1637, but I have run into a few problems. The main problem being that getMetadataForRow is not aware of scopes. Giving awareness is easy, however it would require a range. The reason giving a range is a problem is because cell ranges do not include the cell header/metadata. This means that while searching for the cell header of a line inside scope, it will search outside of scope if it doesnt find one inside scope.
My Request

Change getCurrentCell and getCell to return { range: atom$Range, cellType: HydrogenCellType }
Allow getCell and getMetadataForRow to accept a scope (atom$Range) to search within.
Rename getMetadataForRow to _getMetadataForCell making it private since it will be returned with get getCell
Rename getCell to _getCell since it is not exported currently anyways

These changes will help me properly implement cells for multi-grammar scopes.

Please respond with critiques, concerns or approval. If we approve, I'll create the PR for the refactor and the fix to #1636.
CC: @BenRussert, @aviatesk

Issue Resolved: Multi-Grammar Scopes do not support cells.


CI: check version before release

We tend to forget updating version.py when releasing a new version.
Let's add an Action to update it automatically or at least abort if version.py != tag.
See https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release
Related: https://github.com/fireeye/capa/issues/184

Do we necessarily need to do this for capa v1.6.1? With the release documentation, I think now it is more difficult to forget this and I don't think it is a priority.
I am changing this to the v2.0.0 milestone and assigning it to myself. Let me know if you are not ok with this.

Yes, that sounds good to me!

Will this be worth the effort or are we good with the release check list?

Let's rely on the release checklist and reopen this if it fails just one more time 😉


Rejecting 101 requests - Ratchet\App - WSServer (Authentication)

A similar question to #604.
Currently I am extending the WebSocket\WS server in order to provide authentication on upgrade.
However, I am looking to move to the PubSub model using the provided WAMP server.
There seems to be no easy way to inject the below functionality into the \Ratchet\App instance.
I am able to close connections if not authenticated using httpRequest on connection, however, I do not wish clients to "Upgrade" at all.
The following works on a basic WS model.
// OurWsServer.php

class OurWsServer extends WebSocket\WsServer
{
    use CloseResponseTrait;

    /**
     * Handles authentication before allowing upgrades
     *
     * @param ConnectionInterface $conn
     * @param RequestInterface $request
     * @return void
     */
    final public function onOpen(ConnectionInterface $conn, RequestInterface $request = null)
    {
        // Headers
        $headers = $request->getHeaders();

        // Singular JWT token
        if ($headers['Authorization'] ?? null) {
            $headers['Authorization'] = array_pop($headers['Authorization']);
        }

        // Request object to code application
        $symfonyRequest = new Request([], [], [], $headers);
        $parameters = (object)[];

        // Reject
        if (!IsAuthenticated::handle($symfonyRequest, $parameters)) {
            return $this->close($conn, 401);
        }

        parent::onOpen($conn, $request);
    }
}

Server setup

// snip

// WS server
$wsServer = new OurWsServer($app /* Our app implementing MessageComponentInterface */);

// Origin check
$wsServer = new OriginCheck($wsServer, self::ORIGINS);

// HTTP server
$httpServer = new HttpServer($wsServer);

// IOServer
$server = IoServer::factory($httpServer, self::PORT);

Test

use Ratchet\Client as Ratchet;

// Snip

public function testShouldAcceptAuthorisedUsersConnecting()
{
    $loop = Factory::create();

    // React
    $reactConnector = new React\Connector($loop, [
        'timeout' => 2
    ]);

    // Ratchet client
    $connector = new Ratchet\Connector($loop, $reactConnector);
    $promise = $connector('ws://localhost:8081', [], [
        'Authorization' => $_COOKIE['Authorization']
    ]);

    // Sync - block promise for testing
    try {
        $conn = Block\await($promise, $loop, 2);
    } catch (Exception $e) {
        $conn = null;
    } finally {
        $this->assertTrue((bool)$conn);
    }
}

Is there a way to achieve the above using the \Ratchet\App or would I have to extend the above?
Many thanks for support in advance,
Mike

I would recommend creating your own class that implements HttpServerInterface. This class should live between the HttpServer and WsServer layer.
I don't quite understand the goal or the problem though, could you elaborate please? Connections that are authorized need to upgrade if they're going to speak WebSockets, including using the WAMP protocol.

Hello,
Many thanks for your assistance.
What I've now done instead is taken a look at the Ratchet\App and implemented the following snippet.
Rejecting the connection at the ws server level (so tcp connections should also be rejected through raw sockets).
// snip

/**
     * WS Server factory that implements authentication before upgrades.
     *
     * @param WampServer $wampServer
     * @return WebSocket\WsServer
     */
    private static function wsServer(WampServer $wampServer): WebSocket\WsServer
    {
        /**
         * This is a basic extension of the WebSocket server Ratchet provides.
         *
         * The onOpen method is being overridden in order to provide auth behaviour when attempting to upgrade (101).
         * If a client attempts to connect without a token then the upgrade request is rejected entirely.
         */
        return new class($wampServer) extends WebSocket\WsServer {
            use CloseResponseTrait;

            /**
             * Handles authentication before allowing upgrades
             *
             * @param ConnectionInterface $conn
             * @param RequestInterface $request
             * @return void
             */
            final public function onOpen(ConnectionInterface $conn, RequestInterface $request = null)
            {
                // Headers
                $headers = $request->getHeaders();

                // JWT token
                if ($headers['Authorization'] ?? null) {
                    $headers['Authorization'] = array_pop($headers['Authorization']);
                }

                // Request object to code application
                $symfonyRequest = new Request([], [], [], $headers);
                $parameters = (object)[];

                // Reject
                if (!IsAuthenticated::handle($symfonyRequest, $parameters)) {
                    return $this->close($conn, 401);
                }

                parent::onOpen($conn, $request);
            }
        };
    }


Sync the online docs

I just revisited this project due to a friend's notice, and realized that the contents of docs.phinx.org and the docs/ folder are not the same, especially when it comes to creating tables and such.
Could you possibly update the online docs?

What branch are you looking at? As far as I know the documentation online is the latest stable release (0.4.x) whereas the latest stuff on GitHub is on the development branch (0.4.x@dev)

Hi @IngwiePhoenix the docs are built off master and yes the changes in 0.4.x-dev need to be merged. That has now been done and will automatically update shortly.

Yeah I was reffering to the default branch seen on Github. I usually dont touch the branch selector mostly because it tends to point at a currently working version.


Validation swallows real errors, when they occur within a validator.

Reproduce like this:
ValidationGroup.prototype.test = function()
{
	this.passes((newValue, threshold) => {
		let x = null;

		x.y = "This causes a null reference error.";

		return threshold;
	});

	return this;
}

If you try this, you will get this in the console:
Uncaught (in promise) Error: Unexpected behavior: a validation-rules-collection should always fulfil(…)(anonymous function)
@ validation-property.js:79

The message is pretty unclear, too, but at least it should emit the actual error, if possible.

Thanks for submitting this / commenting on this.  At this time we are closing this because we have completely re-written and are deprecating the previous feature set.  If you feel this should be re-opened please feel free to review this blog post and submit either again on this repository, or on the new validatejs bridge repository
Thanks again!


better threading docs required. & onContactsDataSourceReadySignal is not always dispatched to the main thread

onContactsDataSourceReadySignal
2016-11-07 06:30:07.113 OhanaExample[71212:3367760] <NSThread: 0x7f83a6492460>{number = 2, name = (null)}
I think this was caused by the OHABAddressBookContactsDataProvider calling back on a background thread.
There's a generally larger task required here: Ohana's threading isn't very well defined.
We've generally assumed operation on Main. This is fine, but the contract with dataProviders and postProcessors should be better defined to dictate how they can offset work.

I can feel that we should always be on main thread in our callbacks. I wonder if @Darj should complete a possible RxSwift conversion before tackling this

yes, we should build this assumption into the framework.

Yeah from memory all this pain was to do with the callback assumptions from UBSignals, the docs should be more explicit. While the Rx port will 'fix' this we should still update it here at some point.


Dont like the newest update :(

I acctually hate the newest update, people want the app to be easier, and easier to mass-download.
With this newest update, It will take for ever to download MANY stories.
Instead you should still fix the "download all stories" like I have wanted before :)
Thanks for an good app, and good job, but please dont make it worse and worse :)

+1

Up up up.....
Cmon @CaliAlec bring back the old version ~


draft: Add Arbitrary

Adds an example draft showing what is needed to use Arbitrary for coin selection.
Shot out to how nice Arbitrary is for fuzzing a target by taking unstructured randomness and creating structured rust-bitcoin types for fuzzing.  Is there a way we could add this to rust-bitcoin for structuring the fuzz data needed?
This is then the example to fuzz test a SRD algo (after applying this PR to rust-bitcoin) using rust-bitcoin types :)
#![no_main]

use arbitrary::Arbitrary;
use bitcoin::{Amount, FeeRate};
use bitcoin_coin_selection::{select_coins_srd, WeightedUtxo};
use libfuzzer_sys::fuzz_target;
use rand::thread_rng;

#[derive(Arbitrary, Debug)]
pub struct Params {
    target: Amount,
    fee_rate: FeeRate,
    weighted_utxos: Vec<WeightedUtxo>,
}

fuzz_target!(|params: Params| {
    let Params { target: t, fee_rate: f, weighted_utxos: wu } = params;
    select_coins_srd(t, f, &wu, &mut thread_rng());
});

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 4 (0.0%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 83.08%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

bitcoin/src/blockdata/script/owned.rs
0
1
0.0%

bitcoin/src/blockdata/transaction.rs
0
1
0.0%

units/src/amount.rs
0
1
0.0%

units/src/fee_rate.rs
0
1
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-0.01%

Covered Lines:
19587

Relevant Lines:
23576

💛  - Coveralls

Do we want derives for this? It only affects fuzzing which takes much longer than derive anyway.

I'm not sure what the other option would be right now.  Obviously this dep shouldn't be included as part of the build and only be conditionally compiled for use with fuzzing.

Definitely needs to be feature-gated. Implementing on Script is likely to be hard and won't be derivable. But the stuff that just wraps u64s and whatnot definitely can.

I'm not sure what the other option would be right now

Implementing it manually.

To fix the CI failures, the lock files need to be updated, but the minimal lockfile can't be updated until MSRV is updated to 1.63

I think arbitrary 1.2 should work since it's nearly 2 years old. Possibly 1.3.0 as well. If it turns out to be too onerous to support these old versions (which presumably are missing some new features) then we can wait for the MSRV bump.

Technically even 1.0 should work.

Technically even 1.0 should work.

Why is that?

The API wasn't broken so it's safe to assume the trait is the same, maybe minus some default methods.

Couldn't there have been compiler features in 1.56.1 that where not available when 1.0 of Arbitrary was released?

Oh, I'm not saying MSRV is right. Just that 1.0 is more permissive since we probably won't rely on API of a higher version.

This is just a small subset of types.  I added Arbitrary to these because these are the types needed for coin-selection and can be used with fuzz tests and proptests (arbtest).  I'm ok with circuling back around and adding Arbitrary for other types, can probably be done for most by running a regex over the codebase.  Or we can just let them be organically added.  I just don't want to be accused of making un-ergonomic changes :P

I would strongly prefer not to use derive because it pulls in syn 2 and will slow down compilation. And it's not even what we want for ScriptBuf because scripts have much more structure than raw vectors.

I would strongly prefer not to use derive because it pulls in syn 2 and will slow down compilation. And it's not even what we want for ScriptBuf because scripts have much more structure than raw vectors.

Ok, I can work on pulling out derive.

@yancyribbens looking at it, most of those are trivial so I suggest you add a decl macro trivial_arbitrary! to internals gated on arbitrary that simply uses Self(u.arbitrary()) and just call that for most types.
@apoelstra hard to say what to do about ScriptBuf. It has no invariants because you can put garbage into the chain (remember some famous bugs) so I think Arbitrary ought to return it but we might want to also provide a method returning a script that is not a complete garbage - has no out-of-range pushes. I think creating a method returning perfectly valid script (that returns TRUE) is too much work for questionable value.

@Kixunil I think we want to switch on the first random byte or something, and for script, choose between:

a passthrough to Vec<u8>
a valid script (in the sense of parsing correctly, not in the sense that it can actually be executed; it can use invalid opcodes, have imbalanced IF/ENDIF, etc)
an OP_RETURN script (which can use all the push opcodes including OP_RESERVED)
same as above but with a truncated push
an open-ended list of special cases (like the thing in testnet with a gazillion CHECKSIG opcodes, etc)

and we should make sure that we're using the non-minimal push modes.
I'm ambivalent on having the trivial_arbitrary! macro. If you like having the smaller code you should do it. Though it's only a couple lines per type to write it out explicitly.

That's a very interesting idea! Is that some kind of known prop testing technique? It might still be interesting to have methods to select the strategy explicitly but perhaps this is too involved and should be left for the users.

I'm ambivalent on having the trivial_arbitrary! macro.

I'm starting to think for this kind of write-once-read-often boilerplate code its better to not use macros, but I'm not 100% sure.

And it's not even what we want for ScriptBuf because scripts have much more structure than raw vectors.

I don't really need ScriptBuf at the moment actually (only TxOut).  What just using ScriptBuf::new() for now and then adding it with a next PR?

I don't think the CI fail is related.  Looks like new lints dropped.

I think creating a method returning perfectly valid script (that returns TRUE) is too much work for questionable value.

Isn't the point of at least fuzz testing, to create arbitrary data thats invalid (as well as valid)?  I mean, invalid data should be tested if it's possible to receive that data so that the possibility of a panic or other unexpected behavior can be avoided..

What about just using ScriptBuf::new()

If you mean always returning an empty ScriptBuf then no, that's just invalid implementation so we should rather not have it at all.

That's a very interesting idea! Is that some kind of known prop testing technique?

It's a fairly standard fuzztesting technique. In some sense it's a straightforward generalization of the proptesting "try extreme values" strategy. With proptesters I think usually you have some sort of explicit "strategy" knob rather than manually reading a byte and switching on it like this. But as discussed we don't have that with the Arbitrary trait.
Another idea to switch strategies is to use thread locals, with our Arbitrary impl reading the threadlocal and our proptests somehow setting it on test start.
@yancyribbens the CI failures look like they're in your code and there can't be any "new lints dropping" because we've pinned all the compiler versions. (Actually, they can drop in the stable compiler, which we don't pin, and this did happen recently ... but it hasn't happened twice in one year IIRC. If it does then we'll pin that too.)

I'm starting to think for this kind of write-once-read-often boilerplate code its better to not use macros, but I'm not 100% sure.

I would kinda like to have an explicit codegen binary that we run in CI so that the checked-in code is unrolled but the code we write is generated. (In another project I used PHP for this. I understand people really hate PHP for various reasons, but like, it's a strict improvement over the C preprocessor. I think that's the mindset you gotta approach it with.) But this is a separate discussion.

I would kinda like to have an explicit codegen binary that we run in CI so that the checked-in code is unrolled but the code we write is generated.

This has the issue that if you somehow change the written code and don't keep the old version then you have to manually update everything. And checking in generated code causes horrible merge conflicts. Rather than that I'd suggest using the xtask pattern to generate the code when publishing which would improve downstream compile times and people could use the tool to expand the code but we'd avoid the downsides.

This has the issue that if you somehow change the written code and don't keep the old version then you have to manually update everything.

I don't understand this. If you update the generated code, you need to do so by updating the source file and regenerating. If you do anything else then CI will fail.

And checking in generated code causes horrible merge conflicts

Yes, we'd have to be careful to keep the generated code in its own files or at least in parts of files that are rarely touched. For example in all our uses of internal macros in hashes I think we already satisfy this requirement (we have at least one impls-only file, and the rest of the macros appear right after struct definitions near the top of the file where we never change stuff).

we'd avoid the downsides.

It sounds like we'd need an extra tool that wouldn't be regularly exercised and our own code would still be hard to read.
Though the xtasks pattern does sound potentially interesting in general. Maybe it could replace some of our shellscripts and justfile stuff.

I don't understand this.

If CI did just macro expansion - that means removing the macro call from its original location like rustc does then it'd fail. I don't want to write codegen in some arcane language if it's not absolutely required, so I don't know what else you're proposing rather than macro expansion.

Yes, we'd have to be careful to keep the generated code in its own files

It doesn't help much. Any two people changing the same macro call in different places would cause conflict. Or one editing the macro and the other an input.

It sounds like we'd need an extra tool that wouldn't be regularly exercised and our own code would still be hard to read.

You run the tool if you want to read the expanded code - addresses both.

I am definitely not proposing to edit files in-place!

OK, great!

pretty basic string substitution and maybe looping.

Please no. We start with that and end with a DSL competing with proc macros that only three of us will know. (Or two, if I rage quit because of it.) If you really have to do it (which I hope not), just run the nightly rustc expand command on a file with decl macros.

Then you have a dirty tree?

Maybe, depends on where you store it. We can of course .gitignore standard locations. Anyway, I was thinking of stdout being the default (but highlighting would be great).

How do you clean up the expanded code when you're done reading it?

We might store it in target, or just have a command for cleanup.

We are talking about code that we basically never touch.

Which is it? We're touching basically everything.

Please no. We start with that and end with a DSL competing with proc macros that only three of us will know. (Or two, if I rage quit because of it.) If you really have to do it (which I hope not), just run the nightly rustc expand command on a file with decl macros.

I'm not sure how we jump from "we can use literally any language" to "we will end up with a DSL". But sure, we can try to use  macro_rules! and the rustc expand command, if that works. (I'm skeptical because I think this tries to expand all macros even println! and write! and so forth and the result is likely to be overwhelmingly stdlib junk.)

Then you have a dirty tree?

Maybe, depends on where you store it. We can of course .gitignore standard locations. Anyway, I was thinking of stdout being the default (but highlighting would be great).

This sounds completely unusable. You can already (try to) use the rustc expand command if you want to see code outside of the codebase in a separate program from your text editor.

Which is it? We're touching basically everything.

If you mean the trivial_arbitrary macro then we can put all the arbitrary impls into separate files, which would be nice anyway since they're basically noise. Or we can just put them after the struct definitions, which (almost) never change. Though then we'd need to figure out how to inject generated code into specific locations which will be a PITA.
Same story with the hash_newtype macros and all the other "impl a standard trait in a boilerplate way" macro.

If you mean always returning an empty ScriptBuf then no, that's just invalid implementation so we should rather not have it at all.

@Kixunil Ok, I've added ScriptBuf, although since I don't currently use it, it's hard for me to weigh-in on how it should be implemented beyond just the basic use case.

the CI failures look like they're in your code and there can't be any "new lints dropping" because we've pinned all the compiler versions

@apoelstra oops and thanks, it was a problem with my PR.  Good to know the compiler is now pinned, although it was kind of fun before, like winning the anti-lottery xD
The conversation has spiraled to a point where I'm not sure where to begin.  I think what is being said is that manually implementing the impls is going to be more work then using a macro that creates the impls for us when people update and change the types that we want as Arbitrary.  Although isn't all this something we can improve as we go?

I'm not sure how we jump from "we can use literally any language" to "we will end up with a DSL".

Well I really don't want to write imperative codegen if we can write declarative. Just compare declarative macros and procedural. Procedural are totally unreadable compared to declarative. Anyway, if we definitely cannot write something declaratively (which is super rare) then the biggest reason to use Rust is that we have the syn crate.

I'm skeptical because I think this tries to expand all macros even println! and write! and so forth and the result is likely to be overwhelmingly stdlib junk.

That's a good point also for another reason: some std macros use unstable library internals to achieve what they want so after expansion the information is lost and the code is broken. But maybe the expansion can be filtered somehow.

You can already (try to) use the rustc expand command if you want to see code outside of the codebase in a separate program from your text editor.

Yes, and I think we should just stick with that.

If you mean the trivial_arbitrary macro then we can put all the arbitrary impls into separate files, which would be nice anyway since they're basically noise.

Right, but I don't see writing and maintaining a complicated imperative codegen with a complicated CI setup and bunch of other issues to deal with as worth making a ~10-line macro more readable.
@yancyribbens

it's hard for me to weigh-in on how it should be implemented beyond just the basic use case.

I think it's completely fine to do a trivial impl first and improve it over time.

Although isn't all this something we can improve as we go?

Yes, it is.

Ok, at some point I will try to implement this and we can discuss a specific implementation. Iterative codegen isn't necessarily unreadable (e.g. the shellscript that generates our fuzz CI file is basically just a giant echo statement with some surrounding logic to get a list of targets). Nor is the CI infrastructure necessarily complicated and hard to deal with (again, see the way we generate the fuzz CI file).
It is a bit annoying and always takes a few tries to change, but we rarely do this and meanwhile reading is easier.
Interesting thought that if we use Rust macros we have syn... I'm not sure if you intended this, but one idea this could lead us to is being able to generate serde (and arbitrary) impls with an external tool that uses syn, and then our actual committed codebase would just contain the generated code. So it'd compile quickly and not need a syn dependency.
Anyway this isn't something I plan to do soon, and I think we've said enough here that I have an idea what sort of implementations might be acceptable to you.

but one idea this could lead us to is being able to generate serde (and arbitrary) impls with an external tool that uses syn, and then our actual committed codebase would just contain the generated code. So it'd compile quickly and not need a syn dependency.

I strongly suspect that would need forking the derive macro and patching up things though maybe it's not too hard. Might be worth the effort for large things.

This PR does not build for me locally with cargo test --features=arbitrary

For me it builds fine, although I do get a seemingly unrelated test fail:
---- src/sha256t.rs - sha256t::sha256t_hash_newtype (line 169) stdout ----
error[E0433]: failed to resolve: use of undeclared crate or module `io`
  --> src/sha256t.rs:171:1
   |
5  | / sha256t_hash_newtype! {
6  | |     /// Optional documentation details here.
7  | |     /// Summary is always generated.
8  | |     pub struct FooTag = hash_str("foo");
...  |
13 | |     pub struct FooHash(_);
14 | | }
   | |_^ use of undeclared crate or module `io`
   |
   = note: this error originates in the macro `sha256t_hash_newtype` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: use of undeclared crate or module `io`
  --> src/sha256t.rs:171:1
   |
5  | / sha256t_hash_newtype! {
6  | |     /// Optional documentation details here.
7  | |     /// Summary is always generated.
8  | |     pub struct FooTag = hash_str("foo");
...  |
13 | |     pub struct FooHash(_);
14 | | }
   | |_^ use of undeclared crate or module `io`
   |
   = note: this error originates in the macro `sha256t_hash_newtype` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 2 previous errors

@tcharding is that the error you get or it doesn't build at all?

To get CI coverage you need to update bitcoin/contrib/test_vars.sh with the new feature.

Hmm ok, I'll take a look.

Actually, they can drop in the stable compiler, which we don't pin, and this did happen recently ... but it hasn't happened twice in one year IIRC

Unrelated to this thread but we should really pin stable. We missed this one but it's clear that there's no stability guarantee, even an "in practice" one.
https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374

I'm actually having a trouble getting the tests to run on master at all.  Seems like something got passed CI.  Will start an issue for it.

Ah whops this is not news then.  I tested tobins branch and it passed.

Ah whops this is not news then. I tested tobins branch and it passed.

This comment is for issue 3205

I'm guessing you ran cargo test --features=arbitrary from the crate root. Try cding into bitcoin and running it. And yes cargo does not behave that intuitively with workspaces.

@apoelstra we would've caught that one in nightly tests. But I still want to pin stable of course.

Yes, and then we would've filed a bug immediately after it appeared, just like we did with https://github.com/rust-lang/rust/issues/110475, and then they would have refused to fix it for 3 months and instead released it in stable (which they did then and which they did with the time thing) and then we would have had to deal with it in stable anyway.
But ok, we agree that we should pin stable :).

I've fixed the build problem that tobin found, however now CI is failing and I'm unable to reproduce locally.  I'm not sure if this is a problem with this PR or something with CI.  Specificaly, I see a fail on CI when running cargo --locked build --no-default-features --features='rand serde secp-recovery bitcoinconsensus base64 ordered' using the nightly toolchain but for me that command runs fine.

@apoelstra interesting. That's a real weird one but I can imagine we would've had enough time to fix the code. Still, pinning everything is the right choice.

@yancyribbens it triggers if you do it in the bitcoin/ directory.
I'll try to rebase #3195 and also fix this so that by the time Tobin is up we'll have a fix that he can review (and hopefully Kix has acked).

https://github.com/rust-bitcoin/rust-bitcoin/pull/3220 should fix everything. Though the errors in current CI originate in #2892 which was merged 2 months ago, so I am investigating why it's only now that CI is failing. (Presumably it was because of the extra checks that #3200 added ..... but why did CI on #3200 itself then pass?)

(Sorry to spam your PR with this nonsense.)

No problem.  Thanks for the help identifying the problems with CI.

I think this is good to go once we get the Result conversation above figured out.

To get CI coverage you need to update bitcoin/contrib/test_vars.sh with the new feature.

I forget to investigate this comment.  Taking a look.

Ok, I believe this very long running PR is a merge candidate

BOOM!


Fix onnx export preprocessors save

Bug introduced in https://github.com/huggingface/optimum/pull/897 as well

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.


zaz: init at 1.0.0

Motivation for this change
Pretty "famous" foss game (you can find it in most repos)
Things done

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

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

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

@fgaz Thanks for the package!
@jonringer Thanks for the review, it helped me greatly in testing it :)


feat(torii): enable any build (not just wasm) to connect to Slot

Description
We couldn't connect to a remote Slot using dojo.c. Only the Unity game built with a web build could connect.
This PR fix this issue. Thanks @steebchen for the help to understand what was wrong.
The issue was that GRPC didn't handled the right uri, we are now using with_origin method to connect to GRPC.
There is also a part of the code retrieving the public certs to handle HTTPS.
Added to documentation?
Once dojo.c uses this commit, we can update the doc to say that any build can connect to Slot, not just wasm.
Checklist

[X] I've formatted my code (scripts/prettier.sh, scripts/rust_fmt.sh, scripts/cairo_fmt.sh)
[X] I've linted my code (scripts/clippy.sh, scripts/docs.sh)
[X] I've commented my code

Summary by CodeRabbit

New Features

Enabled TLS support by updating the tonic library to version 0.11, enhancing security for communication.

Chores

Added openssl as a workspace dependency to support TLS functionality.

Refactor

Improved connection handling in the WorldClient to support SSL/TLS based on URI, ensuring secure connections.

I need to remove all the unwrap to avoid crashes.
I also have an error when I import the library made with dojo.c in my c++ project, some ssl symbols are missing

@glihm would like to have your review on this one please. I need to know if importing openssl is ok, and also is openssl import mandatory: I'm not 100% sure fetching the certificates is the right way to do this. Maybe we could use another certs and avoid the openssl import.
Also I didn't changed how it worked with http, so that localhost server still works, but we could also handle the "with_origin" like I did with https so that we can handle http url where torii is not exposed at the root domain (localhost:8080/torii for example)
I am currently trying to use 1.0 with dojo.c but the FieldElement/Felt changes is a lot of work, so I didn't test using dojo.c, I only had a temporary test to run from the dojo repo:
#[cfg(test)]
mod tests {
    use super::*;

    #[tokio::test]
    async fn test_client_new() {
        let torii_url = "https://api.cartridge.gg/x/spawn-and-move-cubzh/torii".to_string();
        let rpc_url = "https://api.cartridge.gg/x/spawn-and-move-cubzh/katana".to_string();
        // let torii_url = "http://localhost:8080".to_string();
        // let rpc_url = "http://localhost:5050".to_string();
        let relay_url = "/ip4/<IP_ADDRESS>/tcp/9090".to_string();
        let world = FieldElement::from_hex_be("0x7efebb0c2d4cc285d48a97a7174def3be7fdd6b7bd29cca758fa2e17e03ef30").unwrap();
        let models_keys = None; // or Some(Vec<KeysClause>) if you have keys

        let client = Client::new(torii_url, rpc_url, relay_url, world, models_keys).await;

        assert!(client.is_ok(), "Error creating client");
    }
}

The test was not passing with the api.cartridge.gg domain at the beginning and now it works. So I guess it will also work when used with dojo.c.

@glihm Thanks for the review, I found another way to do it without openssl with a feature of tonis tls-roots. It's working with 0.0.73, but had troubles testing with 1.0.0-alpha.


Update title.json

Added granted slots and stats to huge ships, added images.

Closing due to inactivity


Ensure invitations are sorted descending by association expiry date

Ensure invitations are sorted descending by association expiry date

CI: No security warnings found


feat: CLIN-3090 Save logs and move initialization logic to PIPELINE_INITIALISATION

Warning: THIS IS A DRAFT, NOT READY FOR REVIEW
THIS PR IS TOO BIG, I WILL SPLIT IT.
Changes:

Modified PIPELINE_COMPLETION workflow to save nextflow log file in specified output directly
Move initialization logic from PostProcessing workflow to PIPELINE_INITIALISATION workflow
Fix issues with test sample sheet:

urls not found for gvcf files
wrong column name
one line per family instead one line per sample

Note:
The copied log file is not entirely complete. It will miss a few logs from the completion handler and other Nextflow internal handlers (e.g., reports). However, the missing logs should not contain any critical information for debugging.
Tests description
I run the linter and double check that there is no new warning in comparison to the main branch. Actually we have 39 warnings instead of 41 because. I fixed 3 TODO comments warnings and there is one new warning because there is a new  version available for one of the nf-core module that we are using.
 nf-core lint
╭───────────────────────╮
│ LINT RESULTS SUMMARY  │
├───────────────────────┤
│ [✔] 159 Tests Passed  │
│ [?]  37 Tests Ignored │
│ [!]  39 Test Warnings │
│ [✗]   0 Tests Failed  │
╰───────────────────────╯

I run the pipeline locally in stub mode. It completed successfully in all these cases:
nextflow run main.nf -stub -profile test
nextflow run main.nf -stub -profile test,docker
nextflow -log "foo.log"  run main.nf  -stub-run -profile test,docker
nextflow -log "foo bar.log"  run main.nf  -stub-run -profile test,docker

I verified that the nextflow log file was correctly copied to ./results/pipeline_info/nextflow.log in all cases.
Extra tests needed:

Try with the -log option
Run on juno with S3 url for the outdir
investigate if there are unit testing options without introducing nf-test

PR checklist

[x] This comment contains a description of changes (with reason).
[ ] If you've fixed a bug or added code that should be tested, add tests!
[x] If you've added a new tool - have you followed the pipeline conventions in the contribution docs
[x] Make sure your code lints (nf-core lint).
[ ] Ensure the test suite passes (nextflow run . -profile test,docker --outdir <OUTDIR>).
[ ] Check for unexpected warnings in debug mode (nextflow run . -profile debug,test,docker --outdir <OUTDIR>).
[x] Usage Documentation in docs/usage.md is updated.
[ ] Output Documentation in docs/output.md is updated.
[ ] CHANGELOG.md is updated.
[x] README.md is updated (including new tool citations and authors/contributors).

Closing pull request as it is already addressed through other PRs.


Add make-dylan-app functionality

This will be much like make-dylan-app, but will also

add the new app to the active packages in the current workspace.
run git init, maybe?
accept a list of dependencies to add?
dylan new should offer to create packages if they don't exist.
Always create them in the workspace top-level directory, regardless of current dir.

Current status: always creates a new package; needs to work inside an existing package.

Previous comment meant, for example, don't generate a pkg.json file if one already exists in the current directory or one of its parents.
Also I notice that library.dylan imports io/format-out but doesn't use it in the module definitions.

Also to do: When --executable is used we should generate a library for the executable, a test library, and a library that has the actual implementation so that both of those libraries can use it. This is a bug in the current implementation, as the test suite will currently run the exe.

I think all of the above is done.


Handling objects_handle.py dependencies

Eliminated the dependency on visualization library in objects_handle.py from pyfluent-ui repo, while using the object definitions from visualization library.

@seanpearsonuk, @ajain-work and @hpohekar -> closing this PR as this is no longer relevant. Please confirm once.
Thank you.


Workbench is failing to connect to the server.

ADD ISSUE DESCRIPTION HERE
Version: 1.81.1
Commit: 6c3e3dba23e8fadc360aed75ce363ba185c49794
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36
Embedder: codespaces
When I attempt to load up my codespace I receive this message.
The workbench failed to connect to the server (Error: connection record disposed by ConnectionHub: {
"errorMessage": "Failed to start VS Code Remote server.",
"originalErrorType": "",
"errorCode": -1,
"errorType": "GenericError",
"stack": "Error: Failed to start VS Code Remote server.\n at [CODESPACE_URL]\n at [CODESPACE_URL]\n at [CODESPACE_URL]\n at [CODESPACE_URL]\n at d ([CODESPACE_URL]\n at a ([CODESPACE_URL]"
} $1 $1)
This occurred after my codespace failed to retrieve the max.zip file through the wget command. I reloaded my space and it would no longer load.

I managed to recover my workspace. Thank your for assigning someone so quickly. Going to close the ticket.


ISPN-7298 PrimaryAckCommand must send the DeltaAware instead of its D…

…elta
https://issues.jboss.org/browse/ISPN-7298

Looking

@pruivo This fixes the issue, waiting only for CI before merging it.

Integrated. Thanks!


Update verify check to handle new pom files

Fixes #9650.
This updates the github workflow check to properly check for newer build files that needed to be added for Scala 2.13 and shows the diff properly for those files and any changed files.

build

build


Bug: when building with -overlay, trap will not be generated

go.mod
module trace

go 1.21.7

require github.com/xhd2015/xgo/runtime v1.0.25

trace_test.go
package trace

import (
	"testing"

	_ "github.com/xhd2015/xgo/runtime/trace"
)

func TestTrace(t *testing.T) {
	A()
}

func A() string {
	return "A"
}

overlay.json
{
    "Replace": {
        "ROOT/trace/trace_test.go": "ROOT/tmp/trace_repalce_test.go"
    }
}

The replaced files content is identical to the original one.
run:
# trace normal
xgo test -v --strace ./

# trace empty
xgo test -v --strace --overlay overlay.json ./

Root cause:  when overlay applied, the pos file between syntax stage and IR stage aren't the same

Syntax Stage:  the replaced file
IR Stage: the original file

That makes mapping failed.

There is a function in noder: trimFilename(pos), which is called during writing IR records.
This function will apply the -trimpath flag to filenames.


GetUser is called several times per pageload

https://github.com/OrchardCMS/Orchard/blob/bdba35c704bd07b431fae901f0376856c9a743c2/src/Orchard.Web/Modules/Orchard.Users/Services/MembershipService.cs#L134
This method is called a few times per pageload, because it's called by the provider for WorkContext.CurrentUser (when a User is authenticated).
We could cache the query inside this (per request, and my guts say only if a user is found) to save a few more queries being sent to the database.

A local cache should work fine. (in the scoped service)

I did more tests on this today with fresher eyes.
Looks like there is already a memorization happening per-workcontext, and the additional invocations I'm seeing are caused by filters and such having to generate a new WorkContext (e.g. OutputCacheFilter has to do this).
When a new WorkContext is instanced, its underlying providers (specifically the one for CurrentUser) are also reinstanced (that can make sense to me), so a local cache (on a simple level, a dictionary) gets reset.
That being the case I think I'd close this and leave things as they are.


wrong comment type on comment command

Hi!
I've use editor.foldAllBlockComments on <style lang="scss"> block, and I got wrong result like this:

and I try to search issue for answers and nothing found, thanks for reply.

Do you mean editor.action.blockComment command?
Volar don't define scss language comment brackets, it's define by VSCode built-in css extension and your other scss extensions. Please try resolving extension issues with bisect.


Population information of different languages

As a reporting analyst of the Global Population Census Bureau, I want to have easy access to the population information of people speaking Chinese, English, Hindi, Spanish, and Arabic, organised by largest to smallest, so that I can provide the organisation with population reports.

@GLMMADHURYU
This is a great start, but a couple of things need to be changed;

The population information is not being pulled from the code
The output is empty at this time, only the table is showing

The populateLanguageStats needs to be moved to the main App folder

Similarly the printLanguageStats should be moved to the main App folder

The PopulateLanguageStats should be moved from this report class and separated to a new class like we have done already, should be named Language

Completed working on this, But the workflow failed due to build issues.

@GLMMADHURYU
Good work on this issue overall.
The only issue is that the output is not consistent with the requirement.
The results should only have the 5 languages and the total population with the percentage of the world.
But this looks like it's outputting languages per country and percentage of the country's population.
The percentage of the world population should add up to 100%