Clean up the outputfile naming conventions and document

There are a lot of variables for running the code at this point.

[ ] create a first draft of an explanation of the variables that are set using create_iq_snapshot_init in readme.md
[ ] create an updated convention for naming the output that takes into account that sometimes files will be read and other times the API.
[ ] update the code to reflect the changes.
[ ] Test it

I've spent today working on this.
It's touched all the main files.
I had to think again about decisions I made about file naming and challenge them. The filenames are generally built left to right from least volatile to most volatile.
I think what I've implemented and documented in the README.md makes sense in that having the workflow doesn't matter so much for the api runs but it may be more significant for the file runs.
I'm doing testing on the api and file runs in my local environment now before checking it all in.

hit the api rate limit. time to leave it for now.

starting to do check-ins now around #38 this is the comment that goes with pydata.
The naming conventions updating lead to some serious tangential work including re-organizing the initialization function, changing some of the behavior for input variables, and changing how I validate the input variables.  This still feels very amateur.  I know there are libraries for cleaning and validating input as well as best practices for passing many input variables and I'm looking forward to v2 to get to understand those better.

I'm going to close this for now as being adequate for a first pass at a cleanup.
The results are here:

README.md
reflected in code in pydata.py that controls the naming of the output directory and the output file name base.
Reflected in the new format of the yaml file.

collection_flag:
        h: 'str: valid values: start | snapshot | end. api=required. file=Ignored.'
        v: ''
organization_name:
        h: 'str: e.g: IQSS. Always required.'
        v: IQSS
output_base_dir:
        h: 'str: /mnt/hgfs/iq_reporting_collab/run/out;no[ ,.-special_char] ok:''_''.
                No trailing /. api=ignored. file=Optional'
        v: ''
output_file_base_name:
        h: 'str: e.g. sprint_2023_05_03-snapshot-2023_05_22_11_00-api-000-orig  .api=ignored.
                file=not required.'
        v: ''
project_name:
        h: 'str: e.g: IQSS/dataverse. Always required.'
        v: IQSS/dataverse
sprint_name:
        h: 'str: e.g. sprint_2023_04_26;no[ ,.-special_char] ok:''_''; api=required.file=Ignored.'
        v: ''
src_dir_name:
        h: 'str: e.g: ~/iqss_gh_reporting/run/in no[ ,.-special_char] ok:''_'' no
                trailing /. api=ignored. file=required.'
        v: /mnt/hgfs/iq_reporting_collab/sprint_2023_05_10/start/
src_file_name:
        h: 'str: e.g: sprint_2023_05_03-snapshot-2023_05_22_11_00-api-000-orig.tsv
                .api=ignored. file=required.'
        v: 2023_05_10-21_55_01-May102023-start-r01-api-20230510215501-sized.tsv
src_type:
        h: 'str: valid values: api | file. Always required.'
        v: file
workflow_name:
        h: very short description or code.no[ ,.-special_char] ok:'_' Optional.
        v: 1strun


Allow for undefined media component in walkthroughs

For: https://github.com/microsoft/vscode/issues/225522

Holding off on making this change till we get more feedback for:  https://github.com/microsoft/vscode/issues/225522


Update documentation on initializing a source-git repo

packit source-git init is the way to initialize a source-git repo, but the documentation on the website does not reflect this.
Make sure https://packit.dev/docs/cli/source-git/init/ is up to date and it's referenced from https://packit.dev/docs/source-git/how-to-source-git/

please sync


Cannot be used in IDEA2020.3 version

Cannot be used in IDEA2020.3 version.
Can you help me!

The ClearCase plugin is officially not supported. We're sorry for the issues you're experiencing, but we do not plan to release any fixes or updates for the plugin.

So unlucky


Uncaught: WalletDisconnectedError

Describe the bug
When clicking disconnect on the web, the button stays in a state of "Disconnecting" and never disconnects
I'm using Solana/Phantom wallet
To Reproduce
Steps to reproduce the behavior:

Select a wallet from the "Select Wallet" button
Button changes to now show "Disconnect"
Click "Disconnect" button stays grayed out and saying Disconnecting

Expected behavior
Button should disconnect the wallet and say Select Wallet
Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

OS: macOS
Browser: Arc (Chromium)
I'm using Phantom browser extension: Phantom 23.5.0

Additional context
Theres this related issue but this is NOT a solution for me: https://github.com/solana-labs/wallet-adapter/issues/755
    "@solana/wallet-adapter-base": "^0.9.22",
    "@solana/wallet-adapter-react": "^0.15.32",
    "@solana/wallet-adapter-react-ui": "^0.9.31",
    "@solana/wallet-adapter-wallets": "^0.19.16",

last issue in april, last commit in april, i wonder if this is still being actively maintained 🤔

@jnwng any ideas?

Can you tell me if the bug happens on this page using Phantom?
https://solana-labs.github.io/wallet-adapter/example/

it does
Im actually stuck on this screen even after a refresh

Im speaking of the react ui one

If it isn't happening on the example app linked above, it's likely not a bug with Wallet Adapter and something in the configuration of your project. I'd like to help but unfortunately without seeing the code of your project, I won't be able to tell why it's happening there. I'm going to close this issue, but if you follow up with a link to a repository of your project, I'll take a look.

same issue I have got error WalletDisconnectedError


Feature: Integer, Number, and more

Added Function:
CreateInstance(Class, Name, RandomName)
Description:
Allows for easy creation of instances from one place.

Commit 2:
Added Functions:
isOdd(number)
isEven(number)
calculateHalf(number)
absoluteValue(number)
maximum(a, b)
minimum(a, b)
round(number)
power(base, exponent)
squareRoot(number)
sine(number)
cosine(number)
tangent(number)
randomInRange(min, max)
Description:
Makes interacting with Integers on roblox easier

I adjusted a few areas of this PR.
Most importantly, I saw that most of the added methods don't bring any additions to Lua.
However I like the idea of having the Number and Integer sub-modules.
calculateHalf was converted into Integer.divide(input, divisor) -> floor, ceil which helps facilitate code re-usability and adds additional functionality that could have been included before.

Created LA.Lego.Instance.create.
I'm not 100% on the naming for this one, but the method is now consistent with the rest of the library.

Added Color.lua
Added Functions:
rgbToHsv(red, green, blue)
rgbToHtml(red, green, blue)
hsvToRgb(hue, saturation, value)
hsvToHtml(hue, saturation, value)
htmlToRgb(htmlColorCode)
htmlToHsv(htmlColorCode)
Description:
Allows for converting colors

@WillFJS awaiting your review

@MidSpike This ever gonna be closed? 😂


Add link

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

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/guide/architecture-styles/cqrs.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


New projection engine rebase + fixes

WIP

Hey, is it ok if I make HotChocolate.Data.ThrowHelper public? I did happen to need throws from there at some point when writing the ownership library.

There are some really cool bits in here already :) nicely done
I guess there are a lot of open point (all the temp stuff, rewrtier which is merely a PoC, how we provide both implementations and how we maybe can do most of the work in the operation compiler).
I think we should setup a zoom call together with @michaelstaib . Are you up for this @AntonC9018 ?

I don't mind a call. Nonetheless, I think written communication is more suitable for this purpose, as it leads to natural documentation. I like to come back to some of your messages after a while of coding, having understood the system a bit more.

Let's do a call as it will lead to faster transfer. We can update the issue later.

So I'm trying to debug a test. In particular, this one. It fails because this code is run before the projections, which saves the parent as the original object instead of object[], which makes it fail later with a cast exception. Is the test setup wrong, or does this logic of saving the parent before projection just assume that the projection result is going to be the same type?

I need help with debugging here. I don't understand how the pipeline works, because it's too abstracted. And I cannot debug normally, because the middleware delegates are created at runtime here. Past that method, the debugger becomes useless for understanding the bigger picture.

I think not using interfaces for the middleware invocations was a terrible decision. There should just be an interface IMiddleware with InvokeAsync that all of them should implement. Otherwise the code becomes literally undebuggable. And you'll need it if you migrate to AOT (no runtime delegate compilation is allowed there, iirc). This should probably go in a different PR though.

Can you explain what's this conversion thing for?

I think not using interfaces for the middleware invocations was a terrible decision. There should just be an interface IMiddleware with InvokeAsync that all of them should implement. Otherwise the code becomes literally undebuggable. And you'll need it if you migrate to AOT (no runtime delegate compilation is allowed there, iirc). This should probably go in a different PR though.

It's not a terrible decision. You loose flexibility by enforcing the interface. e.g. you cannot use value injections into InvokeAsync. MS also does not longer do it.
It's also possible to compile it this way in AOT.

Can you explain what's this conversion thing for?

It's for the value converters that you can register on the schema. mostly used for scalar, but i belive also used for things like nullabe structs or custom converters in complex types.

Can you explain what's this conversion thing for?

It's for the value converters that you can register on the schema. mostly used for scalar, but i belive also used for things like nullabe structs or custom converters in complex types. @michaelstaib can give you certanly more examples

This should definitely not be called when working with object[] after a projection. Right?

Regarding middleware this is not true. I have a branch that uses source generators for compilation.

It's not a terrible decision. You loose flexibility by enforcing the interface. e.g. you cannot use value injections into InvokeAsync. MS also does not longer do it.
It's also possible to compile it this way in AOT.

The best way to achieve value injections without compromising debuggability is by generating adapters with source generators.
You don't lose any flexibility, if you generate an adapter - inject whatever you want. What you gain is readable, debuggable, straightforward code - instead of magical dynamic delegates you get e.g. property accesses.
It's a real pain to debug your code, I'm being serious.

Shucks, it won't even work correctly with interfaces or unions at this point. But I still don't understand why you need the parent objects in the result tree. Shouldn't it just have the leaf nodes, and just point to types in the intermediate nodes?

Shucks, it won't even work correctly with interfaces or unions at this point. But I still don't understand why you need the (converted) parent objects in the result tree. Shouldn't it just have the leaf nodes, and just point to types in the intermediate nodes?

We dont need the converted parent objects. We want to operate on the object[] there. The converters in this PR are only for resolvers that need them. we rewrite the selections to work on the object[].  The interfaces and object array have a fallback check that we manually set at the moment. How we best integrate this into the operation is is something that we have to discuss. Because at the moment it is implemented on a schema level just for the PoC
https://github.com/ChilliCream/graphql-platform/blob/5f112e3fc0607104c2e27df8d84f01c8295b8e3d/src/HotChocolate/Data/src/Data/Projections/Extensions/ProjectionsSchemaBuilderExtensions.cs#L46-L66

Hold on, what are the intermediate objects used for in the result tree then? The leaf nodes already store the values that will be returned to the client, and the intermediate "parents" are already available in their raw form on the resolver context, ready to be converted for the Parent call. So why are they stored at all? It doesn't make sense to me.

I think returning the whole parent object here is unfair to the user. They don't even have a way to check if a field has been included in the projection (well, they kinda could check the selections, but I don't expect a regular user to do so). How about returning a proxy object that would provide access to particular properties?
...([Parent] ProxyObject<Parent> proxy)
{
    var name = proxy.Get(p => p.Name);
    if (name.IsProjected)
        return name.Value;
}

Or maybe source generating a proxy
...([Parent] PersonProxy proxy)
{
    var prop = proxy.Name;
    if (prop.IsProjected)
        return prop.Value;
}


Disable flaky grpc_authz test case on mac

based on historical data, this seems to be the test case that is responsible for vast majority of flakiness (see https://source.cloud.google.com/results/invocations/ce30bd5a-e0ba-4c02-8e8b-7c54e2b243da/targets/%2F%2Ftest%2Fcore%2Fend2end:h2_full_no_retry_test@grpc_authz/log for reference)
fix the test label printed to the logs (so actually we want to disable test_file_watcher_recovers_from_failure)

This time the actually test_file_watcher_valid_policy_reload test case has failed:
https://source.cloud.google.com/results/invocations/5ed60307-4c02-4633-8a14-dc9f95f579bc/targets/%2F%2Ftest%2Fcore%2Fend2end:h2_fd_test@grpc_authz/log

Thank you for updating the test name. I will close my PR (https://github.com/grpc/grpc/pull/29920/files) then.
https://screenshot.googleplex.com/9do2iJQkQyCbpG3.png
The tests fail with deadline exceeded error and the delay is usually in grpc_load_file block. Somehow it takes several seconds for load file to complete. I have some more runs to try out, will update the bug soon with more details.


docs: update Russian translation for the whole React guide

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

This PR was closed and then re-opened in an attempt to clear a specific Travis build failure

@greggubarev I resolved the frontmatter issues which CamperBot mentioned above and was the reason the build failed.  That is why just closing and reopening the PR did not resolve the Travis failure.  If you have reviewed the content, feel free to merge it now.

LGTM 👍  Congrats on your first contribution!

Thank you for the PR ✨ 🎉 We're happy to accept these changes and look forward to your future contributions.
Happy coding!


Update MakeConnection and stub creation functions to use Options modified by stub creation functions instead of just a copy of the Options provided (PubSubLite).

Stub factories are fully generated. Also, we hate this service.


feat: add FastAPI Router include_router method, fix #497

Support FastAPI routers nesting:
router = self.router_class()
router2 = self.router_class()
router.broker = self.broker_test(router.broker)

app = FastAPI(lifespan=router.lifespan_context)

@router.subscriber(queue)
async def hello():
    return "hi"

@router2.subscriber(queue + "1")
async def hello_router2():
    return "hi"

router.include_router(router2)

Fix TestKafkaBroker.publish and publish_batch methods to support batch consumers

Closes #497


Obsidian Web Clipper need optimization for bilingual format

This plugin needs optimization. If using a bilingual format, the translated content (using chrome translation plugin) is not indented, making it difficult to read. Other clipper plugins have indented formats, which are more readable.

Which translation plugin are you using?

Which translation plugin are you using?

https://immersivetranslate.com/

Which translation plugin are you using?

https://immersivetranslate.com/


replace links to /docs/concepts/cluster-administration/addons/ with /ja/docs/

closes #28505

/assign @nasa9084

/lgtm

/approve


Allow rendering ViewModel directly

Solves #2.

Closing in favor of #4, as the patch I introduce does not introduce a new concrete method, but instead re-uses the method defined in TemplateRendererInterface to accommodate view model instances.


Display 1 Entry Per CSV File Successfully Submitted (i.e. Filter out Errors)

Problem Statement
Currently, all actions are shown in the submission history, which will be very confusing for Senders.  Senders want to see one entry per CSV file that they successfully uploaded.
Acceptance Criteria

Given I

Am logged into ReportStream as a Sender OR RS Prime Admin

When I

Choose to view my submission history (or for any Sender when Primary Admin)

Then I

See 1 entry per CSV file that I successfully uploaded (i.e. remove submissions that produced errors)

Submission history server-side does not support dynamic filtering.
Options:

Remove entries on client
Pros: no server changes, easy/quick to do.
Cons: because this list is paged, the page sizes can vary in length as items are removed. If the ratio of removed items approaches the page size, empty pages could be an issue.
Modify current API to always filter out errors.
Pros: Relatively easy server side change.
Cons: More work than Option 1. Will impact other users of the API and needs more through review since we don't want break API calls others may be using.
Add filtering parameters/support to API call.
Pros: This is where we eventually want to get. Can be done in way to not break backward compatibility.
Cons: A LOT more work than other options. New code to process filters and filter results. API change but in compatible way, but still needs more regression tests, etc. Longer to implement.

Related to work https://github.com/cdcgov/prime-reportstream/issues/1556


[detect] Add support for public endpoint with boards, procuct codes etc.

There is now a public https://www.mbed.com/api/v1/boards/ endpoint. It exposes all public boards. It contains information about product code, features, targets (classic, mbed os 5, yotta) and more. There is also similar endpoint on developer.mbed.org site but it requires token to get this information.
See IOTWEB-1105 for more details.

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.


Updated hostapd to v2.5

Motivation for this change
Keeping hostapd up to date. This version ships with, e.g. Gentoo (and I have been using it on that OS), so I believe this update is reasonable.
I have been testing this version on NixOS for the last couple of days via an addition to my configuration.nix.
I'm new to Nix and am not really sure how to do any of the below tests :/
Things done

[ ] Tested using sandboxing
(nix.useChroot on NixOS,
or option build-use-chroot in nix.conf
on non-NixOS)
Built on platform(s)

[ ] NixOS
[ ] OS X
[ ] Linux

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Fits CONTRIBUTING.md.

Welcome!
The update itself looks fine. We tend to name our commits like "foo: 1.0 -> 1.1". About tests:

Enable nix.useChroot in your NixOS configuration, rebuild and if the package still builds after that things are okay. Most likely they will.
You have already built the package on NixOS AFAIU, so you can tick off the box.
Run the command nix-shell -p nox --run "nox-review wip --against HEAD~1" on this branch -- it's almost like an advised one but will run tests between current state and HEAD~1 instead of HEAD.
You have already tested how the binary runs by testing hostapd itself, so you may tick the box.
CONTRIBUTING.md's two main points are:

You agree to license your work under MIT-like license.
 I will follow these guidelines for my future submissions. Thanks also for the heads-up about licensing -- I am happy with MIT, but hadn't actually considered from this perspective.
Haha, thanks @garbas. I do indeed promise to do it right the next time.
Out of interest, I was intending on working through all the checkboxes, but I had trouble with the sandbox one: Adding nix.useSandbox to my configuration.nix appeared to be correct (if only because I first added nix.useChroot as suggested, and nixos-rebuild complained that that was deprecated). However, since the package was already in my store, it wouldn't rebuild hostapd even if I 'uninstalled' it first.
I tried nix-collect-garbage --delete-old after removing hostapd from my environment.systemPackages, but it still didn't seem to get rid of it. What did I miss here?
I don't suppose it's too important; I'll just keep nix.useSandbox there going forward. Still, everything I can learn helps my understanding...


toc.ncx isn't configured properly.

Describe the bug
The Table of Contents renders the names of the chapters but does not link them to the chapters themselves.
To Reproduce
Steps to reproduce the behavior:

Install Lithium on your mobile device.
Load up the EPUB file, and the text is alright.
Click on the table of contents on the right side panel for any chapter.
See error.

Expected behavior
The table of contents must allow for the user to navigate throughout the book.
Desktop (please complete the following information):

OS: Android
Lithium

Additional context
Addition of a cover would also be pretty nice.

Edit
The problem lied with the toc.xhtml and not the toc.ncx for a good reason. There was no toc.ncx.
Issue
The issue lied with the fact that the entire path from C: was given as the link rather than just the basename.
Solution
Just added a os.path.basename() to fix it.
End result
The table of contents now ensures that navigation is possible.


Milestone1 list structure

This is the first milestone of the to-do list project in this milestone below features are added.

Set up webpack for the project
HTML Structure for adding todo list with placeholder
JS object to list todo items
Added linters

@BrianSammit , @FrederickMih
Thanks for your review.


Drill to detail gives error on some charts when using Druid.

Bug description
We recently upgraded Superset from version 2.1.1 to 3.1.1 and encountered errors with certain charts when attempting to access the drill-down detail window.
How to reproduce the bug
Error arises when attempting to open the drill-down detail popup window.
Screenshots/recordings
An example chart that gives error. It is a line chart with some advance analytic options.

Error shown on web

Superset log
Traceback (most recent call last):
  File "/app/superset/connectors/sqla/models.py", line 1795, in query
    df = self.database.get_df(sql, self.schema, mutator=assign_column_label)
  File "/app/superset/models/core.py", line 612, in get_df
    self.db_engine_spec.execute(cursor, sqls[-1])
  File "/app/superset/db_engine_specs/base.py", line 1596, in execute
    raise cls.get_dbapi_mapped_exception(ex) from ex
  File "/app/superset/db_engine_specs/base.py", line 1594, in execute
    cursor.execute(query)
  File "/usr/local/lib/python3.9/site-packages/pydruid/db/api.py", line 62, in g
    return f(self, *args, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/pydruid/db/api.py", line 256, in execute
    first_row = next(results)
  File "/usr/local/lib/python3.9/site-packages/pydruid/db/api.py", line 362, in _stream_query
    msg = "{error} ({errorClass}): {errorMessage}".format(**payload)
KeyError: 'errorClass'

Superset version
3.1.1
Python version
3.9
Node version
16
Browser
Chrome
Additional context
druid version: 27.0.0
pydruid: 0.6.5
Checklist

[X] I have searched Superset docs and Slack and didn't find a solution to my problem.
[X] I have searched the GitHub issue tracker and didn't find a similar bug report.
[X] I have checked Superset's logs for errors and if I found a relevant Python stacktrace, I included it here as text in the "additional context" section.

Hmmm.... I'm unable to reproduce this so far on the latest master (or pretty close to it, anyway). Are you able to make a chart with built-in example data, so we can try to reproduce this effectively?

It occurs only on druid datasources. Unfortunately I'm not able to reproduce it with example data.

Ahh... ok, that helps. Let me clarify the title and labeling.

This issue still exists on 4.0.0 fyi

Pinging the Druid folks from the rolodex for potential reproduction/debugging:
@betodealmeida
@sujiplr
@nytai
@villebro

I have ran into the same issue. The failure pattern is when I have a UNION ALL, CTE, etc. the charts add a SUM over the metric.
Copy pasting the query from the Superset view query into DRUID returns
"Error: UNSUPPORTED (OPERATOR)
Unhandled Query Planning Failure, see broker logs for details"
Is there a way to generate charts over the SQL query directly instead of aggregating again in Druid?

Let's see what the robots think... @dosu-bot

There's clearly a pydruid bug here - while surfacing another problem. It would help to see the underlying SQL. You should be able to click the [View Query] in the context menu, maybe there's something in that SQL that Druid doesn't like.

@betodealmeida and me are both pydruid maintainer and could help address the issue there, where we should not trust that the payload has bot have certain keys like we seem to do given the stacktrace.

This will fix the error that happens while reporting the other error. I submitted this just because it's an easy fix: https://github.com/druid-io/pydruid/pull/322
This will only enable us to have more visibility into the route error that triggers this, but without it we don't have a good stacktrace. It'd be great if someone can path their local with that quick fix so that we can see the actual error that pydruid hits

For people who have a druid env setup, you may be able to do a quick manual fix in your python environment with the edit in my PR to get more intel and share it here.
@StephanPF the query you share does not look like a drill-to-details-type query. I'd expect to see something more like a SELECT *  with current filters/predicates applied and no GROUP BY clause

@mistercrunch happy to help here but I'll need some guidance. Do you mind reaching out in PM?
Note: The query from my previous message was "View query" not "Drill to details" - I'm not sure how to get the drill to details query..

One way to log the query to stdout is to add this to your superset_config.py
def SQL_QUERY_MUTATOR(  # pylint: disable=invalid-name,unused-argument
    sql: str, **kwargs: Any
) -> str:
    print("DEBUG: " + sql)
    return sql

I'm pretty sure the drill-to-details query - as all other queries - should go through this SQL_QUERY_MUTATOR, and here we're just printing the query to catch it - assuming you have a dev environment setup connect to druid.
One could also probably monitor on the druid side and see what queries hit the system when you happen to click on drill-to-details.

This issue still persist on 4.1.0rc1. It gives below error
Error: druidException (INVALID_INPUT): Column 'metric_is_freezed' not found in any table (line [142], column [13])
We have a user defined metric. It is working on chart edit but I dont know why drill to detail using it and throw error.

I think drill to details adds in "Calculated Columns" defined in at the dataset level and will fail if there's an error in any of them. I just hit a similar issue and deleting the calculated column fixed things.
To prevent this, maybe the metric editor and calculated column editor could have a "validate" button that would force people to fix things. There are some scenarios though where the underlying dataset can change and calculated columns expressions can break as a result. Maybe we should just SELECT * by default and have a checkbox to "Include calculated column" as an option (?)

@iercan can you confirm that metric_is_freezed is referenced in one of your "Calculated Columns" (in the Dataset Editor), and that deleting or fixing this calculated metric fixes your issue?

@mistercrunch Yes. Removing the calculated column resolved the issue.


[Question] Is the 'frames' command necessary?

Just wondering if there is a reason to keep the 'frames' command when the frame id is already given in the 'log' command? Especially since the 'log' command allows a from-to span applied to limit the results that are returned.
If there's not a specific reason to leave it as-is, I'd suggest either removing it or aliasing it to the 'log' command.
Thanks!
Scott

It is needed by the Bash completion.

Ah, that answers my question, thanks!


Log additional error properties

Currently, when using SQL mode and a migration contains a syntax error, db-migrate will only print the error message and call stack:
[ERROR] AssertionError [ERR_ASSERTION]: ifError got unwanted exception: syntax error at or near ")"
    at node_modules/db-migrate/lib/commands/on-complete.js:15:14
    at tryCatcher (node_modules/bluebird/js/release/util.js:16:23)
    at Promise.successAdapter (node_modules/bluebird/js/release/nodeify.js:22:30)
    at Promise._settlePromise (node_modules/bluebird/js/release/promise.js:601:21)
    at Promise._settlePromiseCtx (node_modules/bluebird/js/release/promise.js:641:10)
    at _drainQueueStep (node_modules/bluebird/js/release/async.js:97:12)
    at _drainQueue (node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (node_modules/bluebird/js/release/async.js:102:5)
    at Async.drainQueues [as _onImmediate] (node_modules/bluebird/js/release/async.js:15:14)
    at process.processImmediate (node:internal/timers:476:21)
    at Parser.parseErrorMessage (node_modules/pg-protocol/dist/parser.js:287:98)
    at Parser.handlePacket (node_modules/pg-protocol/dist/parser.js:126:29)
    at Parser.parse (node_modules/pg-protocol/dist/parser.js:39:38)
    at Socket.<anonymous> (node_modules/pg-protocol/dist/index.js:11:42)
    at Socket.emit (node:events:513:28)
    at addChunk (node:internal/streams/readable:324:12)
    at readableAddChunk (node:internal/streams/readable:297:9)
    at Readable.push (node:internal/streams/readable:234:10)
    at TCP.onStreamRead (node:internal/stream_base_commons:190:23)

Even for a medium sized migration SQL file, syntax error at or near ")" can be like finding a needle in a haystack.
When using pg, the Error actually contains additional information with the exact position of the syntax error. But currently, that information is not logged, as explicitly only the stack of the error is logged.
This PR changes it so that the entire error object is logged. Node's behavior when an Error is passed to console.error() (which is used under the hood by log.js) is to log only the stack property if there are no additional properties, meaning there would be no difference in those cases.
But if there are additional properties, Node will log both the stack with message, and any properties after it:

In particular, the position here can be copy-pasted into an editor's "go to position" command to jump exactly to the syntax error in the SQL file.
Other properties can be helpful in case e.g. a DB constraints gets violated by the migration, as it can contain the constraint name, offending column values, etc.
One small change is also necessary to make sure the error gets properly logged: Throw the actual error if it's an Error instance instead of wrapping it in an AssertionError, as the AssertionError just adds additional noise to the log and since the Error gets nested under the actual property, it doesn't get expanded in the log but reduced to only [DatabaseError].
There may be a small benefit in wrapping in an error given the error may not be an Error instance, but if it is, it makes more sense to throw the error directly.

I'm not sure I understand – isn't the stack still logged in the screenshot above? The information logged now is a strict superset of what was logged before

The stack does not get logged by default on all error objects. That is why.

Are you sure? What's an example of an error object that wouldn't have the stack logged by console.log()?

For reference, here's the code branch in NodeJS that formats errors:
https://github.com/nodejs/node/blob/1e3631f0e392eeac327c33aeb56f590814ba5c39/lib/internal/util/inspect.js#L983-L984
isError() returns true for any Error instance, even from other realms (see https://nodejs.org/api/util.html#utiltypesisnativeerrorvalue).
If for some reason a non-Error instance was to be thrown with a stack property, it would still get logged as a property of a plain object, just not formatted quite as pretty. I think that is an okay trade-off because that's kind of what you have to expect when throwing a non-Error instance, it's not going to get formatted as an Error, but as an object with properties and values. It would actually still print information than currently, because currently no other properties on such object except stack get logged.
Note also that the current code already doesn't support this case well, for example if somebody was to throw null the current code would throw because it's trying to read stack of null. The code in this PR would actually handle this more gracefully.
But if you'd like I could add an extra if that checks for the case of a non-Error object with a stack property and in that case log the stack instead.


Remove section on disabling GraphQL introspection

Disabling introspection on GraphQL should be considered an anti-pattern because

It is security through obscurity
Breaks a significant feature of GraphQL

While many developers reach for it based on previous experiences of not exposing documentation to the public, it has been well established in the Elixir community for a long time that it is not recommended. I'd suggest reaching out in the Elixir slack #absinthe-graphql for further discussion. Unfortunately the chat history is long lost, but sentiment likely remains.
I understand this is a subjective opinion, but I think it's pretty controversial overall to include this section.

I'd love to have a discussion about it's inclusion / exclusion:
While the intention of this section isn't fully clear yet due to a WIP adjustment, the idea with this section is to outline that we believe GraphQL Introspection should be disabled on Production systems and optionally allow for it in Development environments. Additionally, one could allow for the bypassing of this filtering on Production via mechanisms like SimpleTokenAuth.
Here is a related blog post from Apollo on why they believe Introspection should be disabled. Additionally, OWASP outlines disablement as a Secure Configuration Best Practice on their "cheat sheet" series.
Due to the above reasons I would lean towards leaving it as is in the training material, but it would definitely be worth considering adding additional clarification to the lesson that by itself it is not an all encompassing protection and fully outline the "protections" that disabling introspection affords.

Thanks for the reply Holden.
The OWASP page is good 👍 - Glad both pages mention that this is security by obscurity. Protecting introspection by authorization is a nicer middle ground than completely disabling it.
It would be great to discuss these nuances rather than blanket suggesting disabling it.
Cheers!


simple_server.cpp

Tiny errors... Must be header files problem.. Contribute if you have any idea... No need to put high pressure because I am also working over the issue... Just try your best =)

Simple Client-Server issues in Cpp as this brother server (https://github.com/Geek-Research-Lab/Operating-Systems/issues/1) had a bug. Cpp sockets are quite suicidal. Tried a simple one in Java (https://github.com/dragonwolverines/SocketProgramming) long time back though. For now, closing this issue https://github.com/Geek-Research-Lab/Operating-Systems/issues/2 as well as https://github.com/Geek-Research-Lab/Operating-Systems/issues/1


Alternative wallet icons (for discussion only)

Current icons:

Why home is a face? Why a contract is a text? Why network is a motorcycle?
My, IMHO, personal suggestions:
For home:

For address book (just alternatives):

For contract:

For network selection:

For token (coin): nothing found ;(

token ?

and the 'link' icon makes sense to me for token/+network, but may be confusing since its kind of ubiquitous..

That's just a prototype at the moment. We'll make a good design, don't worry :) I have a designer working on this stuff, just not ready yet

hahaha, i chose most of the icons randomly as placeholders. Don't take them too seriously :)

@elaineo I am going to switch back to coding, end of test session, finally ;)

addressed heer: https://github.com/ethereumproject/emerald-wallet/issues/252


[WFLY-17774] Update SmallRye OpenTelemetry to a version with Issue #223 fixed

https://issues.redhat.com/browse/WFLY-17774
Upgrade SmallRye OpenTelemetry to 2.3.1
(Also fixes sr-otel issue #224)

This looks good to me with the exception of the import order that Brian pointed out.

Shoot. I thought I had fixed those. I'll get those fixed for real as soon as I can.
Thanks.

Thanks @jasondlee


afollestad-master

Hey @patelkarn! Nice work on the quality profiles. Feel free to reach out to me or @sugarmanz if you have any questions!

Hey @tylerkrupicka thanks I will definitely take you up on that if I have any questions. I was trying to merge the new changes onto my fork but wound up doing it wrong and created a pull request here.


build: Update known-good files for 1.2.151 header

Changes:

Updated known_good.json
Generated new source files

These changes are almost through internal CI.

Aaaaand it passed.


⚠ OC Society has degraded performance

In 00cf3a0, OC Society (https://www.ocsociety.org) experienced degraded performance:

HTTP code: 200
Response time: 11455 ms

Resolved: OC Society performance has improved in 38748ec after 8 minutes.


Account changing only password not possible

In 0.10.5 it's not possible to only change the password without changing any of the other properties.
Calling a.password = "test" will not make the account dirty and therefore a a.save does not update the model in the database. Setting a.name and then calling a.save will update the model correctly.

You need to pass also confirmation.
a.update_attributes(:password => 'tester', :password_confirmation => 'tester')
Always check errors.
puts a.errors.full_messages unless a.valid?

I am sorry, I just tested that again. If you change only the password in the admin interface and nothing else, the @account.update method does nothing. It returns true but does not save the new password.

It seems that the issue is still reoccurring on our version of Padrino (v.0.12.2). The password seems like it updates (by update confirmation) when a new password is entered but it doesn't update the database.
However, when updating one of the other fields as well the password, the passwordupdates successfully.
Can this be reopened?

Fixed for DataMapper, checked for ActiveRecord, Sequel, MongoMapper.


Not working

Speaker control functions
speaker.mute()
speaker.unmute()
speaker.set()
speaker.increase()
speaker.decrease()
not working at all

can you try the 3.0.5 version ?

It works now. Thank you


Queries to last cache with large IN list predicates seem slow

The performance team has observed that when querying the last cache with IN clauses with ~100 elements leads to response times on the order of ~30ms.
For example,
SELECT * FROM last_cache('table_name', 'cache_name') where key_columns IN ('random value 1', .... 'random value 100');

This issue is for tracking whether or not this can be improved.

Adding the stats and details in here.
Observations - Single and Multiple series (10 and 100 series) on PRO

Single series and 10 series last value cache based query the results are returned in less than 10 ms as expected
For 100 series we observe results returned is less than 40 ms
Resource usage does not yield any red flags (memory is 22%)

Note: Not necessarily a problem, I believe Paul did mention for 100 series the expected latency is 20ms (+10ms for every 100 series).

To be fair, the numbers I mentioned were just guesses at what I thought good performance might look like. We should still look into this though :)

Based on the concerns raised as part of https://github.com/influxdata/influxdb/issues/25562 , we need to keep this issue open.

@MaduMitha-Ravi - agreed. I still have a suspicion that there is an underlying concurrency problem (https://github.com/influxdata/influxdb/issues/25615). Hopefully we can resolve that first and then isolate issues in the last cache.


Several supported options

Hi.
EBSI, as multi use-case project, supports several options for

revocation
VC format
Signing algorithms

However, the profile definition requires only one value.

@alenhorvat we had this discussion in the last meeting that a profile has sometimes multiple values.
In case we allow multiple entries for one resource, we are not able to compare profiles by their features (e.g. one of the revocation features supports privacy, the other one does not. What does that mean for the privacy aspect looking at the whole profile?
The current solution is to define multiple profiles with a unique name, like the case with anoncreds:

Anoncreds can be realised with did:indy, did:web, did:sov: so we would call the profile "Anoncreds with did:indy", and so on.

The resulting TODO out of this question is how to we want to define a profile and what is the outcoming purpose of it
Your mentioned case with EBSI is special because in my opinion it is not a profile, but just a system for key management (it was added to the list before we challenged the criteria of a profile definition)
The TODO of this question is to remove all incomplete profiles from the list and to only allow the onces that have a specification like MDL that is defined by ISO.

Hi. Ok. Then we'll register several profiles accordingly.
EBSI does contain several profiles (for both B2C/G2C and B2B/G2G VC exchange) and "system for key management" is only one of its features. Interesting to hear such a conclusion since the 2 main profiles have been presented in an OWF meeting.
See also end-to-end conformance tests: https://api-conformance.ebsi.eu/docs/wallet-conformance
Here you can find more information about key management, revocation, selective disclosure, ... https://api-conformance.ebsi.eu/docs/specs/credential-status-framework/credential-status-strategies
Thank you.
Issue can be closed.

The question how to define a profile is not fully answered yet. The idea with referencing only one resource allows you to query profiles like "show all profiles that have crypto agility".
Do you know in which meeting it was? Maybe the recording of it can give me some good information :)

The EBSI profile is btw a good example for the different use cases and problems. In the case we define a separate profile for each possible combination. EBSI has 5 credential status VCs and two methods for the holder (legal entities and natural persons). So only with these parameters we would have 10 different profiles that needs to be added to the list. But not every profile with each selection has its own specification. So this would be a good reason to allow 1 to n linking for resources.

Reopening this issue since the question is not really answered.

Hi.
It was a meeting where other profiles like mDL, Duch profile, HAIP and others were presented. @tlodderstedt can maybe help to identify the exact meeting.
Note that ISO mDL has a similar structure (this is only 18013-7)

there are several signing algorithms (I believe the number of supported algorithms is > 5)
2 revocation approaches: CRL, OCSP
2 presentation protocols (mDL REST API and OID4VP) - OID4VP has at least two options for client_schema_id - hence at least 3 variants

I also understand the simplicity/complexity of expressing the different profile(s) where some are very specific and focused on a single use case (or even closed systems), whereas others need to cater for a larger number of use cases (where we know that different variants appear due to different business/security/privacy requirements). It is also important to understand from which businesses the different profiles originate and where they are being tested/piloted/used. We learned at EBSI that something that works well for one use case might require a lot of bending to fit it into another use case.
Great work! Thank you very much. It's not an easy task.

I agree, ISO mdoc needs to be further detailed into multiple profiles. In the end, the number of profiles makes transparent how many options implementations need to support. Perhaps that inspires people to remove option to make interoperability easier.
Note, however:
ISO does not have a revocation mechanism for mdocs. It uses the expiration to control validity. Protocols are out of scope for credential formats (at least for now).

Great. I agree. Let us know whether 1:1 or 1:n approach is going to be used/supported.
ISO manages all key revocations using CRL and/or OCSP (issuer keys, device keys), depending on the key/certificate type. Without a valid device key and device certificate (x509), the mdoc cannot be presented. Hence mdoc can be revoked indirectly by revoking the device key.
ISO profile needs to support both: x509 and mdoc-related credential formats.
(outside of the scope of this specification)

You are mixing the format of the credential and the format used to convey keys and trust chain information. Credential revocation is about the first aspect.
Indeed, revoking the key/trust chain of an issuer might invalidate the credentials issued by that issuer (if there is no time bound validation, e.g. using trust lists) is in place. I would not see that as credential revocation. Perhaps we need to tighten the definition of this category a bit.
Indeed, a certain format (x.509) can also be a credential format in which case CRL and so on kick in. But that's a different profile (one could meta in relationship to mdoc).

I am closing this since we agreed in the future, that a profile is only having one resource (like one signing algorithm). Otherwise it is not possible to compare them: when my profile has two signing algorithm, but only one of them supports ZKPs, does the profile then supports it or not? I am not a fan of (*), so it seems to be cleaner to add multiple profiles where the user can filter them.


MJ bug fixes and unit adds

Hi, in this pull request I have put the following updates:-

Changed div() to divide() in the examples and POD
Changed the test failing on quadmath systems
Added the planetary units to Unit.pm
Thanks

Merged via ff2cf538148c2bb5df4395231379cb778eff41f8


mail configuration

In config file there is
config.email
but if i activated i get this error
undefined method `email='

Hi Rich,
Installed your gem today with Rails 5.  It worked incredibly well.  Thank you so much!
I would love to use the email notification feature.
After I set  email: true, what else do I need to do?
Are there further instructions somewhere?
Thank you!

Hi @nlyczak unfortunately this is not in the system yet - I have a new version slated for release soon that will include it for sure.

Email has been included in 0.6.5, more instructions on the way.


Badge request: Microsoft Store

Please add a badge for Microsoft Store apps, e.g.
https://www.microsoft.com/store/p/nuget-package-explorer/9wzdncrdmdm3
9wzdncrdmdm3 is the app id

Hi there! Thanks for the suggestion. Is there a public API that provides this information?

That link says you can only get package information for your own packages once authenticated with your account. That doesn't appear flexible enough for a shield badge.

Gotcha. Thanks for tracking down that information.
P.S. Thanks also for contributing to our Open Collective! 🌟

I made one with undocumented API.
https://github.com/JasonWei512/Microsoft-Store-Badge


Release broken - main.js missing

This is probaly the cause the pligin cannot be found in the community plugins. ???

It's not yet validated by Obsidian's teams. Where did you install it from?

https://github.com/kalvn/obsidian-export-to-html/releases/tag/1.0.1
main.js is there as you can see.


Thank you for the mention !

You are very welcome, your library gave me some good ideas and helped me as a reference.


Make a target for the SOHL land cover data

The SOHL land cover data is not being automatically recognized by the function that scans ScienceBase. We'll need to add this data to the pipeline manually. That could be done in a couple of ways:

After the table of ScienceBase links is fetched, create a target that adds a row for the SOHL data. I think this works best for use in our current workflow.
Create a separate target that fetches the SOHL data.

From @ajsekell: this happened because item_list_children() has a default max limit of 20 items. Increasing that limit resulted in retrieving the SOHL land cover item in the table of ScienceBase links.
I'm going to link this issue with the ScienceBase PR #54

Addressed in #75


Releasedocs0 7

@nwf tagging you to see the shape I'm thinking about.  I'll generate graphs tomorrow, if you think this makes sense?  The text needs some polish too.

@SchrodingerZhu  would you be able to check what I say about polite waiting is correct?  Thanks

@SchrodingerZhu would you be able to check what I say about polite waiting is correct? Thanks

Looks good!


[IMPROVED] Added case-sensitivity option to selection sort.

Often case-sensitivity of lines sort is undesirable - added case-insensitive counterparts of ascending and descending sorts actions.

Hey! Thanks for this - sorry it took me so long to get to it, been busy with other sutff :)
:beers:

You're welcome, thanks for cool plugin!


frogmouth: update from xdg to xdg-base-dirs

Description of changes
Previously, running frogmouth resulted in a stack trace where frogmouth was unable to find xdg and could not start.
Now, the two places where xdg is imported are patched to use xdg_base_dirs.
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

@figsoda Here's an update/fix for you, as the maintainer of this package. 💌
I'll work to make the correct fix upstream.

Oh, I see you had already made this patch but it got rejected upstream. https://github.com/Textualize/frogmouth/pull/59. Sad! Well, at least we can have nice things on NixOS.

I've replaced the previous patch with a one-line sed command.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/2814


Pre release into master

Change description
Pre-release changes into pre-master
Does this PR introduce a breaking change? (check one with "x")
[x] Yes
[ ] No

Unwanted


"Either" really means "Any"

In English, "either" means a choice between two ("Choose either A or B). For three or more, the word is "any" (Choose any of these: A, B, C, or D). The "either" keyword is jarring and confusing.
How about changing "Either" to "Any", because that seems to be the syntax--"any of the following".

Yes, this is planned as it makes definitely more sense. It was discussed in #8 but having an extra issue for that isn't too bad.

@KarimGeiger Ah sorry, didn't see #8.


Ensure the cached env values do not get stale

Update the cached info after getenv()/setenv() (or let/unlet).

An empty $HOME value is likely to cause trouble, better keep the old value until a new one is set.


Kernel name

Hi guys,
I'm booting on the last ARM kernel "armv7l 4.5.7 std #2 (latest)".
Unfortunately the kernel name is not well defined:
# uname -r
4.5.7CONFIG_EPOLL-std-2

Which result in an error when trying to sync the kernel modules with scw-sync-kernel-modules :(
Thanks,
Adrien

Hi @Bacto
Yes we will fix it.

Fixed from a code POV, will be fixed in production soon

It works. Thanks guys :)


Make execute_block return an ExecutedBlock.

Motivation
We are still handling a block's outgoing messages and state hash separately in some places. Using the ExecutedBlock type is simpler.
Proposal
Use ExecutedBlock more.
Test Plan
This doesn't add new logic.
Links
N/A
Release Plan

[x] All good!
[ ] Need to bump the major/minor version number in the next release of the crates.
[ ] Need to update the developer manual.
[ ] This PR is adding or removing Cargo features.
[ ] Release is blocked and/or tracked by other issues (see links above)

Reviewer Checklist

[ ] The title and the summary of the PR are short and descriptive.
[ ] The proposed solution achieves the goals stated in the PR.
[ ] The test plan is reproducible and provides sufficient coverage.
[ ] The release plan is adequate.
[ ] The commits correspond to distinct logical changes.
[ ] The code follows the coding guidelines.
[ ] The proposed changes look correct.
[ ] The CI is passing.
[ ] All of the above!

I was going to argue that both copies got used in the chain manager, so it's no additional clone. But that's not even true for the single-owner manager. :upside_down_face:


NodeJS v0.12 Cluster Mode - undefined symbol: node_module_register

As the title says, when I run our app in cluster mode using NodeJS v0.12 I get the above error:
uncaughtException: /opt/builds/CURRENT/node_modules/sharp/build/Release/sharp.node: undefined symbol: node_module_register
However if I run this without clustering turned on, then it is fine, no errors.
For additional information I am using PM2 for my process management which also handles the cluster or normal fork mode.

Hi Iqbal, that error message looks like the sort of problem you might encounter when an addon is compiled against one version of Node and run against another.
Might a fresh installation/compilation via something like rm -rf node_modules;npm install help here?

Hi Lovell,
I did try that, unfortunately no luck, I am using NVM to manage my node versions while my system version is Node 0.10.
I don't suppose that should cause a problem should it when compiling sharp? I have set the node version to 0.12 using NVM so unless somehow sharp is still using the system wide installation.
Though node -v will give me 0.12.

The version of Node made available to node-gyp when npm install is used needs to match the version of Node at runtime.
It might be that there's a global node-gyp being picked up. npm uninstall -g node-gyp should remove it if so.

I've checked, no global node-gyp installed, could there be anything else you suspect?

"I have set the node version to 0.12 using NVM so unless somehow sharp is still using the system wide installation."

node_module_register was added to Node in v0.11.11 so sharp has been compiled against that version or later but is being run against an earlier version.
My best guess is that sharp is using 0.12 but pm2 is using 0.10.

Yes your right PM2 was using an older version, though the error was a bit misleading.

Glad to hear you got it working.


RPC Executor improvements

debug_executionWitness currently needs to output all state required to execute the given block. The endpoint currently does not work for optimism because it needs to use the optimism executor, and the eth mainnet system calls may be different from optimism. It also needs to retain more execution-related information than is desired for the vanilla executor.
The debug_executionWitness endpoint
The endpoint needs to return the following information:

all state that was accessed or changed during block execution

including system calls and transactions

all code loaded during execution
merkle proofs for the state accessed / changed during block execution

We need to leave the current executor as-is, so we don't do more than needed during regular block processing.
A new executor
So, we now have the BlockAccessListExecutor, which implements the Executor trait:
https://github.com/paradigmxyz/reth/blob/9760319f3427dba39f431871011d3fb9ad9b3b41/crates/ethereum/evm/src/execute.rs#L392
This is a new executor that retains the accessed state in the BundleState of the BlockExecutionOutput. There is also one for optimism. This separate executor meets all requirements for the endpoint, but we still need to make this executor accessible to the RPC endpoint.
Executors in RPC
We currently have the BlockExecutorProvider, which provides multiple types of executors for RPC to use:
https://github.com/paradigmxyz/reth/blob/9760319f3427dba39f431871011d3fb9ad9b3b41/crates/evm/src/execute.rs#L110-L123
This PR includes a third type of executor to include in the BlockExecutorProvider trait: https://github.com/paradigmxyz/reth/pull/10868
We can either:

pursue this direction further, or
change how we get executors for rpc somehow

cc @mattsse

debug_executionWitness currently needs to output all state required to execute the given block. The endpoint currently does not work for optimism because it needs to use the optimism executor, and the eth mainnet system calls may be different from optimism. It also needs to retain more execution-related information than is desired for the vanilla executor.
The debug_executionWitness endpoint
The endpoint needs to return the following information:

all state that was accessed or changed during block execution

including system calls and transactions

all code loaded during execution

merkle proofs for the state accessed / changed during block execution

We need to leave the current executor as-is, so we don't do more than needed during regular block processing.
A new executor
So, we now have the BlockAccessListExecutor, which implements the Executor trait:
https://github.com/paradigmxyz/reth/blob/9760319f3427dba39f431871011d3fb9ad9b3b41/crates/ethereum/evm/src/execute.rs#L392
This is a new executor that retains the accessed state in the BundleState of the BlockExecutionOutput. There is also one for optimism. This separate executor meets all requirements for the endpoint, but we still need to make this executor accessible to the RPC endpoint.
Executors in RPC
We currently have the BlockExecutorProvider, which provides multiple types of executors for RPC to use:
https://github.com/paradigmxyz/reth/blob/9760319f3427dba39f431871011d3fb9ad9b3b41/crates/evm/src/execute.rs#L110-L123
This PR includes a third type of executor to include in the BlockExecutorProvider trait: #10868
We can either:

pursue this direction further, or
change how we get executors for rpc somehow

cc @mattsse

I'm not sure but I think it should be made custom, would solve the compatibility issue easily

closing this because this is now integrated, rpc improvements tracked #11122


support webgl functions in syntax highlighting

Happy to PR this, but I'm not entirely sure how to add in webgl-mode functions in syntax highlighting.  Thanks!

That would be great - that stuff lives over in this repo: https://github.com/antiboredom/brace/blob/master/mode/javascript.js#L61


Add negative tests for state circuit

Adds an overrides: HashMap<(test::AdviceColumn, usize), F>, to StateCircuit for tests. Assignements to entries in this hash map will be overridden in tests, allowing us to verify that specific constraints aren't satisfied when assignemnts are wrong.
The first two such tests are address_limb_out_of_range and address_limb_mismatch in zkevm-circuits/src/state_circuit/test.rs.

i am doing some experiments with state circuit recently.
write some suggestions here:
(1) in RLC chip, use "power_of_randomness: [Expression; 31]," rather than columns to enable more flexible implementations. Like evm circuit

(1) in RLC chip, use "power_of_randomness: [Expression; 31]," rather than columns to enable more flexible implementations. Like evm circuit

How do I get the query expressions for a column without calling meta.create_gate?


Small accessibility fixes

A recent audit of the tech docs gem identified a few issues. Most of these were fixed automatically by updating the gem, but there were a couple of things that needed fixing by hand:

f21c86b - add row-level headings to tables that need them
1fd2e7c - remove a duplicate link to / in the header

I think this is all of the issues that affect us from this checklist

the doc seems to say that we should use a space after the #?

Ah, not actually true. I changed my mind mid way through implementing the row level headings feature, so it works with or without the space now.


Discuss the use of sqlx and its presence in libzkchannels-crypto

The dependency on sqlx is keeping us from updating our dependency on bls12-381. This is not great, and we should look into untangling sqlx from libzkchannels-crypto at the very least. Or maybe even look at alternatives.

@gijsvl I know this was a while ago, do you know what exactly was causing the update issue?


Adding and updating docs and removing obsolete folders

This Pr is to add 2 new walkthroughs a template for future walkthroughs changes to the current walkthroughs to align with new template. Wdyt of the template yah or nay? I also removed folders that were duplicates and organised the docs folder a little bit

/approve
/lgtm


[3.1][Error] Implement localizedDescription using _swift_Foundation_getErrorDefaultUserInfo

Cherry picks #810.
This should return an appropriate value instead of the fixed "The operation could not be completed".

@swift-ci please test

Let's take the fix as-is for 3.1 and apply Alex's feedback on master.

@swift-ci test and merge


Add custom move events to contract

We need to add custom Dojo events to track important game actions in the Mancala game. This will improve the user experience by allowing the frontend to react to game state changes and provide better visual feedback.
Events to Add
1. Capture Event
Purpose: Track when a player captures seeds from opponent's pit
#[derive(Copy, Drop, Serde)]
#[dojo::event(historical: true)]
struct Capture {
    #[key]
    game_id: u128,
    player: ContractAddress,
    pit_number: u8,
    seed_count: u8,
}

2. End Turn Event
Purpose: Signal when a player's turn ends and next player begins
#[derive(Copy, Drop, Serde)]
#[dojo::event(historical: true)]
struct EndTurn {
    #[key]
    game_id: u128,
    current_player: ContractAddress,
    next_player: ContractAddress,
}

3. Extra Turn Event
Purpose: Indicate when a player earns an extra turn
#[derive(Copy, Drop, Serde)]
#[dojo::event(historical: true)]
struct PlayerExtraTurn {
    #[key]
    game_id: u128,
    player: ContractAddress,
}

Implementation Tasks

Event Definitions

[ ] Add event structures in events/index.cairo
[ ] Create trait implementations in events/move.cairo

Store Updates

[ ] Add emission methods in store.cairo

Game Logic Integration

[ ] Modify move function in components/playable to emit Capture, EndTurn & ExtraTurn event

Hi @okhaimie-dev can I quickly implement this?
ETA: 24hrs


plot_trans only works for head.fif surface.

AFAIK we could also use outer_skin.surf to plot the head surface.

you suggest to try to find outer_skin.surf is head.fif is not present?

Yes. Or allow to pass a param or smth.

I prefer to detect it automatically and do not add a parameter. It's fine
with me as it's not doing any computation nore creating new files.

We should also use high res head shapes if they are present?

We can modify head parameter from True (current behavior, use head.fif) to other things like 'best' or something. @jaeilepp you want to do it, or should I?

I'll take a look.


cl20 cl21 cl22: Lost fix - Proposed fix for bug 16239

Looks like fix for test_half in cl_utils.c proposed by b-sumner was lost

All PRs merged, closing.


how to use end method for v4

I used this in version 2 to find out that mathjsx has finished rendering
 window.MathJax.Hub.Register.StartupHook('End', function () {           // some Write code         });
What should I do now in version 4?
I also used those convert tools, it says:
Version 3 uses promises rather than signals and queues
window.MathJax.Hub.Register.StartupHook('End', function () {
    });

I did not understand what to do

When MathJax was first written in 2008, there were few tools available in Javascript to handle coordination of asynchronous tasks, so we developed our own library based on queues, signals and callbacks.  Since then, javascript has been expanded to include standard techniques for asynchronous coordination via the ES6 notation of promises, and the rewrite of MathJax for v3 switched to using promises rather than it non-standard queues and signals.
See the documentation for Performing Actions After Typesetting for details about how to synchronize your code with MathJax's initial typesetting.  Note, however, that there is a bug in the handling of MathJax.startup-promise (see #3130) that will be fixed in the next beta release, so you should use the second approach given in the section cited above to avoid that.


fix: ideal height is 800

This is so the window isn't super tiny when first opening it. I think most modern Mac systems probably have a good enough screen resolution to default to 800.

☀


Support for Cuttlefish Android Virtual device

I am trying to work through the example here: https://google.github.io/bumble/platforms/android.html to give a cuttlefish Android Virtual device access to my ubuntu hosts bluetooth radio
The work involved seems to be figuring out a way to bridge my local hosts BT controller and the android virtual devices host BT stack.
On the host side:
The board I am using comes with BT (I did not have to attach an additional USB BT dongle). I was able to verify the USB transport with
python3 examples/run_classic_discovery.py $USB

### This printed out classic BT devices that were previously visible from the BT app on ubuntu

On the Android Virtual Device side:
I've launched cuttlefish following instructions here: https://source.android.com/docs/setup/create/cuttlefish-use
The default launch seems to be launching netsimd as well with the following params:
/home/ubuntu/cf/bin/netsimd -s {"devices":[{"name":"<IP_ADDRESS>:6520","chips":[{"kind":"BLUETOOTH","fdIn":121,"fdOut":122}]}]} --hci_port=7300 --instance_num=1

I found the grpc port using
ubuntu@mtk-genio:~/cf$ cat $XDG_RUNTIME_DIR/netsim.ini
web.port=7681
grpc.port=39069

Now to bridge the two, my understanding is that I need to run the HCI bridge with the android-netsim in host mode and my physical radio
Something like this
python3 apps/hci_bridge.py android-netsim:localhost:39069,mode=host $USB

This seems to be causing crashes in the bluetooth app and also killing the netsim process (Still rootcausing the issue)
The alternative is to follow this path: https://google.github.io/bumble/platforms/android.html#connecting-a-custom-virtual-controller
However, I'm unsure on the equivalent launch config to --packet-streamer-endpoint for cuttlefish
I was hoping to kick start this issue in hopes to know if im on the right path and if someone has already got this working for cuttlefish and not just the android emulator?

Usually I use tcp-client:<IP_ADDRESS>:7300 connecting to Cuttlefish's rootcanal directly, but I am not sure what's the policy of netsim.

What you’re trying to do here (connect cuttlefish to a radio), can be done, but not via netsim. Netsim is a virtual Bluetooth controller (radio) that two (or more) virtual devices can connect to and communicate with each other through. But physical devices can’t connect to netsim. What you want here (and what’s done with the Android Studio emulator on the doc you’re pointing to), is to connect cuttlefish to your physical controller. With Studio’s emulator, the emulator connects to the controller using gRPC over a TCP socket, so we run a Bumble transport in gRPC server mode, to accept the connection, and then bridge it to some other controller (in your case that would be your Linux controller). Cuttlefish is different, it doesn’t use gRPC for this, it connects to a controller via a local file descriptors (fdIn and fdOut in the netsim parameters you list here) So we need to 1/ run an HCI bridge between a file descriptor and your Linux BT controller, 2/ tell Cuttlefish to not start its own netsim to talk to, but talk to the bridge instead. I’ll follow up here shortly with some details on how to do this (typing this from my phone now, can’t try out cuttlefish).

Usually I use tcp-client:<IP_ADDRESS>:7300 connecting to Cuttlefish's rootcanal directly, but I am not sure what's the policy of netsim.

@zxzxwu I did try that too
Essentially launched cuttlefish with the netsim_bt=false param and then tried the HCI bridge
python3 hci_bride tcp-client:localhost:7300 $USB

I didnt really see the BT devices show up in the BT android app. Did the same work for you?
Can you share your setup with me please?

@barbibulle TY for your response! That makes sense!
Awaiting the details :)
In the meantime, I will play around with this on my end too!

Ok, here are the details:
You need to use the -rootcanal_instance_num= option, and optionally -base_instance_num=, with launch_cvd to tell it to forward HCI packets to an external "instance" of rootcanal (the virtual Bluetooth controller that's part of netsim), which in our case isn't going to actually be rootcanal, but the bumble HCI bridge in "controller" mode, presenting the same interface as rootcanal/netsim would, therefore receiving the packets and forwarding them to/from some other HCI transport, which would be your Linux HCI in your case.
There are two options:
1/

Start the HCI bridge as the second "instance" (instances are 1-based, so that's instance=2), with: python apps/hci_bridge.py android-netsim:_:<some-port>,mode=controller,instance=2 <some-other-hci-transport>
Launch cuttlefish as the first "instance", with launch_cvd --rootcanal_instance_num=2

or
2/

Start the HCI bridge as the first "instance", with python apps/hci_bridge.py android-netsim:_:<some-port>,mode=controller <some-other-hci-transport>
Launch cuttlefish as the second "instance", with launch_cvd -base_instance_num=2 --rootcanal_instance_num=1

(note that in this case we omitted the instance= part of the Bumble specifier, because the current version of Bumble doesn't yet implement the 1-based contract that cuttlefish and rootcanal use, so instance=1 wouldn't be recognized as the "default instance". We'll fix that in a later version, but for now, simply omitting the instance number does the right thing.)

Hey @barbibulle ty for the help! the instructions you provided worked out of the box :)
Closing issue


chore: add timer value to signals

Description

Related Issue

Motivation and Context

How Has This Been Tested?

Screenshots (if appropriate):
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[ ] I have signed the Adobe Open Source CLA.
[ ] My code follows the code style of this project.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have read the CONTRIBUTING document.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

I think "feat" is usually better than "chore" for new functionality.  But either way we can squash merge it all in with a "feat"


Fixing refresh for multi managed domain environment.

Fixes how server groups are associated with domains and servers with server groups when multiple domains are present.
It does 3 things, all are needed.

adding _object to ignored keys - this fixes the https://bugzilla.redhat.com/show_bug.cgi?id=1394040
the feed id must match when finding the appropriate server group - fixes https://bugzilla.redhat.com/show_bug.cgi?id=1403775
resetting the @data[:middleware_server_groups] during the refresh for each feed. This led to the bug that if there were 2 domains the second had the server groups from the first one.

@miq-bot add_labels providers/hawkular, bug

@rubenvp8510 could you please do a review?

@pilhuhn euwe yes or no?

This LGTM

Can this go in?
@miq-bot assign @bronaghs

I was going to suggest adding a spec test for at least the parser change but i don't see any specs around fetching domains/server groups, maybe I missed them? Maybe a GH issue should be created for a general enhancement to the parser specs.
Otherwise this LGTM

@miq-bot assign @blomquisg


Ronak/custom code

Make canvas items clickable to switch code
Refactor clear canvas button to clear whole project

This has been merged into the migration branch


Request for \choose syntax support

How should the input text representation look like

{5 \choose 3}

How should the ASCII art output look like

⎛ 5 ⎞
⎝ 3 ⎠

Describe in what context you would use this notation

Discrete Math, Probability, Counting, Statistics

Additional context
Given the design of the "choose" notation adding a third, middle row is also an option.
⎛ 5 ⎞
⎜   ⎟
⎝ 3 ⎠

I wonder why the syntax of \frac{x}{y} is like this and choose is {x \choose y}. I would have to explore a bit in the parser to support this.


chokidar doesn't notice changes under weird path

In windows 7 I attempt to run the following script:
chokidar = require('chokidar')
fs = require('fs')

path = "APCS (3.0)2\\burrito.txt"
console.info(fs.lstatSync(path)) # path exists
watcher = chokidar.watch(path)
watcher.on('change', (path) -> console.info("path: #{path} changed"))

setTimeout(( -> 1), 50000)

chokidar never notices file changes to burrito.txt.

likely a dupe of #300


2.19.0-RC2 EnvelopesApi -> getEnvelope hard-coded to API v2

Howdy,
The release commit here - https://github.com/docusign/docusign-java-client/releases/tag/v2.19.0-RC2 - says the 2.19.0-RC2 release is meant to support v2.1-20.4.01 of the REST API, however, in at least this one code path, it's still calling API V2.
The outcome here is that I can make a call like this:
GetEnvelopeOptions envelopeOptions = envelopesApi.new GetEnvelopeOptions();
envelopeOptions.setInclude("recipients");
Envelope env = envelopesApi.getEnvelope(accountId, envelopeId, envelopeOptions);
Recipients recipients = env.getRecipients();

And it will look like everything is working fine, the code will compile, etc, except that recipients will always be null in the last line, because include=recipients was reserved for DocuSign use in V2 - https://developers.docusign.com/docs/esign-rest-api/v2/reference/envelopes/envelopes/get/
It would have been a lot faster to figure this out if the SDK threw a NotImplementedException or something along those lines when it's passed invalid options.
Cheers!

(I should also note I'm guessing this thing is code gen'd via swagger or the like, so it probably can't throw an exception there, but it would still be nice if it could!)

@mkornblum first of all apologies for not responding in a more timely manner. Everything you said makes sense. The "release notes" for version 2.19.0-RC2 had a typo and it should say v2-20.4.01. The typo has been fixed now (thanks to you).
For more information about this SDK's version 2.x VS 3.x please have a quick look on this page (although the exact minor and patch versions might not be up-to-date): https://developers.docusign.com/docs/esign-rest-api/esign101/upgrading-v21/#sdks
If you want to use the latest from the eSign API, you should migrate to version 3 of this SDK. Most of integrations shouldn't see any/lot of breaking changes. Also API v2 is being put on maintenance mode and will be sunset soon. I encourage you to look at the link in the previous paragraph to lean about feature changes between the two versions so you'll have a good idea how much effort is needed for the migration.

thanks for your help!


Invite new suppliers via UI

We have a CLI command to invite a supplier with his contract ID and NIT. It would be good to have this feature in the OCP Admin panel as well so that any OCP admin could send the invitation without having to log into the server and run the CLI command.

@yolile me interesa este pero no esyo seguro si la entiendo completamente.
Podemos conversars sobre esto?

Noting that https://github.com/open-contracting/credere-backend/issues/245 is an alternative approach, but I think this request comes up very infrequently.


Attempt at more robust time-sensitive concurrency tests

By running SAs on larger problems, we transfer more weight to
computationally intensive parts, which should benefit the most from
the parallelism. Hopefully, this will tip the scale to get us into
a more robust regime on resource-starved CI VMs.

Codecov Report

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

@@           Coverage Diff           @@
##           master     #196   +/-   ##
=======================================
  Coverage   88.23%   88.23%
=======================================
  Files          16       16
  Lines        1666     1666
=======================================
  Hits         1470     1470
  Misses        196      196

Continue to review full report at Codecov.

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

Codecov Report

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

@@           Coverage Diff           @@
##           master     #196   +/-   ##
=======================================
  Coverage   88.23%   88.23%
=======================================
  Files          16       16
  Lines        1666     1666
=======================================
  Hits         1470     1470
  Misses        196      196

Continue to review full report at Codecov.

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

Codecov Report

Merging #196 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
+ Coverage   88.23%   88.29%   +0.06%
==========================================
  Files          16       16
  Lines        1666     1666
==========================================
+ Hits         1470     1471       +1
+ Misses        196      195       -1

Impacted Files
Coverage Δ

hybrid/flow.py
93.09% <0%> (+0.27%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #196 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
+ Coverage   88.23%   88.29%   +0.06%
==========================================
  Files          16       16
  Lines        1666     1666
==========================================
+ Hits         1470     1471       +1
+ Misses        196      195       -1

Impacted Files
Coverage Δ

hybrid/flow.py
93.09% <0%> (+0.27%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

Merging #196 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
+ Coverage   88.23%   88.29%   +0.06%
==========================================
  Files          16       16
  Lines        1666     1666
==========================================
+ Hits         1470     1471       +1
+ Misses        196      195       -1

Impacted Files
Coverage Δ

hybrid/flow.py
93.09% <0%> (+0.27%)
:arrow_up:

Continue to review full report at Codecov.

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

Codecov Report

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

@@           Coverage Diff           @@
##           master     #196   +/-   ##
=======================================
  Coverage   88.23%   88.23%
=======================================
  Files          16       16
  Lines        1666     1666
=======================================
  Hits         1470     1470
  Misses        196      196

Continue to review full report at Codecov.

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

Codecov Report

Merging #196 into master will increase coverage by 0.06%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #196      +/-   ##
==========================================
+ Coverage   88.23%   88.29%   +0.06%
==========================================
  Files          16       16
  Lines        1666     1666
==========================================
+ Hits         1470     1471       +1
+ Misses        196      195       -1

Impacted Files
Coverage Δ

hybrid/flow.py
93.09% <0%> (+0.27%)
:arrow_up:

Continue to review full report at Codecov.

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


Reimplement Dropdown Component

Current implementation required hacky fixes in Hub and Connect.
Investigating Radix Dropdown vs having to rebuild the component.

Fixed dropdown to avoid abslute positioned items.


🚀 Feature: Add separate audit log event stream

🔖 Feature description
This feature aims to add an audit log event stream which involves implementing a dedicated system for tracking and recording critical security-related events and actions within Backstage. This separate event stream ensures that security-sensitive activities such as user authentication, authorization, data access, and configuration changes are logged independently from regular operational logs. By maintaining a distinct audit log event stream, organizations can enhance security, facilitate compliance with regulatory requirements, enable efficient incident response, and uphold the integrity of critical audit data.
🎤 Context
Importance of Audit Logging:

Enhance Security: Tracking critical security-related events such as user authentication, authorization, and data access bolsters the protection of your Backstage instance against unauthorized activities.

Ensure Compliance: Fulfill regulatory requirements by logging configuration changes and other security-sensitive operations, aiding your organization in adhering to industry standards.

Enable Investigation: Detailed event tracking facilitates forensic analysis and investigation of security incidents, empowering administrators to swiftly identify and respond to security breaches.

Maintain Integrity: Implementing restricted access and robust tamper-proof measures upholds the integrity of audit logs, ensuring the reliability and accuracy of recorded events.

Why Separate Audit Logging?

Security and Integrity: Segregating audit logs ensures higher security measures, such as restricted access and encryption, safeguarding sensitive information from unauthorized tampering or access.

Regulatory Compliance: Compliance frameworks necessitate organizations to maintain audit logs for security and accountability purposes. Separating audit logs from normal logs aids in managing and verifying compliance requirements more efficiently.

Event Filtering and Analysis: Independent audit log event streams facilitate filtering and analysis of security-related events, enabling efficient monitoring, detection, and investigation of security incidents without interference from non-security-related events.

Performance and Scalability: Optimizing performance and scalability, separating audit logs allows dedicated resources and configurations tailored specifically for the requirements of audit logging, capturing critical events with higher frequency and granularity.

Clear Differentiation: Separating audit logs from normal logs helps distinguish security-related events from other operational events, simplifying troubleshooting, debugging, and monitoring processes.

In summary, maintaining a separate event stream for audit logging ensures that security-critical events are handled with appropriate security measures, compliance adherence, and efficiency, while also optimizing performance and clarity in event management and analysis.
✌ Possible Implementation
The only necessary adjustments involve expanding Backstage's Winston configuration to accommodate a distinct audit log event stream: link.
For instance, you can refer to this implementation: link.
By implementing this change, users can maintain a separate audit log event stream while retaining the existing normal log event stream. For example:
// This message is exclusively recorded in the audit log event stream
logger.log({ level: 'info', message: 'This is an audit log message', isAuditLog: true })

// This message remains unchanged and appears in the normal log event stream
logger.log({ level: 'info', message: 'This is a log message' })

👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

I'm a bit unsure about how the Winston implementation works in Backstage. Which specific file(s) should I edit to make adjustments? I noticed that createRootLogger is referenced in the current backend. However, WinstonLogger is utilized in dynamicPluginsRootLoggerServiceFactory, designed for the dynamic backend. Is there a way to streamline this setup to facilitate easier modifications in the future? I feel like the current implementation is overly complicated and confusing. Ideally, I believe we should remove the Winston wrapper implementation WinstonLogger and stick with createRootLogger.

In an attempt to answer this -- there's the legacy backend (what is linked first) and then there's the new backend system (not linked) and I think the dynamic backend is something under development.
With the "new" backend system (default in current releases) you can replace the default logging service implementation but you'll have to use backend.createSpecializedBackend(services) with your service factory implementations (e.g. for the root logger or other logging). rather than backend.create() which uses all the default service factories.

Thanks for raising this issue - it's been coming up from time-to-time, but there does not exist something like this yet. Just want to refer to some ongoing/older discussions here to have the context available:

https://github.com/backstage/backstage/issues/8219#issuecomment-979931788
https://github.com/backstage/backstage/issues/10652#issuecomment-1119099275
https://github.com/backstage/backstage/issues/1519#issuecomment-947788686

Comments from @Rugvip on discord.
https://discord.com/channels/687207715902193673/687235481154617364/1227301762634088581

We're moving over to the LoggerService being the way to log: https://backstage.io/docs/backend-system/core-services/logger. The WintsonLogger is the basis for the default implementation of that, but it's ofc possible to switch out

https://discord.com/channels/687207715902193673/687235481154617364/1227303938705981492

I find it to be very similar to structured logging, just even more structured. I don't think it needs a ton of frameworkification, just some good handling of users etc. You might for example let it consume the new credentials objects and derive fields from the principals that executed an action.

Prolly worth having it be a separate interface from the logger service though, but then likely have a default implementation that just forwards it to the logger.

Hard part is what kind of information plugins are supposed to provide at this point imo, and what level of guarantees we want thay particular actions were actually executed, and the granularity.

Bit hard to prioritize against a lot of the other things going on too so I don't think it's realistically something that can be added in the next few months tbh.

Quick update on this and how to move it forward. I think it makes sense to add as such, but needs more refinement as discussed above. Next step would be a BEP that starts outlining goals and suggesting a concrete implementation.

Quick update on this and how to move it forward. I think it makes sense to add as such, but needs more refinement as discussed above. Next step would be a BEP that starts outlining goals and suggesting a concrete implementation.

Great! I will start working on creating a BEP.

Not stale

not stale


assertThrown!Error and assertNotThrown!Error should be nothrow

andrej.mitrovich reported this on 2014-04-25T12:49:18Z
Transfered from https://issues.dlang.org/show_bug.cgi?id=12645
CC List

monarchdodra

Description
-----
import std.exception;

void main() nothrow
{
    // should be marked nothrow
    assertThrown!Error( { throw new Error(""); }() );

    // ditto
    assertNotThrown!Error( { }() );
}
-----

test.d(8): Error: 'std.exception.assertThrown!(Error, void).assertThrown' is not nothrow
test.d(11): Error: 'std.exception.assertNotThrown!(Error, void).assertNotThrown' is not nothrow
test.d(5): Error: function 'D main' is nothrow yet may throw

The way to handle this is to make these two templates wrap function templates inside, and use a static if section to mark one of the code paths as nothrow.

andrej.mitrovich commented on 2014-04-25T13:40:57Z
This is invalid since Exception is not derived from Error, so catching Errors will not catch those Exceptions.

k.hara.pg commented on 2014-04-25T14:05:58Z
This is a possible enhancement, blocked by issue 12647.

monarchdodra commented on 2014-04-25T15:35:52Z
(In reply to Kenji Hara from comment #4)
> (In reply to monarchdodra from comment #3)
> > (In reply to Kenji Hara from comment #2)
> > > This is a possible enhancement, blocked by issue 12647.
> >
> > 12647 was made invalid. assertNotThrown!Error Really has no reason to be
> > nothrow, since it can legally throw exceptions.
>
> I agree with that the issue 12646 is invalid, but the newly filed issue
> 12647 is different thing.

Ah right. I didn't realize the inference was wrong. I thought we were just asking for "always" nothrow.

monarchdodra commented on 2014-04-25T15:16:13Z
(In reply to Kenji Hara from comment #2)
> This is a possible enhancement, blocked by issue 12647.

12647 was made invalid. assertNotThrown!Error Really has no reason to be nothrow, since it can legally throw exceptions.

k.hara.pg commented on 2014-04-25T15:27:35Z
(In reply to monarchdodra from comment #3)
> (In reply to Kenji Hara from comment #2)
> > This is a possible enhancement, blocked by issue 12647.
>
> 12647 was made invalid. assertNotThrown!Error Really has no reason to be
> nothrow, since it can legally throw exceptions.

I agree with that the issue 12646 is invalid, but the newly filed issue 12647 is different thing.


fix: use next build dir when finding required server files

Fixes #61
Uses nextBuildDir instead of the standalone build dir when getting required-server-files.json. This would resolve to ${nextjsPath}/.next/required-server-files.json.

Thanks! I think this makes sense to do. The original reason to use the standalone path was to use its canonical files generated in standalone mode. But if .next contents is identical to the standalone/path/to/web/.next, then this is a better/simpler solution.

Thanks! I think this makes sense to do. The original reason to use the standalone path was to use its canonical files generated in standalone mode. But if .next contents is identical to the standalone/path/to/web/.next, then this is a better/simpler solution.

Actually, what I think it should do is use nextStandaloneDir instead of nextStandaloneBuildDir

Thanks! I think this makes sense to do. The original reason to use the standalone path was to use its canonical files generated in standalone mode. But if .next contents is identical to the standalone/path/to/web/.next, then this is a better/simpler solution.

I think what actually needs done is nextjsPath should not be added to nextStandaloneBuildDir


Changes are not applied when context lines are present

Changes are not applied when context lines are present.
When there's no context line, the changes applied just fine.
But when there's context line, the changes even on the search word is not applied at all.
And when changes are applied the second time, it seems like the lines that the search word is in are replaced with the first few context lines.

Confirmed. Please try to fix it! I use this extension on a daily basis and it's very cumbersome to have to hide context lines all the time 🙏


doc updates - adding Quickstart Guide for Bicep and TF

Overview/Summary
This PR will include updates to the documentationn.
This PR fixes/adds/changes/removes

Added a quickstart guide with

overview page
Bicep and Terraform specific pages

Configured the site to support Microsoft Clarity

Menu placement:

Key features include short videos:

Breaking Changes

Retiring Bicep deployment question/guidance from the FAQ

As part of this Pull Request I have

[x] Read the Contribution Guide and ensured this PR is compliant with the guide
[x] Checked for duplicate Pull Requests
[ ] Associated it with relevant GitHub Issues or ADO Work Items (Internal Only)
[x] Ensured my code/branch is up-to-date with the latest changes in the main branch
[x] Ensured PR tests are passing
[x] Updated relevant and associated documentation (e.g. Contribution Guide, Docs etc.)

@Azure/avm-core-team, please review this PR as soon as possible, so we can release our first wave of QuickStart guidance.
@eriqua, @AlexanderSehr, @jtracey93, @segraef @jeanchg- can one of you please review the Bicep page and also take a look at the root QuickStart page?
@matt-FFFFFF, @mbilalamjad, @jaredfholgate, @segraef, @PmeshramPM - can one of you please review the Terraform page and also take a look at the root QuickStart page?
Note that @ReneHezser, @jchancellor-ms and myself tried to review each other's work in rotation, but you may have additional suggestions. My main ask for those suggestions that would require significant re-work would be to please save them for v2 - as we really need to release the first version of these guides before Wednesday.
Thank you!