Rybrande vscode Functional test attempt 2

Shamelessly stolen from @NTaylorMullen and @ajaybhargavb. I fixed one test that was just broken and commented out some other tests which were flaky. We're going to see if this is stable, and then we can iterate on fixing the other tests.

@octref for some reason the downloaded VSCode always fails to see our experimental extensions in our Windows Release builds. Is there anything the vscode-test infrastructure does wonky on Release configurations (you can see the azdo Windows Release checks on this PR for reference)?

Error: command 'extension.configureRazorDevMode' not found

https://dev.azure.com/dnceng/public/_build/results?buildId=526717&view=logs&jobId=7c8326b9-0a5f-532a-e6de-db8515c72d9a&j=7c8326b9-0a5f-532a-e6de-db8515c72d9a&t=4e12a810-0c2e-5bfc-be41-39f6901056ea
This likely meant your extension is not activated yet. If your extension activate on file type, use VS Code API to open a file and wait some time.

This likely meant your extension is not activated yet. If your extension activate on file type, use VS Code API to open a file and wait some time.

Wait but isn't this sufficient to activate on the invocation of the command?
https://github.com/dotnet/aspnetcore-tooling/blob/b8d54b3b29349f7b1fedd583bbdf4aaa7cff7016/src/Razor/src/Microsoft.AspNetCore.Razor.VSCode.Extension/package.json#L33

I'm not sure what you meant by "Debug configuration", if you meant using a launch config locally, maybe the CI takes a while to start extension host (as the machine is lower spec) and you should wait a bit before calling commands.

you should wait a bit before calling commands.

Is there something we can invoke on the VSCode side to know when the Extension Host is good and ready?

You only see the first message logged not the second, so I guess you had a wrong path for languageServerDir. https://github.com/dotnet/aspnetcore-tooling/blob/051e5f5e42940a2db0472a5c90a8ed2628a28d89/src/Razor/src/Microsoft.AspNetCore.Razor.VSCode.Extension/src/extension.ts#L26-L38

You only see the first message logged not the second, so I guess you had a wrong path for languageServerDir.

You're totally right. @octref thank you for your patience and I'm sorry for the misunderstanding this is entirely on our side.
@ryanbrandenburg / @ajaybhargavb we're only looking for the language server under the Debug folder

Closing this old PR. Essentially a downstream version of this was merged.


Location with the name "Europe/Kiev" doesn't exist

Hello. Probably it's a similar issue as with

Asia/Saigon
Asia/Calcutta

Europe/Kiev was renamed to Europe/Kyiv in 2022.
There is a thread about this https://stackoverflow.com/questions/71829570/how-and-where-should-i-suggest-a-rename-of-an-existing-timezone-name

Hello @Vov4yk,
This plugin hasn't been updated in 3 years now 🙂 Consider switching to flutter_timezone which is a fork of this repo.
That being said, neither version of the plugin contain their own timezone database. They only pass on the timezone name reported by the underlying platform.


CAGRA bench: use device-side refinement when the data is on device

Fix CAGRA build benchmark always assuming the dataset is on host.
Before the fix, this would result in the refinement step being performed on host even if the data is on device; this would lead to a segfault.

/merge


reverse player state after game aborts

player states changed by the game or its phases (e.g. gamemode, inventory) should be reversed to their pre-change state when the game ends.

closed, moved into issue #47


[$1000] multiple error messages shown on sign-up page

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

sign-out
go to sign in page
Enter a mobile number without country code
Click sign-in a few times and see the error each time

Expected results:
should show one error message
Actual results:
first shows one error for a brief time and then that one is overwritten by another error message
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number:
Reproducible in staging?: needs reproduction
Reproducible in production?: needs reproduction
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://user-images.githubusercontent.com/43996225/235534258-e5b54422-be3e-43fa-9bd4-3a24aa655458.mp4
Expensify/Expensify Issue URL:
Issue reported by: @chiragxarora
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1682938777628589
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~0158dcd0971e2b94e4
Upwork Job ID:<PHONE_NUMBER>399085056
Last Price Increase: 2023-05-10

Triggered auto assignment to @JmillsExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

Bug0 Triage Checklist (Main S/O)

[ ] This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
[ ] This bug is not a duplicate report (check E/App issues and #expensify-bugs)

If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead

[ ] This bug is reproducible using the reproduction steps in the OP. S/O

If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
If the reproduction steps aren't clear and you determine the correct steps, please update the OP.

[ ] This issue is filled out as thoroughly and clearly as possible

Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.

[ ] I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

Sorry I can't get this one either. Please update this issue with the reproduction steps or provide a new set of reproduction steps so others can reproduce as well.

Sorry I can't get this one either. Please update this issue with the reproduction steps or provide a new set of reproduction steps so others can reproduce as well.

You have to hover over the red line, Ice mentioned that in my previous comment

Oh, hmm. I'm not sure if that's actually an error given that this is a shared field and we don't evaluate what's been entered enter you submit the value. Happy to open this back up, though I'm not convinced we should do anything here.

@JmillsExpensify May be has the same root cause reported here earlier. https://expensify.slack.com/archives/C049HHMV9SM/p1681390516045499

I'm going to be OOO until Monday fyi. I'll try to find someone to take this over while I'm out

I'm not able to reproduce this bug, it seems fine.
https://github.com/Expensify/App/assets/26260477/376a5d51-d3a8-41e0-b80e-098c52de0f55
I do see a different error message in the tooltip, but I don't think that's worth fixing right now honestly.

Issue not reproducible during KI retests. (First week)


NPE after repl.sess.load()

I was looking for the :reset alternative from Scala REPL in Ammonite REPL and thought that I've found it in repl.sess.load(). Unfortunately, calling repl.sess.load() without previous repl.sess.save() seems to unload all the necessary stuff for the REPL itself making it useless.
./amm
Loading...
Welcome to the Ammonite Repl 0.8.0
(Scala 2.11.8 Java 1.8.0_102)
@ repl.sess.load()
res0: ammonite.repl.SessionChanged =
Removed Imports: Set(
  'Resolver,
  'FilterMapArrays,
  'derefPPrint,
  'IvyConstructor,
  'show,
  'typeOf,
  'IvyThing,
  'tprintColors,
  'ArtifactIdExt,
  'RegexContextMaker,
  'pathScoptRead,
  'browse,
  'GrepResult,
  'Pipeable,
  'ChainableConversions,
  'repl,
  'tail,
  'main,
...
@ 1
java.lang.NullPointerException
@ "foo"
java.lang.NullPointerException

Fixed by #506


Incremented snapshot jvm version

Goal
The goal of this PR is to use a new incremented snapshot for jvm

At what point do we stop with the -SNAPSHOT and cut a release?

@JoeCap08055 We should figure it out but this one was to allow custodial wallet changes merge and having any dependency on a snapshot version


Type suffix notation does not seem current

In this article there are several cases of adding a type suffix, like:
['Foo's Law Value']_double
series.value_long
However in our Gen2 TSI environments that we have created recently, this syntax is not accepted, and gives an error.  Only this notation works:
['Foo's Law Value'].Double
series.value.Long
Am I missing something about the TSI environment version or other parameter?  This underscore notation is in several of the current TSI documentation pages, so I'm wondering why it doesn't match current TSI environments that we have created.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e7a69cb3-f639-42ce-70b2-207f979d5866
Version Independent ID: a8b862c0-ef54-9ebd-a396-ea5737fc51a1
Content: JSON flattening and escaping rules - Azure Time Series Insights Gen2
Content Source: articles/time-series-insights/concepts-json-flattening-escaping-rules.md
Service: time-series-insights
GitHub Login: @lyrana
Microsoft Alias: lyhughes

@rgamage the _ will be the column name in your Parquet files in your storage account. When querying via the API, to reference a column you'll follow the TSX syntax: https://docs.microsoft.com/en-us/rest/api/time-series-insights/reference-time-series-expression-syntax#filter-expressions
This page will be updated to show the query syntax along with the columns in storage.

@lyrana Are there any updates on this issue? Can this issue be closed?

I don't see any updates to the page yet, so I would assume it should be kept open?

@AshokPeddakotla-MSFT I'll attach the PR when ready

https://github.com/MicrosoftDocs/azure-docs-pr/pull/127540 and
https://github.com/MicrosoftDocs/azure-docs-pr/pull/127418

Those links are 404s for me
On Thu, Aug 27, 2020 at 5:16 PM lyrana<EMAIL_ADDRESS>wrote:

MicrosoftDocs/azure-docs-pr#127540
https://github.com/MicrosoftDocs/azure-docs-pr/pull/127540 and
MicrosoftDocs/azure-docs-pr#127418
https://github.com/MicrosoftDocs/azure-docs-pr/pull/127418
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/61128#issuecomment-682254369,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEAGYED7SQ43Y76HAU4F5OLSC3ZMLANCNFSM4QEHEJAQ
.

@rgamage Those PR's have been created in private repo and cannot be accessible for users. Changes will go live once they are merged.

Hello @rgamage, banners for Gen1 docs are now at the top of each article and the Gen1 JSON shaping article with confusing events/timestamps will be removed tomorrow

Thank you!
On Fri, Oct 2, 2020 at 4:46 PM lyrana<EMAIL_ADDRESS>wrote:

Hello @rgamage https://github.com/rgamage, banners for Gen1 docs are
now at the top of each article and the Gen1 JSON shaping article with
confusing events/timestamps will be removed tomorrow
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/MicrosoftDocs/azure-docs/issues/61128#issuecomment-703003423,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEAGYEBZVSW23HFYSFMSAHTSIZQ33ANCNFSM4QEHEJAQ
.


Airline colors lost when changing focus to and from a :terminal buffer

Hi, thank your for the awesome work. I am having some trouble with the plugin and the terminal emulator of neovim.
environment

vim: nvim 0.3.4
OS: Mac/Linux
Have you reproduced with a minimal vimrc: Yes
What is your airline configuration: Stock
does it happen in Vim: ???

actual behavior
The airline turns black when changing focus back to the :terminal buffer
expected behavior
Airline colors shall be kept

can you please show a screencapture of what is happening?

If I understand correctly, this is the default inactive window highlighting.

Well the default is grey, when I get back to the window making it active, it actually turns black. It should be bright as it is the first time it is active.

Ah, I couldn't follow the screencast. I think what is happening (in both vim and neovim) is, that the first time you switch to the terminal, the terminal isn't fully setup yet, so airline does not update to the desired state. Only after re-entering the terminal you see the expected colors.

As I am using the solarized light color scheme the expected colors shall be what they are at first: light. The theme is lost upon refocus of the windows when making it active the second time.

Weil the solarized airline theme most likely is missing an entry for the terminal.

Am 10.04.2019 um 17:04 schrieb Philip Karlsson<EMAIL_ADDRESS>As I am using the solarized light color scheme the expected colors shall be what they are at first: light. The theme is lost upon refocus of the windows when making it active the second time.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

Alright, I will see if I can confirm in the vim scripts for the airline theme then I guess

If anyone is looking for a solution, you can use this: https://github.com/vim-airline/vim-airline-themes/issues/180#issue-471090136

as said before, I am not opposed to adding new sections to the existing themes. Someone just has to make them


Hook-Examples.md: improve markdown formatting for code blocks

Some blocks are not getting syntax formatting/highlighting.

@adnanh ping, in case you're not getting issue notifications. Trivial merge.

Thank you!


replace derivative dependency with educe

Replace the unmaintained derivative dependency with educe. See also https://github.com/kube-rs/kube/issues/1583.

Motivation

The derivative dependency is unmaintained and uses syn 1 while everything else uses syn 2.
Solution
I decided to replace derivative with educe instead of derive-more, as derive-more lacks support of skipping/ignoring fields (see #311) and cannot derive Eq and PartialEq. However, I haven't tried too hard to make it work so let me know if I should try to use derive-more anyway.
Although educe can almost be used as a drop-in replacement in most places, it lacks to specify custom bounds for Eq for some reason. I decided to write the manageable impl for Eq myself where needed, i.e. in mod.rs and object_ref.rs

Edit: Noticed by CI checks that educe triggers clippy::unused_underscore_binding when deriving Debug for enums (i.e. for State<K> in watcher.rs). Hence, I added #![allow(clippy::used_underscore_binding)] in kube-runtime, not sure whether that is acceptable...

Marking as a fix as I don't think this will need to be classified as a breaking change. Though, likely one for the next minor anyway.


How to read chunked response?

I code like this:
// resp is a reqwasm::http::Response
let read_opt = resp.body();
match read_opt {
    Some(stream) => {
        let reader: js_sys::Promise = stream.get_reader().read();
    }
    None => {

    }
}

error:
no method named `read` found for struct `js_sys::Object` in the current scope
method not found in `js_sys::Object`

You need to access the read function from js_sys::Object. There are multiple ways to do that such as using Reflect or using unchecked_into to convert the returned Object a the proper type (see MDN documentation for that) and calling read method on it
PS: This is unrelated to this library.


chore(); allowed string literal in ethereum.decode call

Allowing usage of string literal in ethereum.decode() e.g. ethereum.decode("address", log.data). Otherwise, we have to go through
const ADDRESS = "address";
ethereum.decode(ADDRESS, log.data);

and adds no more readability.

Unfortunately, this doesn't work. will debug (& do a new PR) when I have time.


Move cmd script to tools

coverage: 99.181% (+0.08%) from 99.101%
when pulling 6f9d4ab323ca26bc9570f9b1b2b0151c1f7c162e on users/alexpeck/benchtools
into bfd18d0735ba117144a8c9991768b2556c1d5c7b on main.


modules/sops/templates: Support custom files as secret templates

This exposes the file option, which can be used with pkgs.formats to write additional configuration formats.
Without this option exposed, it's not possible to write configuration file formats like YAML or TOML that require a package build to generate.

I've addressed your comments. PTAL and thanks!

@mergify queue


Allow functional components to return React.ReactNode

I was able to fix this locally by editing the index.d.ts for @types/react.  I changed:
interface Element extends React.ReactElement<any, any> { }

to
type Element = React.ReactNode;

inside of the JSX namespace.

You should comment this on this new video from Matt which might send the feedback to the React team to be actually added to React.

This causes MANY issues throughout global scope. interfaces should never be overridden by types.


DS-189 Table Caption

Jira
https://pegadigitalit.atlassian.net/browse/DS-189
Summary
Add support for table captions.
Details

Add caption Twig prop.
Fix JS error previously thrown if table contained a <caption>.
Fully support <caption> by wrapping table in <figure> and caption in <figcaption> when caption is present.

Note: caption is moved out of the main table content into <figcaption> in order to make it span the table container width, not the table width, which can overflow the container.

How to test

Review code changes
Review Table Caption demo page

@mikemai2awesome addressed the feedback about the images and WC demos:

For the docs, you changed fillmurray to placeholder, can you change to a bolt-image instead? The point is to show different types of content. And for the WC docs, use web component markup, no twig please.

@cjwhitedev @danielamorse I fixed some indents and demo markup. Make sure your text editor is set to use tab width of 2 spaces.


use bind mounts instead of named volumes

This is maybe a matter of taste,  but I find the use of bind mount for databases, documents and dumps preferable over using named docker volumes, because it eases backup and restore, it survives when I wipe /var/lib/docker, so my precious user data is safe.
So in my local install, the uwazi service has the following volume parameter:
volumes:
  - ./documents:/home/node/documents
  - ./dump:/home/node/dump
  - ./log:/home/node/log

and mongo has:
volumes:
 - ./data/mongo:/data/db
 - ./dump:/dump

I don't care about elasticsearch, because in my understanding, that's no persistent data. I have added a directory for dumps, because for backup purposes I do a daily mongodump and I want to have access to it.

I agree. In fact it was the the default before use of volumes and I personally like to use the way you do in production.
What do you think about, to start, add these information as additional comment on the docker-compose.yml for now, and eventually we consider put (or not) as default?
Also, maybe with these comments, experience, etc we eventually will archive some docker-compose for production usage (see https://docs.docker.com/compose/production/)


ListProperty cannot be deepcopy'd (or pickled, probably)

Versions

Python: 3.7.4
OS: Gentoo Linux
Kivy: 1.11.1
Kivy installation method: pipenv

Description
ListProperty does not implement a valid __reduce__ or __reduce_ex__ method, making it impossible to deepcopy (or presumably pickle).
Code and Logs
import copy
from kivy.properties import ListProperty
from kivy.event import EventDispatcher

class A(EventDispatcher):
    attr = ListProperty()

a = A()
b = copy.deepcopy(a)

[INFO   ] [Logger      ] Record log in /home/dylan/.kivy/logs/kivy_19-09-05_17.txt
[INFO   ] [Kivy        ] v1.11.1
[INFO   ] [Kivy        ] Installed at "/home/dylan/.local/share/virtualenvs/venv/lib/python3.7/site-packages/kivy/__init__.py"
[INFO   ] [Python      ] v3.7.4 (default, Aug  1 2019, 15:47:41)
[GCC 8.3.0]
[INFO   ] [Python      ] Interpreter at "/home/dylan/.local/share/virtualenvs/venv/bin/python"
 Traceback (most recent call last):
   File "foo.py", line 9, in <module>
     b = copy.deepcopy(a)
   File "/home/dylan/.local/share/virtualenvs/venv/lib/python3.7/copy.py", line 169, in deepcopy
     rv = reductor(4)
   File "stringsource", line 2, in kivy._event.EventDispatcher.__reduce_cython__
 TypeError: no default __reduce__ due to non-trivial __cinit__

I'm guessing this would be an easy fix, so PR with unit test is welcome. DictProperty presumably has a similar issue.

I think this issue is not related to ListProperty, because the following code produce the same error.
import copy
from kivy.event import EventDispatcher

class A(EventDispatcher):
    pass

a = A()
b = copy.deepcopy(a)

Also, I believe we can't just copy.deepcopy() a EventDispatcher even if no error is occured.

Unfortunately this is still an issue in the latest version.
File "/usr/lib/python3.10/copy.py", line 172, in deepcopy
     y = _reconstruct(x, memo, *rv)
   File "/usr/lib/python3.10/copy.py", line 271, in _reconstruct
     state = deepcopy(state, memo)
   File "/usr/lib/python3.10/copy.py", line 146, in deepcopy
     y = copier(x, memo)
   File "/usr/lib/python3.10/copy.py", line 231, in _deepcopy_dict
     y[deepcopy(key, memo)] = deepcopy(value, memo)
   File "/usr/lib/python3.10/copy.py", line 161, in deepcopy
     rv = reductor(4)
   File "stringsource", line 2, in kivy.properties.ListProperty.__reduce_cython__
 TypeError: no default __reduce__ due to non-trivial __cinit__

Process finished with exit code 1

I have a similar / the same problem.
from copy import deepcopy
from kivy.properties import ListProperty
from kivy.uix.widget import Widget

class A(Widget):
    attr = ListProperty()

a = A()
deepcopy({'value': a.attr})

my workaround was to cast it to list.
Versions:

Python: 3.10.11
OS: Windows 11
Kivy: 2.2.1


The app does not render Base64-encoded images correctly

Summary
The app does not render Base64-encoded images correctly
Environment Information

Device Name: iPhone 6S
OS Version: 10.3.3
Mattermost App Version: 1.1.0 (Build 47)
Mattermost Server Version: 4.1.0

Steps to reproduce
Post a message containing a base64 markup, like this:
Red dot: ![red dot](data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==)

You'll see the red dot in the web application (including the old classic iOS app, of course), but you won't see it in this iOS or Android app.
Expected behavior
I expect to see the red dot image in this iOS/Android app.
Observed behavior
I am not seing the red dot image. Instead, I am seeing the raw markdown, like this:

Anton Johansson
Red dot: ![red dot](data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==)

Possible fixes
Sorry, can't provide one. :(

Hi @anton-johansson - thanks for the report, I think this is because we haven't added support for inline images yet.
We have a ticket here to fix the issue: https://mattermost.atlassian.net/browse/RN-173

Aha, sorry, my bad!
Would it be possible that you close this issue once your internal issue is closed?

@anton-johansson - yes for sure, we can leave this open + close it once the Jira ticket gets closed

Much appreciated!

@anton-johansson - v1.5.1 of the app should fix this

It works indeed! However, a newline is generated before and after each image, unlike in the browser, where I can include an embedded icon in the middle of the line.


Column Encryption

Issue Type: Bug
I am trying set up a connection to one of my Sql Azure databases using the "Column Encryption Setting=Enabled" advanced setting.
When I try to query the table that has one of the columns encrypted, this setting does not appear to work as I am trying to view the data decrypted.
Azure Data Studio version: azuredatastudio 1.8.0 (96e214593190071f0b520439929b218f9fa673de, 2019-06-06T01:59:30.203Z)
OS version: Windows_NT x64 10.0.17134

System Info

Item
Value

CPUs
Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz (12 x 2208)

GPU Status
2d_canvas: enabledchecker_imaging: disabled_offflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onnative_gpu_memory_buffers: disabled_softwarerasterization: enabledsurface_synchronization: enabled_onvideo_decode: enabledwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
15.74GB (4.81GB free)

Process Argv

Screen Reader
no

VM
0%

Extensions (2)

Extension
Author (truncated)
Version

profiler
Mic
0.7.0

whoisactive
Mic
0.1.1

Closing this as a duplicate of #39 - currently Always Encrypted is not supported in .NET Core (https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-client-development)


basic riscv assembly cleanups

The risc-v assembly code is a mess of code duplication and inefficiencies.
Many things can be improved here. But let's do it in steps.
This first batch cleans up the existing code without changing the code
flow and logic.

I added my big cleanup along with the other commits.
The major highlight is:
Run of samples/userspace/syscall_perf (before):
*** Booting Zephyr OS build zephyr-v3.0.0-325-g3748accae018  ***
Main Thread started; qemu_riscv32
Supervisor thread started
User thread started
Supervisor thread(0x80010048):       384 cycles      509 instructions
User thread(0x80010140):           77312 cycles    77437 instructions

Run of samples/userspace/syscall_perf (after):
*** Booting Zephyr OS build zephyr-v3.0.0-326-g4c877a2753b3  ***
Main Thread started; qemu_riscv32
Supervisor thread started
User thread started
Supervisor thread(0x80010048):       384 cycles      509 instructions
User thread(0x80010138):            7040 cycles     7165 instructions

Yes, that's more than a 10x speed-up!
This clashes big time with the recently merged SMP support. I do think it would
be far easier to port the SMP support on top of this rather than doing it the
other way around.

The first four patches - the simple refactor, look great. I didn't start looking at the "mega simplification" one yet. As it's fairly big, I'll probably do it on parts next week.
@npitre you mention about the conflicts with the SMP support series. Are you suggesting that, for your patches to go, the SMP series should be reverted and recreated in the future? I do understand that rebasing your series on top of current main is fairly complex now, but maybe the right tactics can help. I haven't looked carefully at the main patch yet - but I'll look at them thinking on ways to approaching this rebase. Hopefully there's a good way forward.

Are you suggesting that, for your patches to go, the SMP series should
be reverted and recreated in the future? I do understand that rebasing
your series on top of current main is fairly complex now, but maybe
the right tactics can help. I haven't looked carefully at the main
patch yet - but I'll look at them thinking on ways to approaching this
rebase. Hopefully there's a good way forward.

I'm working on backporting SMP support on top of this at the moment.

SMP support added to this branch. I had to revert 3 existing commits
as they heavily conflicted with these cleanups and needed a different
implementation.
It is now equivalent in functionality (and in bugs) to the current
main branch. Yes, SMP in main has bugs whose fix will be nicer on top
of this.

OK, here it is done. And CI should be happy too.
The last 2 commits address issues that were not covered by the current
main branch's code. Most importantly is making arch_is_user_context()
SMP compatible.

qemu_riscv64_smp          tests/subsys/logging/log_stack/logging.log_stack_immediate_cpp FAILED Failed
Those tests just check stack sizes and it seems the new code change what the test is expecting. TBH, those tests are starting to be an annoyance, especially when working on bringing up a new architecture. @nordic-krch FYI

those tests are starting to be an annoyance

yes, noticed it couple of times already. On the other hand, logging is used everywhere so it's good to be track stack usage and delta. Things that could be tweaked there are:

increase tolerance. Currently it is set to 16 bytes. Downside is that it will delay detection of increase.
be more tolerant for NO_OPTIMIZATION case. I've seen that it tends to grow faster.

Other proposals?

Copyright (c) 2016 Jean-Paul Etienne<EMAIL_ADDRESS>

Copyright (c) 2022 BayLibre SAS

Why is the reason behind this change in the copyrights?

The content of thisfile ended up being a complete rewrite.

+#ifdef CONFIG_CPU_HAS_FPU_DOUBLE_PRECISION
If  another extension-related ifdef is being added, maybe it would
be a good idea to name it as described
here,
i.e. CONFIG_RISCV_ISA_EXT_D?

Indeed. Here I wanted to reuse what was there already to ease reviewing.
A separate commit on top of this to use better nomenclature would be good.

Also, many empty lines could and probably should be removed from this file.

Style preference I guess. I don't have a strong opinion here though.

Latest changes:

fixed exit path for irq_offload to consider preemption
implemented CONFIG_IRQ_OFFLOAD_NESTED
fixed tests/subsys/logging/log_stack after latest upstream changes

Can we please merge this now? SMP support in the main branch is buggy
and lacking (see the last 2 commits).

On Tue, 15 Mar 2022, Ederson de Souza wrote:

@edersondisouza commented on this pull request.

Last patch quite deviates from the rest of the series, but I guess
that's life. Looks good, but it would be nice if someone more
acclimated with PMP helps review.

I deliberately didn't touch the PMP code, except for removing the PMP
mapping of the is_usermode global variable when USERSPACE and SMP are
enabled given such variable cannot be used in that case. So PMP remains
unaffected by this series.
But PMP is on my list for a revamp as well.
The difficulty here is to find enough people with the skills set to
review this code. The magnitude of this cleanup is a sign of that. So
I'd advocate for a merge sooner than later given that remaining issues
can be fixed later. This series does address many serious issues
already so the greater risk is rather about not to merge it.

I even wrote about the z_get_next_switch_handle issue, then noticed this is addressed at a later patch. Maybe squash this with previous one, so not to have known bad patches that may throw off some git bisect?

I prefer not for those reasons:

It is still quite difficult to trigger the race.

This is a workaround that deserves to be "documented"
separately to make it clearer to code archaeologists.

SMP is obviously not fully functional until the very last patch so
bisection is much more likely to fail for other reasons than this
anyway.

@npitre please rebase
@kgugala please review

Combined workaround for #40795 into the arch_switch commit as #43894
to be merged soon clarifies things (this is lo longer a workaround).

Rebased on latest main branch

All tests pass now.


Comments from instructors [DO NOT MERGE]

Could use some tests on CommentsController
So far so good, just some opportunities to dry a few things up.
@theidlemonk @mdmartinez @jannypie Good work!

@alycit Thanks!!!


feature/dbt-expectations-shim

PR to address Issue #29
This PR adds a folder for shims of dbt-expectations macros. Specifically, this PR only adds a spark shim for the regexp_instr macro. This may be expanded in future PRs to add other shims for macros within this package.
I did not add anything to the integration_tests folder. Let me know if there are any updates needed on my end for this to be incorporated. A working implementation currently exists within the Fivetran dbt_google_ads_source package. The intention will be to remove this macro from the Fivetran package and into spark-utils for use by all.

Unsure why CircleCi is failing. Happy to make adjustments to my PR if needed.


filtering issue in normalized benchmarks when multiple variants are selected

Selecting multiple variants like

or this

where one variant is different from the rest of the selected variant (where the selected variants are the same variant) the normalized dataframe results in the following errors respectively

 and

The normalise function seems to be unable to match the index of the dataframe with the number of values.

The use case for this scenario is inherently invalid because there shouldn't be a case where one needs to select multiple variants of one type and one variant which is a little bit different

https://github.com/ocaml-bench/sandmark-nightly/commit/75cea2dddca6c1e4596ba0ed21e125dff18d3af8 adds an error message to inform user


[KTLN-259] default non optional param

I'm wondering if this tutorial would be better placed in this core-modules-5 folder?

I'm fine with moving this around - I did not have a great idea on where to place it. Will move.


GPS - Enchancement

Hey moagrius ,
I have previously mentioned this before, according to relative coordinates positioning.  Your examples works perfectly , when i bound my map similarly it also works.
Though not exactly, let me expound, when i bound my coordinates south east and north west,it relatively maps the coordinates. However when i pulled live gps coordinated and then use add marker , it position is way off. eg. lat 18.02232 lon = -76.432221 , it appears the precision is up to the third digit at most.
So my question is, do you know any way mathematically or logically map the real coordinated in relation to the ones generated by the tileview(Coordinate Translator is pixel based).

i don't know of a way off hand - there's no "curve" built in - it just takes whatever you say your left and right edges are, and find the relative position for any number between them.
i'm sure someone has done it, and you could probably customize the positioning stuff without too much trouble (by computing yourself and not using relative bounds at all), but i don't know off hand of any resources - sorry.

I see, thank you . But for guidance,  (by computing yourself and not using relative bounds at all), the map is a grid of pixels. By nature their relative. what exactly do you mean?

all TileView does is find a relative position between edges.
if you're left edge is say 50, and your right edge is 100, and someone passes in a coordinate of 60 it will be at a point 20% between left and right.
double distance = right - left;
float relative = (coordinate - left) / distance;

that would give you 0.2, which means 20% of the way across.  you then apply that to pixels to get the actual coordinate on screen:
int pixel = width * relative;

As you can see, it's a very simple system.  It does not take into account the curve of the earth.  That said, you can supply whatever bounds you want - or none, and compute pure pixel positions yourself - however works best for you app.


SPARQL 1.1 Update fails for O(5k) insertions

(Migrated from https://openrdf.atlassian.net/browse/SES-971)
SPARQL 1.1 Update queries fail as the graph gets large. For example, an the "INSERT DATA" statement fails when the number of inserted triples is too large: INSERT DATA { GRAPH http://g { http://s http://p http://o-1. http://s http://p http://o-2. # and so on for -3, -4, ... -n } This query starts to break with n >5000. I've seen it fail on n as small as 6000 and succeed for n as large as 16000. The behavior is inconsistent, even for identical queries. (Binary search script: https://gist.github.com/2253815) I've tried inserting against a memory store and a disk-based store, and I see the following stack overflow in my logs: java.lang.StackOverflowError at org.openrdf.query.algebra.Join.visit(Join.java:51) at org.openrdf.query.algebra.BinaryTupleOperator.visitChildren(BinaryTupleOperator.java:100) at org.openrdf.query.algebra.helpers.QueryModelVisitorBase.meetNode(QueryModelVisitorBase.java:658) at org.openrdf.query.algebra.helpers.QueryModelVisitorBase.meetBinaryTupleOperator(QueryModelVisitorBase.java:601) at org.openrdf.query.algebra.helpers.QueryModelVisitorBase.meet(QueryModelVisitorBase.java:336) at org.openrdf.query.algebra.Join.visit(Join.java:51) [repeated!]

Processing of INSERT DATA has been radically redesigned since this was reported, and no longer involves use of a Join visitor. This issue therefore no longer occurs.


Add "Extended" clickbench queries

Which issue does this PR close?
Closes https://github.com/apache/arrow-datafusion/issues/8860
Rationale for this change
I would like to have benchmarks that allow us to show improvements such as https://github.com/apache/arrow-datafusion/pull/8827 and https://github.com/apache/arrow-datafusion/pull/8849 are significant
What changes are included in this PR?
Add new "Extended" datafusion specific clickbench queries:
to run:
./benchmarks/bench.sh run clickbench_extended

Example:
***************************
DataFusion Benchmark Script
COMMAND: run
BENCHMARK: clickbench_extended
DATAFUSION_DIR: /Users/andrewlamb/Software/arrow-datafusion/benchmarks/..
BRACH_NAME: alamb_clickbench_extended
DATA_DIR: /Users/andrewlamb/Software/arrow-datafusion/benchmarks/data
RESULTS_DIR: /Users/andrewlamb/Software/arrow-datafusion/benchmarks/results/alamb_clickbench_extended
CARGO_COMMAND: cargo run --profile release-nonlto
***************************
RESULTS_FILE: /Users/andrewlamb/Software/arrow-datafusion/benchmarks/results/alamb_clickbench_extended/clickbench_extended.json
Running clickbench (1 file) extended benchmark...
   Compiling datafusion-benchmarks v34.0.0 (/Users/andrewlamb/Software/arrow-datafusion/benchmarks)
     Running `/Users/andrewlamb/Software/arrow-datafusion/target/release-nonlto/dfbench clickbench --iterations 5 --path /Users/andrewlamb/Software/ar
row-datafusion/benchmarks/data/hits.parquet --queries-path /Users/andrewlamb/Software/arrow-datafusion/benchmarks/queries/clickbench/extended.sql -o /Users/andrewlamb/Software/arrow-datafusion/benchmarks/results/alamb_clickbench_extended/clickbench_extended.json`
Running benchmarks with the following options: RunOpt { query: None, common: CommonOpt { iterations: 5, partitions: None, batch_size: 8192, debug: false }, path: "/Users/andrewlamb/Software/arrow-datafusion/benchmarks/data/hits.parquet", queries_path: "/Users/andrewlamb/Software/arrow-datafusion/benchmarks/queries/clickbench/extended.sql", output_path: Some("/Users/andrewlamb/Software/arrow-datafusion/benchmarks/results/alamb_clickbench_extended/clickbench_extended.json") }
Q0: SELECT COUNT(DISTINCT "SearchPhrase"), COUNT(DISTINCT "MobilePhone"), COUNT(DISTINCT "MobilePhoneModel") FROM hits;
Query 0 iteration 0 took 5614.0 ms and returned 1 rows
Query 0 iteration 1 took 5652.6 ms and returned 1 rows
Query 0 iteration 2 took 5554.3 ms and returned 1 rows
Query 0 iteration 3 took 5511.4 ms and returned 1 rows
Query 0 iteration 4 took 5554.3 ms and returned 1 rows
Done

Are these changes tested?
I tested this (and clickbench_1) manually
Are there any user-facing changes?
this is a development tool only

Thank you for the review @andygrove

Thank you @alamb


added copy constructor to min_heap.h

Created a copy constructor for the heap.

@77Transam Thanks for your interest to contributing and solving issues. I advice you to read the CONTRIBUTE.md and - in general - the readme files to see how to contribute. In your case, we just need to add some unit tests for the new function you implemented in order to be accepted. If you have any questions i will be pleased to answer them. Thank you!

Maybe you have to add C:\MinGW\bin to the path first. I don't know much about windows or what machine you have.Make sure you have MinGW downloaded first and foremost.

I have C:\mingw64\bin added to my path.  I am also using VS code.  Is there any other information that might help us figure this out?

It is your machine's problem that make is not recognized, i mean you can google it and maybe find a solution cause im not in control of your computer. Maybe try MinGW32-make instead of make. If this won't help, check this issue https://stackoverflow.com/questions/23723364/windows-7-make-is-not-recognized-as-an-internal-or-external-command-operabl

Thank you. The MingGW32-make did work. After changing the directory to tests, I was not able to go any further ./ is not recognized by windows. I also was not able to locate the path to the file in question execute.
$ ./runUnitTests
bash: ./runUnitTests: No such file or directory

$ runUnitTests
bash: runUnitTests: command not found

I guess there's an error in building. Please read the log of the build after the cmake .. or MinGW32-make. MinGW32-make should start building all the files, it should take approximately 1 minute to build and you should see all the files building up to 100%. If this don't happen for some reason, then the build failed some steps before.

I am getting errors when building on the hash_table and mat_1d
[ 67%] Building CXX object tests/CMakeFiles/runUnitTests.dir/hash_table/hash_table.cc.obj
In file included from C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\hash_table\hash_table.cc:1:
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/classes/hash_table/hash_table.h: In function 'std::ostream& operator<<(std::ostream&, hash_table<KeyType, ValueType>&)':
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/classes/hash_table/hash_table.h:140:3: warning: no return statement in function returning non-void [-Wreturn-type]
  140 |   }
      |   ^

[ 69%] Building CXX object tests/CMakeFiles/runUnitTests.dir/linalg/mat1d/mat_1d.cc.obj
In file included from C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:1:
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:29:29: error: expected ')' before '<' token
   29 |   explicit Mat1d(std::vector<T> v = {}) : __size(SIZE) {
      |                 ~           ^
      |                             )
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:29:39: error: expected unqualified-id before ')' token
   29 |   explicit Mat1d(std::vector<T> v = {}) : __size(SIZE) {
      |                                       ^
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h: In constructor 'Mat1d<T, SIZE>::Mat1d(T)':
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:58:12: error: returning a value from a constructor
   58 |     return *(this);
      |            ^~~~~~~
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc: In function 'void C_A_T_C_H_T_E_S_T_0()':
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:9:17: error: no matching function for call to 'Mat1d<int, 5>::Mat1d()'
    9 |   Mat1d<int, 5> mat;
      |                 ^~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = int; long long unsigned int SIZE = 5]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note:   candidate expects 1 argument, 0 provided
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = int; long long unsigned int SIZE = 5]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note:   candidate expects 1 argument, 0 provided
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:21:65: error: no matching function for call to 'Mat1d<char, 10>::Mat1d(<brace-enclosed initializer list>)'
   21 |   Mat1d<char, 10> mat2({'a','b','c','d','e','f','g','h','i','j'});
      |                                                                 ^
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = char; long long unsigned int SIZE = 10]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:25: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'Mat1d<char, 10>&'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |                  ~~~~~~~^~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = char; long long unsigned int SIZE = 10]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:26: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'char'
   54 |   explicit Mat1d(const T val) noexcept {
      |                  ~~~~~~~~^~~
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc: In function 'void C_A_T_C_H_T_E_S_T_2()':
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:31:17: error: no matching function for call to 'Mat1d<int, 5>::Mat1d()'
   31 |   Mat1d<int, 5> mat1;
      |                 ^~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = int; long long unsigned int SIZE = 5]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note:   candidate expects 1 argument, 0 provided
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = int; long long unsigned int SIZE = 5]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note:   candidate expects 1 argument, 0 provided
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:44:18: error: no matching function for call to 'Mat1d<char, 5>::Mat1d()'
   44 |   Mat1d<char, 5> mat3;
      |                  ^~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = char; long long unsigned int SIZE = 5]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note:   candidate expects 1 argument, 0 provided
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = char; long long unsigned int SIZE = 5]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note:   candidate expects 1 argument, 0 provided
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:49:18: error: no matching function for call to 'Mat1d<char, 5>::Mat1d()'
   49 |   Mat1d<char, 5> mat4;
      |                  ^~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = char; long long unsigned int SIZE = 5]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note:   candidate expects 1 argument, 0 provided
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = char; long long unsigned int SIZE = 5]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note:   candidate expects 1 argument, 0 provided
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc: In function 'void C_A_T_C_H_T_E_S_T_4()':
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:61:43: error: no matching function for call to 'Mat1d<char, 5>::Mat1d(<brace-enclosed initializer list>)'
   61 |   Mat1d<char, 5> mat({'a','b','c','d','e'});
      |                                           ^
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = char; long long unsigned int SIZE = 5]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:25: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'Mat1d<char, 5>&'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |                  ~~~~~~~^~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = char; long long unsigned int SIZE = 5]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:26: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'char'
   54 |   explicit Mat1d(const T val) noexcept {
      |                  ~~~~~~~~^~~
C:\Users\att77\Projects\CPPProjects\AlgoPlus\tests\linalg\mat1d\mat_1d.cc:69:69: error: no matching function for call to 'Mat1d<std::__cxx11::basic_string<char>, 5>::Mat1d(<brace-enclosed initializer list>)'
   69 |   Mat1d<std::string, 5> mat2({"hello", "world", "we", "are", "csrt"});
      |                                                                     ^
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(Mat1d<T, SIZE>&) [with T = std::__cxx11::basic_string<char>; long long unsigned int SIZE = 5]'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:66:25: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'Mat1d<std::__cxx11::basic_string<char>, 5>&'
   66 |   explicit Mat1d(Mat1d &mat) : __size(SIZE) {
      |                  ~~~~~~~^~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:12: note: candidate: 'Mat1d<T, SIZE>::Mat1d(T) [with T = std::__cxx11::basic_string<char>; long long unsigned int SIZE = 5]'
   54 |   explicit Mat1d(const T val) noexcept {
      |            ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:54:26: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'std::__cxx11::basic_string<char>'
   54 |   explicit Mat1d(const T val) noexcept {
      |                  ~~~~~~~~^~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h: In member function 'T& Mat1d<T, SIZE>::operator[](size_t) [with T = int; long long unsigned int SIZE = 5]':
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:148:5: warning: control reaches end of non-void function [-Wreturn-type]
  148 |     catch(std::invalid_argument &e){
      |     ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h: In member function 'T& Mat1d<T, SIZE>::operator[](size_t) [with T = char; long long unsigned int SIZE = 10]':
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:148:5: warning: control reaches end of non-void function [-Wreturn-type]
  148 |     catch(std::invalid_argument &e){
      |     ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h: In member function 'Mat1d<T, SIZE>& Mat1d<T, SIZE>::operator=(Mat1d<T, SIZE>&) [with T = char; long long unsigned int SIZE = 5]':
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:97:5: warning: control reaches end of non-void function [-Wreturn-type]
   97 |     catch(std::logic_error &e){
      |     ^~~~~
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h: In member function 'T& Mat1d<T, SIZE>::operator[](size_t) [with T = char; long long unsigned int SIZE = 5]':
C:/Users/att77/Projects/CPPProjects/AlgoPlus/src/linalg/mat_1d.h:148:5: warning: control reaches end of non-void function [-Wreturn-type]
  148 |     catch(std::invalid_argument &e){
      |     ^~~~~
MinGW32-make[2]: *** [tests\CMakeFiles\runUnitTests.dir\build.make:511: tests/CMakeFiles/runUnitTests.dir/linalg/mat1d/mat_1d.cc.obj] Error 1
MinGW32-make[1]: *** [CMakeFiles\Makefile2:97: tests/CMakeFiles/runUnitTests.dir/all] Error 2
MinGW32-make: *** [makefile:100: all] Error 2

This will be closed due to inactivity. Though, i added a new windows unit test run commands in README, you might want to check at that


FindMatchBackground setting not work

VS Code Version:
Version: 1.70.3 (system setup)
Commit: a21a160d630530476218b85db95b0fd2a8cd1230
Date: 2022-08-31T08:03:55.990Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 6.1.7601

OS Version: Windows Server 2008 R2 with SP1 x64

I want other "editor" is yellow.

I know, it's "editor.selectionHighlightBackground.


161

QUESTION 161
Hotspot Question
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
NOTE: Each correct selection is worth one point.

Y
N
Y


parse-string accepts invalid json

Below is the current behavior of Cheshire:
(require '[cheshire.core :refer :all])
; nil

(parse-string "\"{0}\"")
; "{0}"

I'd expect Cheshire to throw an exception instead. The fact that parse-string function could return strings is not something I'd have expected. We get around this inconsistency by validating the output of the function at the moment.

Is there some part of the standard that I'm not seeing that says that top-level strings are not allowed?

Gary Fredericks writes:

Is there some part of [1]the standard that I'm not seeing that says
that top-level strings are not allowed?

Yes, I was under the impression that top-level strings are allowed in
JSON, which is why this isn't an exception
--
;; Lee

Hi,
Thanks for the replies. Reading the standard, indeed for the first time, it's clear that a top-level string is a valid JSON value:

5 JSON Values
A JSON value can be an object, array, number, string, true, false, or null.

Feel free to close the issue. Apologies for the confusion. Would it be informative to add such examples to the README?

Pushed a commit adding this to the readme

Thanks a lot @dakrone, for this and all of your OS contributions.


Report progress on Enigma encryption and decryption

Enigma should be able to report progress on its encryption process, useful especially where the files may be large. Also intention to use Asynchronous operations and accept Streams as constructors.

Done with the latest push. The previous Encrypt method now takes in  a IO.Stream  and not byte[]


'fill: "forwards"' causes the element to ignore any future style changes.

Hi,
Using fill: forwards when starting an animation somehow disables all style changes after the animation ends. This can very easily be tested by doing:
$('body').animate([{opacity: 1}, {opacity: 0.3}], {duration: 400, fill: 'forwards'})
and after than ends, running:
$('body').style.opacity = 1
It seems that only the properties that have at some point been part of a forwards animation are 'disabled'.  And this occurs in chrome 48 but not firefox 44

Working as intended. Discussed further in https://code.google.com/p/chromium/issues/detail?id=585463


net forward in dnn face recognition is slow

When I use dlib-net(img) to embed vector , the time it took when embedding 1 image on Windows OS (visual studio 2015) it took 0.4s.
I use AVX and Blas library(mkl) in release mode. I think it should be real-time

There are no official benchmarks that can tell us if this time is small or big. Also performance depends on processor, RAM, library versions... Have you compared this time with other DNN libraries (Caffe, Torch, Tensorflow...) on the same machine/compiler/OS? Do you have GPU?
Do you think if there is a bug in Dlib?
I think you can make some minimal-code example and somebody will be able to run it on his machine and compare the time
In any case you are welcome to provide PR's that can make library better

Tank you @e-fominov ,
The system: intel core i7-6700k 4.00 GHz, 16G RAM, windows10 64bit, no GPU.
I read your comment in https://github.com/davisking/dlib/issues/517 about DNN CPU speed, you said "the main hint is to use BLAS libraries (OpenBLAS/MKL) - CPU DNN module performance increases about 20x".
There is no deference when I run net() (in face recognition example) without Intel MKL and with Intel MKL.

I was testing on different network structure with MinGW 6.3 + single-threaded OpenBLAS on SandyBridge i7. After adding OpenBLAS CPU DNN timings reduced very much. You can try this compiler and Blas library
I am not working with Visual Studio anymore and never tried MKL. May be there are some options that can fine-tune MKL to work faster
And the main question - is MKL really used at runtime? Because 400 ms is the time I expect on your configuration without any BLAS
I recommend you to test
a) MSVC Without BLAS
b) MSVC  With MKL
c) MSVC + OpenBLAS
d) MinGW  with no BLAS
e) MinGW + OpenBLAS
Then we can discuss your results
And make sure that BLAS is single-threaded to make measurements compareable

If you are getting the same timings with and without BLAS then you are
definitely actually not using BLAS at all.  You can see in the cmake
output, or in the compiler settings if you look, if BLAS is being used.

@e-fominov I will do you recommendations and report results here.
@davisking I see in the cmake entries:
The C compiler identification is MSVC 19.0.24215.1
The CXX compiler identification is MSVC 19.0.24215.1
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe
Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works
Detecting C compiler ABI info
Detecting C compiler ABI info - done
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe
Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works
Detecting CXX compiler ABI info
Detecting CXX compiler ABI info - done
Detecting CXX compile features
Detecting CXX compile features - done
C++11 activated.
Searching for BLAS and LAPACK
Looking for sys/types.h
Looking for sys/types.h - found
Looking for stdint.h
Looking for stdint.h - found
Looking for stddef.h
Looking for stddef.h - found
Check size of void*
Check size of void* - done
Found Intel MKL BLAS/LAPACK library
Looking for cblas_ddot
Looking for cblas_ddot - found
CUDA_TOOLKIT_ROOT_DIR not found or specified
Could NOT find CUDA (missing:  CUDA_TOOLKIT_ROOT_DIR CUDA_NVCC_EXECUTABLE CUDA_INCLUDE_DIRS CUDA_CUDART_LIBRARY) (Required is at least version "7.5")
*** cuDNN V5.0 OR GREATER NOT FOUND.  DLIB WILL NOT USE CUDA. ***
*** If you have cuDNN then set CMAKE_PREFIX_PATH to include cuDNN's folder.
Configuring done

Huh.  Are you sure you are timing just the neural network part of the code?  Not the whole program or parts of the data loading or face detection?

Dear @davisking Yes, I'm sure.
begin = clock();
face_descriptor = net(face);
end = clock();
elapsed_secs = double(end - begin) / CLOCKS_PER_SEC;
cout<<elapsed_secs<<endl;

@msobhan69 , we need full source code for testing. Here Christopher made code for ARM testing but different function. better to have code with no file reading/writing
https://gist.github.com/bakercp/157573d1e27eec5f6fe4467c98477aa7
this is from #557
So If you can make something like this with detailed timings - we can try to make Dlib faster

I guess the problem is The DLIB_USE_BLAS and DLIB_USE_LAPACK are not define in visual studio Preprocessor Definition. But now, I have many errors in run time:
Intel MKL ERROR: Parameter 6 was incorrect on entry to DGESVD.
Intel MKL ERROR: Parameter 6 was incorrect on entry to DGESVD.
Intel MKL ERROR: Parameter 6 was incorrect on entry to DGESVD.
...
...
...
...
Intel MKL ERROR: Parameter 13 was incorrect on entry to DGESVD.
Intel MKL ERROR: Parameter 9 was incorrect on entry to cblas_dgemm.

Huh.  Something is going wrong in the cmake setup and it's not setting the compiler options it's supposed to.  What version of cmake and dlib are you using?

Dear @davisking @e-fominov , I found my mistake. After adding DLIB_USE_BLAS and DLIB_USE_LAPACK in visual studio Preprocessor Definition, I set Use Intel MKL to Parallel in visual studio Common Properties in my project, so there is no problem anymore. Dlib-net() is running in real time (0.02s), now.

Now we know how fast it should be :)  So looks like no additional changes in Dlib required

Well, cmake should have set it correctly the first time.  Maybe something is different about a new cmake or MKL, but when I have tested cmake here it correctly sets these things without the user needing to do anything, which is how I intend it to work.
So what versions of dlib and cmake are you using?  Did you make any changes to the CMakeLists.txt file or anything else?

Dear @davisking You are right, it correctly sets these things without the user needing to do anything, but I build dlib and use it's lib in new project. So, everything is ok about cmake and dlib.

Ah, you should have mentioned that :)


wasi: Implements wasi_snapshot_preview1.poll_oneoff for relative clock events

This implements wasi_snapshot_preview1.poll_oneoff for relative clock events,
and in doing so stubs Nanosleep which defaults to noop, but can be configured
to time.Sleep.
Special thanks to @clarkmcc for the failing test here!
fixes #625

want to check how go implements sleep also.. https://github.com/tetratelabs/wazero/pull/621

Thanks for the quick review turnaround @mathetake!

Excellent, thank you!


Release <IP_ADDRESS>

OpenSearch 1.3.15 has been released, see release notes.
Official OpenSearch release ticket: https://github.com/opensearch-project/opensearch-build/issues/4294
Checklist:

[x] Compatibility Matrix is updated (#263)
[x] Release <IP_ADDRESS> tag is present in the repo
[x] Release artifacts are available and downloadable
[x] Release notes published
[x] Forum announcement published

Forum announcement: https://forum.opensearch.org/t/prometheus-exporter-plugin-2-13-0-0-and-1-3-15-0-released/18736


Formatting required for Branding page

On master-head commit id: 629146a

Navigate to dashboard --> Global Settings --> Branding
The page is like this:

Can we format this page - adding demarcation lines, and constant spacing between headings and sections.

On master-head commit id: 5715b8a

Formatting is seen fixed.


Compressors have initial moment of "ducking"/overreacting

Bus Comp, Track Comp, and Consolidator all seem to behave the same way in this regard.
If I start playback "in the middle of" some audio file with a level that triggers compression, for the first (approximately) half second or so, the audio "ducks" as though it's overreacting to the signal. After that the compressor sounds normal; it's only that initial "ducking" that sounds wrong. (To really notice this behavior, be sure to set the threshold low enough that significant compression happens.)
By comparison if I start playback prior to an audio event that would trigger the compression (starting playback on silence, or at a lower level audio item that doesn't trigger the compressor), the compressors behave nicely once the compression is triggered by louder audio.
So they work well most times, but that behavior could be problematic for rendering (and also it can be very distracting when starting/stopping playback while adjusting the compressor's settings).
I should also mention: I can "smash" other compressors by lowering their threshold a lot, and they don't exhibit this sort of behavior. The reaction of the other compressors (ReaComp for example) would sound consistent; starting/stopping playback, or starting playback in the middle of a loud audio item, makes no initial overreaction.

Please try the following:

Play back an audio item that will definitely trigger compression
Stop playback while it's compressing
Move the play cursor into an area of silence, or an audio item that will definitely not trigger the compression
Play back a few seconds of that silence (or below-threshold audio item)
Stop the playback after a few seconds
Move the play cursor into an audio item that will definitely trigger compression
Press play

In such a scenario, do you still get the "ducking"? If there's not, then it could be that the buffered envelope states maybe aren't reset between transport changes.

In that test situation as you describe, the "ducking" still happens. It's really obvious in Bus Comp since the "ducking" seems to slowly dissipate (for about a second).
The only way I can stop it is to reduce the release time to a short amount such as 20ms in Track Comp.

I've been able to observe what you mention, but I can't reliably reproduce it or pin it on one of the compressors. It just happens at some point, and then I click around but can't get it to happen again, until it maybe happens again on its own at some point later on. (I've only noticed this behaviour about 5 times over the last couple of days.)
If it happens on playback changes, i.e. moving the play cursor around in the project or stopping/pausing/playing, then I assume Reaper informs the plugin and calls its @init section to cause an internal reset. If this reset reverts some variable to its default state, that could potentially create a problem.
The thing is, apart from setting an address for the noise buffer and initializing the envelopes that follow the signal to determine how much saturation to apply, nothing else is reset in that @init section. It's all just function definitions and constants that never change, like 0.5π or 1/√2 and so on. So I don't see how that could create an audible fade. Clicks from sudden jumps of the saturation amount would make more sense.
I've attached the bus comp to this message, it has a line added that explicitly instructs Reaper NOT to do that full @init reset when the playback state changes. I couldn't reproduce the problem over the few hours, so I don't know if this does anything. Please let me know either way.
bus_comp.jsfx.zip
If that doesn't solve anything, then could you maybe put together a preset that definitely causes this problem, and attach it to your reply? Would also be good to know which of the plugins it's for, and what kind of signal you're running into it at roughly which peak/RMS level (before it enters the compressor).

That seems to have fixed it! I tried it with various source materials and settings, and never noticed a gradual swelling of the volume after playback start when in the middle of an audio item that triggers compression. It also sounds very nice. :) I noticed no weirdness when using the plugin.
If the new line is "ext_noinit = 1;", then I've seen that in other JS plugins including the popular ReEQ (the only one I can recall at the moment), so I'm guessing it's safe to use. I added the same line to track_comp and it works there too. I'm not sure how it affects the intended sound of these plugins but at least it seems to stop this issue.
I haven't seen that particular code in many plugins, but I see other references to things being "initialized", so perhaps it's a matter of how things are set to initialize (and as long as they do it somehow). That's about all I can say about this though. I wish I could help with any technical details of this, but I'm not a programmer at all.
I have a suggestion for track_comp: the attack time setting is very useful between 0 and 2 ms (for getting "squashed" sounds which also have a bit of bite), but it's difficult to dial in within that range. If that range were easy for fine-grained adjustment, that would be nice. I think I can figure out how to do that in the code at least, but also it might be nice for the plugin in general if you don't mind my saying so.
Thanks!

That's great news!
Yes, that was the new line. I've never seen that line before, but to be honest, I never knew that instruction insisted, and I never looked for it in other plugins. I just went to the JSFX documentation and randomly read information on the init section, and sure enough, there I found it.
I still don't know why reinitializing something that doesn't really change anything would cause such behaviour, but I'm glad if you say it's gone! Then I can put this into the other dynamics processors as well and update them.
I love ReEQ, but for some reason it occasionally gives me DC offset. I'll just randomly see spike at 0 Hz in the spectrum analyzer, and only when I disable ReEQ will that spike go away. So something in there isn't quite as reliable as I'd wish it to be. But then I haven't updated mine in a while, I'll try that later.
The upside of JSFX is that you can just add a line and have a slider appear in a window. Then you add another line and you convert that slider's value to something else. Then you add another line that takes the converted value and uses it to process an audio signal. Super efficient, super fast, super simple.
The downside is that by re-using the slider JSFX automatically creates with that single line of code, there aren't (to my knowledge) any fancy options to affect HOW it behaves. Minimum value, maximum value, default value, precision, that's it. (In this case, "precision" refers to post-comma floating-point numbers.)
Take frequencies, for example. With a [20,20.000] Hz frequency slider, the center frequency should be around 500-1000 Hz so that it makes sense for a human to operate. Look at ReEQ and ReaEQ, without checking to confirm I can tell you that their spectrum analyzers will center around the 500-1.000 Hz range.
But JSFX sliders are always linear, this means that on a scale from 20 to 20.000, the value 10.000 is ~ at the center of the slider, the 5.000 mark is at 1/4 of the slider's width, and 1.000 (which is 1/20 of 20.000) is at 1/20 of the slider's width. So you only get that 5% on the left of the slider to scroll through all the important frequencies up to 1.000 Hz.
If I were to abstract that value, and make the slider's range go from 1 to 100, for example, then I could "fix it in the code" by normalizing the slider's linear [1,100] range down to a linear [0,1] range, and then accellerating/decellerating it as I please. So then I could map the slider's center 50 value to stand for 1.000 Hz in the frequency domain.
That however makes the frequency slider hard to operate. Shoot it at me, no thinking: on a scale of [1,100] that reflects the [20,20.000] Hertz range - which value do you need to get 1.250 Hz? ... Huh? ... And if the slider for the Sidechain High-Pass Cutoff on e.g. the Track Comp ranges in [0,100], then how would you know where the 100 Hz you're looking for are? ... Any guesses? ...  You see? :)
So I prefer to have relatable real-world values on the plugins, that actually mean something to me while I operate them. Unfortunately, in the world of JSFX this comes at the cost of useful scaling. ... That is, unless I started making entirely custom GUIs for those things, THEN of course I could do and scale whatever I want. But in all honesty, that's just too much trouble for unpaid work. :)
When dealing with something like a bass or piano track, there can be long phases where the instrument rings out and the signal goes very quiet - but it's still "operative". With short release times, this would result in constant "breathing", where the release opens up again because the signal is very quiet, and brings back all that background noise that was squashed down just a few seconds ago. Not good. So I'll definitely keep the long 1.5s release time in Track Comp.
But hey - this is JSFX. You can click the "Edit..." button at the top of the plugin, and you can customize it to your liking. If you want to narrow down the attack or release slider ranges, just go ahead and do so. I won't feel insulted or sad, promise. :)
Look for the lines at the top of the code that look like this, then change them as you please:
slider5: compAttack=10<0.001, 100, 0.01> Attack [ms]
The slider5 part is just an internal name for Reaper.
The "compAttack" is the name of a variable in the code that will be assigned the value of the slider.
(I pick relatively sensible names because I get confused otherwise, and in the hope that it helps someone reading the code figure out WTH I'm doing. :) So you should be able to identify the sliders by that name alone.)
The number immediately after the = sign is the default value.
The first number in <> brackets is the minimum value.
The second number in <> brackets is the maximum value.
The last number in <> brackets is the smallest amount of possible change between values, i.e. the "slider precision".
And at the end of it all, you'll find the Label that's displayed on the GUI.
And finally, I agree that the sliders of things like e.g. the Attack time are not sensitive enough at very small settings. But you can hold down a keyboard modifier and move the slider while you hold that key pressed, and Reaper will start making much more precise adjustments to that slider. This is probably a simpler (and more realistic) way to get more precision into those lower milliseconds than waiting for me to put together custom GUIs. ;)

I'll check the Threshold and Knee settings you mention.
(The difference between hard and soft knee won't always be super obvious. And some compressors don't "lower a threshold onto the signal" but "boost the signal into a threshold", and then confusingly name that boost parameter "Threshold", so maybe it's just a difference between expectation/implementation.)

Nope, can't confirm problems with Threshold or Knee for now.
I set Track Comp up a certain way:

no Feedback
no RMS
no Stereo Link
no SC filter
no Auto Makeup
no Saturation.

This means it's doing nothing special, it just compresses.
In addition to that, I set its Attack and Release times to zero, by entering the values in the text boxes by hand and overriding the plugin's slider ranges. This now essentially turns it into a clipping plugin with immediate distortion onset.
I ran a -12 dBfs sine wave through it, and checked in the spectrum analyzer and an oscilloscope what came out of the Track Comp.

With a completely hard knee (slider value 0) I could bring the Threshold down to exactly -12 dBfs, and nothing happened. oscilloscope and spectrum analyzer showed nothing unusual.
The second I set the slider just .01 lower than that, I could see a deformation in the oscilloscope and harmonics appear in the spectrum analyzer. (This was obviously distortion from the super-fast Attack/Release times.)
Bringing the Threshold slider up again above -12 dBfs removed those nasty side-effects.

To me, this means the Threshold is working correctly.
The Soft Knee parameter works like this: the number of dB you dial in are split up, half those dB affect the signal below the Threshold, and half those dB affect the signal above the Threshold. So this means that with a Soft Knee of 12 dB dialed in, the distortion should not start immediately with the Threshold at -12 dBfs, but it should start gradually 6 dB earlier.
And well, that's what it did. With a Threshold above -6 dBfs (minus another 6 dB from the Knee) everything stayed clean, and with the Threshold below -6 dBfs (minus another 6 dB from the Knee) there were artifacts from the distortion.
If you have any more specific idea what shouldn't be working about the Threshold and Knee, then please do let me know. But, and I'm weirdly a bit sorry to say so, to me it seems as if everything is working the way it should. :)

Thanks for the explanation! Yes I already edited the attack slider range, that much I had some idea how to do. I'm using compressors for drums and electric bass guitar mostly, so I hadn't thought of something like piano.
ReEQ has been updated. It had some issues with the AGC (auto gain calculation) which would cause volume spikes, and that was taken care of a while ago in a prior update. Plus also there was some very low-level DC that I had noticed and reported (although it was around -150 dB, it might spike up a bit under some circumstances); the latest update takes care of that. There's an explanation about the even lower-level DC that remains in the plugin after this change (it's for denormal purposes), and also a line of code that can be edited to remove it entirely (which I did, and it seems to work fine).
https://forum.cockos.com/showthread.php?p=2443617#post2443617
The first post of the thread is where the latest version of ReEQ is (attached at the bottom of the post).
I don't mind that these plugins don't have a GUI other than possibly a gain reduction meter; I'd try transposing the graphics from the 1175 plugin, but the last time I tried that, it didn't work well lol. Maybe someday I'll understand more of this code.
I set track_comp as you described and sure enough, I noticed the threshold is behaving as intended. I'm not sure why I didn't notice this, but I'm guessing it's because I left "feedback" turned up, or possibly one of the other controls. Anyway I still can't notice a difference in the knee, at least for now. :) Maybe with some more use, I will. Either way it sounds really good. I'll definitely be using both these plugins. I do see a difference when I test it (similarly to how you did), so I know the knee control does do something, but I think its effect is a bit too subtle for me to notice.
Thanks for these plugins! The more good plugins that exist, the better. Also I use Linux, so JS plugins have been a huge help.

Thought I'd teaser a little. ;)
Not done yet, will be a day or two before I can get this into Track Comp and possibly others, methinks.
Apart from the (orange) Threshold marker, I'm currently probing 6 signal stages, displayed in L/R pairs:

raw input signal (green)
input signal after gain adjustment (red)
key signal after possible M/S conversion and stereo linking (yellow)
gain reduction (blue)
output signal post-compression before (manual) make-up gain (purple)
raw output signal after make-up gain, clipping and dry/wet (cyan)

I don't know how many of these will stay in, maybe the many pre/post signals are a bit much.
Is that something you can work with?
And are you particularly (dis-) interested in any of those signals?
Maybe something I haven't thought of?
Lemme know!
And yes, the colours will certainly change! :)

Very nice!
I think a couple of the indicators aren't necessary and might help the plugin look less "busy" if they were removed. They could all be left in the plugin too (especially after seeing your updated picture with labels on each of the indicators, and how you removed the "stock" JS input/output meters on each side of the plugin to tidy up the look). But here are my thoughts about why a couple indicators might not be considered necessary.
Input (raw, before adjustment) indication shouldn't be necessary since the only input signal that matters is after it's been adjusted by the input gain control.
Similarly, output signal post-compression (but pre-makeup gain) indication shouldn't be needed; if a person has adjusted the output level by increasing or decreasing makeup gain, they should know it. Then again if the plugin has auto makeup gain (such as track_comp) and that feature is being used, it might be useful to see both sets of output indicators.
The other four indicators, I'd consider useful. Key/sidechain indication (after filtering, etc.) is actually something I've wanted in other compressors. Gain reduction is something people commonly want in compressors. Input versus output levels in general is also good to have.
If a "hybrid" sort of indicator were possible for input and output, that would be nice. I'm imagining the "raw" input indicator being green, and any additional gain (from the input gain control) being "stacked" on the right in a different color (darker green for instance). If the input gain is turned down, maybe there could be a thick green line representing the gain reduction "embedded" in the end of the indicator. (See the attached images.) If that kind of approach is feasible, then the input pre/post adjustment could be combined into one indicator. Likewise the output pre/post makeup gain could be combined into one indicator.

Something like that, anyway, if it's possible. Maybe that's not the best way to do it either (maybe there's a more intuitive way to show the gain reduction for instance).
I don't know if you've updated Reaper recently (to a development build in particular) but there's a new LUFS loudness meter plugin (JS), and it has some new functionality introduced in JSFX: the ability to hide/show sliders (click on the little icon on the bottom right). It's "slider_show()" function, in particular. That function might come in handy for you.

I did remove the "pre" and "post" meters, they bothered me. Now it's only:

the raw input (green) because there is no more input meter on the left
the key (yellow) which reflects input gain, stereo linking, filtering, etc.
the gain reduction (orange) coming from the opposite direction
the output (blue) after volume adjustment, optional clipping, dry/wet mix, etc.
I think it should work fine like this.

I could "stack" the input gain changes onto the input meter, but then A) the real input value is lost since there's no more JSFX input meter on the side, and B) the gain would also be in the key signal, which makes their difference less significant, they'd always be fairly close to each other.
I'm currently pondering what exactly the input gain should affect with an external sidechain, the input signal or the sidechain signal. Ah... it never ends. :)

That way of metering provides all the pertinent information while avoiding clutter. I like it.
I suppose since the threshold can be lowered enough (it goes to -60 dB), the "input gain" can be used strictly for key signal whether it's on the main input or sidechain. I'd suggest naming the control something other than "key" though since that's not as common a term as "detector input" or "detector level" (or even "sensitivity"). I generally don't use input gain on a compressor with this degree of versatility; I only use it on compressors which don't have a threshold control that I can lower.

I thought about your suggestion regarding renaming the Key meters, but I think their name is fitting as it is.
I disagree about "detector" being a more common name, since the "detector" is part of the circuit but not a signal as such.
Renaming it to "Sidechain" or "SC" was an option, since I use those terms with the plugin sliders. But firstly, the "sidechain" is just another name for the "detector path", and secondly the meters do not reflect the sidechain/detector input signal, but they also factor in the gain, the filtering and the stereo linking.
Calling the signal level that is actually used to calculate the compression from a "key" is pretty common, so I will leave it that way for now. If it turns out to be too confusing for people, I may reconsider. ;)
Level staging is a very important feature in the plugin world. If the signal going into a plugin is too hot, a dynamics threshold that only goes up to 0.0 dBfs may not be sufficient. (Many offer thresholds above 0.0 dBfs.) Having an input gain slider can help to bring the signal down into a level range useful with that specific plugin.
Also consider this: if you put together a signal FX chain with, maybe, a compressor, an EQ, a clipper, a send to a reverb, and so on - then all the signal levels after that first compressor depend on the output from that first compressor. If you load the FX chain on a track that is too loud or too quiet, you'll need a gain plugin before the compressor - or you'll need to mess with the compressor's threshold and compression settings, which in return will make it necessary to compensate that volume change in all the following plugins too.
So even if you find you don't really need it, I think having input/output volume in a plugin is an important feature, and I won't take them out.


Schedule rake upkeep:update_budgets

The rake upkeep:update_budgets task needs to be run on a schedule.
Use the rufus-scheduler gem for this.

this is a duplicate of Issue #441. closing.


ESAS: LifeStage

LifeStage
Age class:
A Adult
I Immature (not specified)
1 1st calendar year
2 2nd calendar year
3 3rd calendar year
4 4th calendar year
5 5th calendar year

Possible of changing immature to juvenile? Anna will ask.

ESAS meeting: change the CodeType description to 'life stage based on plumage'
juvenile - specific to 1st year (add in brackets)
immature (sub-adult) relates to 1-5 years (add in brackets)
https://ices-tools-dev.github.io/esas/tables/#lifestage

Lifestage based on plumage
Juvenile 1st yr
Immature 1-5 yr

codes are created