client streaming

I was working with an application that required having bidirectional streaming and I was wondering if there are any way that would enable me to send message then wait for its response without having to prepare all the message queue before hand

The the method on the generated client will look something like this:
pub async fn bidirectional_stream(
    &mut self,
    request: impl IntoStreamingRequest<Message = BidirectionalStreamRequest>
) -> Result<Response<Streaming<BidirectionalStreamReply>>, Status>

Where IntoStreamingRequest is implemented  for T: Stream<Item = Message>. If you don't know all the message upfront you'll normally use ReceiverStream to turn a tokio::sync::mpsc::Recevier into a Stream. That allows you to send messages with the corresponding Sender half whenever the server has something to send.
Waiting for responses from the server will require manually coordinating the two streams.
Does that answer your question?

I'm not sure,
what I meant was that my application at the client side have to wait for the next client message to be prepared, after a response for the first client message is attained from the server.
how can I manipulate the request sent to the bidirectional function after sending the first client message in order to put the second client message upon ready in the queue

I don't understand what you mean. Do you mean that you want to wait for the server to send a message after the client sends something? If so that is done by sending a message on the client to server stream and then calling Streaming::message. You get a Streaming when setting up the bidirectional stream.

Not exactly my point,
at the client side I'm currently using futures::stream::iter to pass a vector of client messages that I would want to push some messages to after I get the response from the server to the first client message because my second message depends on the server response.
However I can't push new messages to the streaming request that I created after sending it to the bidirectional function

shortly if I am using a code like this how can I avoid prefilling the vector and be able to append messages to it after getting server responses
let channel = tonic::transport::Channel::from_static("http://[::1]:50051")
            .connect()
            .await?;
        let mut client = SayClient::new(channel);
    // creating a client
        let request = tonic::Request::new(iter(vec![
            SayRequest {
                name: String::from("a"),
            },
            SayRequest {
                name: String::from("b"),
            },
            SayRequest {
                name: String::from("c"),
            },
        ]));
    // calling rpc
        let mut response = client.bidirectional(request).await?.into_inner();
    // listening on the response stream
        while let Some(res) = response.message().await? {
            println!("NOTE = {:?}", res);
        }
        ```

You should be able to do what I was trying to say in my previous message. Instead of using futures::stream::iter use ReceiverStream. Messages can be put into the stream using the corresponding Sender you get when creating the Receiver.
Something like this (just off the top of my head and not tested):
// create the channel
let (tx, rx) = tokio::sync::mpsc::channel(1024);

// setup the stream
let stream = ReceiverStream::new(rx);
let request = tonic::Request::new(stream);
let mut response = client.bidirectional(request).await?.into_inner();

// send some messages
tx.send(SayRequest { name: "a".to_string() }).await?;
tx.send(SayRequest { name: "b".to_string() }).await?;

// wait for a response
while let Some(msg) = response.message().await? {
    dbg!(msg);
}

// send some more messages
tx.send(SayRequest { name: "c".to_string() }).await?;

the line
let stream = ReceiverStream::new(rx);

throws this error
expected struct tokio::sync::mpsc::bounded::Receiver, found struct tokio::sync::mpsc::Receiver
I believe that tokio::sync::mpsc::Receiver  is already a bounded reciever

Are you pulling in two versions of tokio?
This works for me
fn main() {
    let (tx, rx) = tokio::sync::mpsc::channel::<()>(1024);
    let stream = tokio_stream::wrappers::ReceiverStream::new(rx);

    // test that `stream` actually implements `Stream`
    assert_is_stream(stream);
}

fn assert_is_stream<T: futures::Stream>(_: T) {}

If not please share more of your code.

I'm using
tokio = {version="0.2.18",features = ["stream", "macros"]}
tokio-stream = "0.1.5"

tokio-stream depends on tokio 1.x so you are pulling in both tokio 0.2 and 1. Are you able to update to tokio 1?
You can also run cargo tree -i tokio to see exactly which crates depends on tokio. That'll tell you if you're using two different versions.

whenever I edit to the tokio 1.4.0 I can't find stream among the features and I get this error as a result
the trait futures::Stream is not implemented for tokio::sync::mpsc::Receiver<Result<S erverMessage, tonic::Status>>

That is what tokio_stream::wrappers::ReceiverStream is for. Its a wrapper that turns a Receiver into a `Stream.


Fix link in split mode

This broke the build in the CLICKHOUSE_ONE_SHARED mode:
$ ninja dbms/programs/CMakeFiles/clickhouse.dir/main.cpp.o
[1/1] Building CXX object dbms/programs/CMakeFiles/clickhouse.dir/main.cpp.o
FAILED: dbms/programs/CMakeFiles/clickhouse.dir/main.cpp.o
/nix/store/ghzg4kg0sjif58smj2lfm2bdvjwim85y-gcc-wrapper-7.4.0/bin/g++   -I../libs/libcommon/include -Ilibs/libcommon/include -Idbms/programs -I../dbms/src -Idbms/src -I../contrib/cityhash102/include -I../contrib/croaring -isystem /nix/store/0ik3xn1kc2qnp1dmydlcsfbmj9wc8vkh-double-conversion-3.1.3/include -isystem /nix/store/07k9vinbs4l7lirif3d8jla5bv9qy6wk-boost-1.67.0-dev/include -isystem /nix/store/mv25hcpasj2ddjmg3hsmcralwqq9qc0h-re2-20140304/include -isystem ../contrib/libpcg-random/include -fdiagnostics-color=always  -pipe -msse4.1 -msse4.2 -mpopcnt  -fno-omit-frame-pointer  -Wall  -Wnon-virtual-dtor -Wextra -O3 -DNDEBUG -fPIE   -fno-tree-loop-distribute-patterns -pthread -std=c++1z -MD -MT dbms/programs/CMakeFiles/clickhouse.dir/main.cpp.o -MF dbms/programs/CMakeFiles/clickhouse.dir/main.cpp.o.d -o dbms/programs/CMakeFiles/clickhouse.dir/main.cpp.o -c ../dbms/programs/main.cpp
In file included from ../dbms/programs/main.cpp:21:0:
../dbms/programs/server/Server.h:5:10: fatal error: daemon/BaseDaemon.h: No such file or directory
 #include <daemon/BaseDaemon.h>
          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.

target_link_libraries (clickhouse PRIVATE clickhouse-server-lib) in dbms/programs/CMakeLists.txt used to bring libdaemon/include public include:
https://github.com/yandex/ClickHouse/pull/4574/files#diff-fe6e64a8dc316ff0378ed2b61e651764L18
After this change that include directory is missing from the command line above.


pretrain model

First of all, thank you for sharing your great project.
I'm trying to train your model, but I'm having trouble constructing the dataset.
What images should be included in "dataroot_LQ" and "dataroot_GT"?
for example :
dataroot_LQ => /LDR/image_Gamma/0000/0.200000_img.png
dataroot_GT => /HDR/image_Gamma/0000/0.200000_img.png
(HDR image is created after running "gamma_tonemapping.py"  and "mulaw.tonemapping.py".)
is it right?
Additionally, could you provide a pre-trained model?
Thank You!

the same question. The dataset structure was changed. Could you kindly provide the dataset structure and how to match it to the train and test yml? Thanks.

pls try again for this new version.


Create a short program with Xlib

Create a minimal program to open and close window.

I created a working base for Xlib.


Link to the CoC in the README

Instead of generating and storing the CODE_OF_CONDUCT.txt file in every git repository, why not simply link to it in the README?

Not quite sure what you mean. Could you elaborate?

@rgb-one probably remove https://github.com/bundler/bundler/blob/master/CODE_OF_CONDUCT.md file and link to original CoC in the README.md file.

I don't think this is something we want to do.

@rgb-one @simi yep, add a hyper-link in the README to the Code of Conduct document, instead of generating it for every new gem. All Codes of Conduct eventually change, so this would eliminate the problem of having everyone update to the latest version.

@simi that's the Bundler code of conduct, not the code of conduct that's included with new gems if you opt in. We're not going to remove that one, and there is no "original". It's specifically written for this project.
@postmodern no, we're not going to remove the file. If you opt in during gem generation, that's the CoC you're establishing for your project. Pointing only to a URL means that it can disappear or change without notice, which is the exact opposite of what you want for a CoC.


add author details

Add .autorc file
Add author field to package.json

📦 Published PR as canary version: 0.18.13-canary.128.4410929.0

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

:rocket: PR was released in v0.19.0 :rocket:


[Feature] Sequence reuse

This issue is about a new feature proposed from below.

#7

Below is a quote from the PR.

Future Idea
One idea to consider for the future is making the key sequence that was pressed available somehow. Maybe something simple like this:
#[derive(Resource)]
struct LastKeySequence(Option<Vec<KeyChord>>)

But maybe that's too simple. What'd be best is if we could optionally pass the key sequence to the system we're invoking. But I don't really know how to do that.

I suggested this feature, but I ended up implementing this in bevy_minibuffer without needing any special handling by bevy-input-sequence. What I did was when I registered my key sequence on the action, I simply registered the set key sequence to a resource.
So I'm all for keeping this crate simpler when possible. I'd be happy to close this issue.


'MemoryFormFactor' mention in 'Generic' section

Hi,
First of all, thanks a lot for the wonderful tool!
Found small issue. When checking configuration for CoffeeLake and OC 0.6.2, got a remark on Generic section
MemoryFormFactor is missing. Normally set to Auto

Going through OC configuration/documentation, the only mention I can found is in SMBIOS section
MemoryFormFactor
Type: plist integer, 8-bit
Failsafe: OEM specified
SMBIOS: Memory Device (Type 17) — Form Factor
Description: Memory form factor. On Macs it should be DIMM or SODIMM.

https://github.com/acidanthera/OpenCorePkg/blob/0.6.2/Docs/Configuration.tex#L4931-L4937
This change is introduced in https://github.com/rlerdorf/OCSanity/pull/16 by @khronokernel
Looking through https://dortania.github.io/ - wasn't able to find the reference as well.
This seems to be a typo or copy-pasta of some kind. If this is the correct assumption, can prepare a PR to fix this.
Thanks in advance!

Ah it's a typo, supposed to be SystemMemoryStatus. Can fix that in a sec

@khronokernel Thanks much again for the speed of light reaction and fix!

merged


fix language selector error in Android (termux) user

This is fixed error for language selection on Android (termux) users

I thought UTF-8 and utf-8 make no difference, the library will normalize the case internally. NO?

I thought UTF-8 and utf-8 make no difference, the library will normalize the case internally. NO?
P.S. Are you really using this config on Android? There are several dependencies that I am not sure can work in termux.

No it isn't.
I have already tested it in termux Android. it works normally (although there are some unreadable libs maybe but no error message on configuration) except that language string. it should be "UTF-8" read from terminal 'local' environment vars.

I am not sure if you can install all dependencies of this config on termux, and I do not use termux personally. If this is only about language setting, maybe I can change it to UTF-8, on macOS, the case makes no difference.

oh yeah.. if you talking about the all of dependencies, i don't know that if it can run or not. because the major of dependencies is totally works for me. i can help with termux configuration.

I am not inclined to include support for android as I do not use it. But I can change the language settings if UTF-8 also works on Windows. Does that work for you?

No need, I used arch btw, totally works.


API to query hardware capabilities

Eg. if the HMD requires shader for output.

This is kind of done with the device classes (#93 ) right?

Device Classes provide this framework.


Show submodule recipes in --choose

From this comment
@foresterre reports that submodule recipes aren't appearing in --choose
I wasn't actually able to reproduce this. Doing this:
$ cat test.just
mod foo
$ cat foo.just
bar:
$ cargo run -- --unstable --justfile test.just --choose

Showed foo::bar in my chooser.

Reproduced this on both windows and ubuntu using: https://github.com/foresterre/sic/blob/960375b1fd37960e8cc8d4a22b1fa1ecbde32a25/justfile#L17
In this repo (branch 'avif-decoder', see commit hash above), I call just from the root of the repo with just --unstable. The result looks like this on ubuntu:

and on windows: https://github.com/casey/just/issues/929#issuecomment-2136874285 (see earlier) comment
Top level justfile from sic project above for reference

sic top level justfile
# NB: mod requires Just >= 1.19 and just --unstable
mod clippy  '.justfiles/clippy.just'
mod deny    '.justfiles/deny.just'
mod fmt     '.justfiles/fmt.just'
mod msrv    '.justfiles/msrv.just'
mod test    '.justfiles/test.just'
mod dav1d   '.justfiles/dav1d.just'

[windows]
default:
    @echo 'On Windows, run just using:'
    @echo 'just --unstable --shell pwsh.exe --shell-arg -c'
    @just --choose --unstable

[unix]
default:
    @just --choose --unstable

before-push:
    # do fmt
    just --unstable fmt
    # run checks
    just --unstable fmt check
    just --unstable dav1d
    just --unstable clippy
    just --unstable test
    just --unstable msrv
    just --unstable deny

Installed latest release on ubuntu with cargo install just, this solves the issue indeed. My apologies:

However, it does appear that the chooser has a different issue, namely, showing the recipe content:

For completeness sake, and since I was installing just from source anyways and this was hardl any extra effort, I also tested this last one also with the latest git 77a6e02, where this last issue is still present:

i.e. cargo install just --git https://github.com/casey/just.git --rev 77a6e02964f2f7607bd5f6163de5df5a1c13661d

Nice, glad it works! I just merged #2111, which makes --show take a recipe path, so recipe preview when choosing should work now.

Fixed, hopefully this time for good, in #2141.


Translation Miss in src/qt/locale/bitcoin_ko_KR.ts

src/qt/locale/bitcoin_ko_KR.ts
Change All of '비트코인' to '페더코인' Please (Ctrl + H in notepad)
There's so many translation miss.
Let's talk each other. Dev and Community. This Chemistry is really need in CryptoWorld. :)
Is there no T-shirt that marked Feathercoin logo?

src/qt/locale/bitcoin_ko_KR.ts ..?
Could you please change bitcoin_ko_KR.ts to feathercoin_ko_KR.ts?
Now I'm Fan of Feathercoin so I hope to participate this.

No need to rename the file to feathercoin, there are lots of file names with bitcoin in but none make a difference when the compiled binary is presented to the user. Changing file names generates more work.
If you go to the file src/qt/locale/bitcoin_ko_KR.ts in GitHub and edit it then when done it should create a pull request that I can confirm and merge. I'd feel somewhat safer if you performed the edit and I only need to then merge it.
There's no Feathercoin merchandise though it is always possible to get bespoke T-shirts made. Maybe this is something that we should look into.

Thanks. I created it.

Thanks for taking the time to update it. I hate to be a pain but the soon to be released version of Feathercoin is on the 0.16 branch and will be the one going into release. If you look at the release tab you can see which versions are marked as stable and can assume that the highest version number is the one currently or soon to be release. master branch does not have translations due to the number of conflicts when we pull locale updates from Bitcoin and the fact that we do not expect it to be used in production.
Could you kindly apply the same to the 0.16 version linked below?
https://github.com/FeatherCoin/Feathercoin/blob/0.16/src/qt/locale/bitcoin_ko_KR.ts
For compatibility with the Feathercoin URIs they need to be left like this feathercoin:


allocator-test/fuzz: stochastic necromancy test

Hold on to a random collection of freed pointers (stored before we free them) and, after each round, scan the collection looking for asserted tags.  This could happen if an object is prematurely released from quarantine before the revoker gets to the copy here in the collection.

While in the neighborhood, add a basic preflight test to hopefully catch things like the load barrier or revoker not working or being misconfigured (inspired by the report in https://github.com/CHERIoT-Platform/cheriot-rtos/pull/375, even if it isn't the actual problem over there, in the end).


Added password hasher settings. Fixed #2354.

Ok, tested successfully. Works now with django 1.10.1.
@normanjaeckel You can merge it.


Feedback on Tutorial: SAP HCP predictive services, Access your predictive demo data set using an OData services from a REST client

The service is Unavailable when i try to access the URL
https://trial<HCP_ID>trial.hanatrial.ondemand.com/public/timeseries/odata/timeseries.xsodata

Hi "vipalma",
Your url should include you HCP account identifier.
If you do use the "Run" button you should be ok, as this will generate the url with your hcp account identifier.
Let me know if this fix your issue.
Thanks
@bdel

Hi "vipalma",
Have you been able to solve the URL issue ased on my previous feedback?
I will consider this issue as solved, but if not feel free to reopen it.
Thanks
@bdel


Move Events Before Telemetry

Events should be moved before, and discussed before covering Telemetry.  The rationale:

Telemetry requires special "packet definitions", which is just one more distraction before seeing F´ run
Events show a uniqueness to F´ whereas telemetry is fairly standard.

Steps:

Move telemetry to "Events" portion of components part II
Move events to "Tlemetry" portion of comps part I
Move "add telem packet defintions" as note under telemetry section of comps II

Addressed in here https://github.com/fprime-community/fprime-workshop-led-blinker/pull/13


how to play the game? can't figure it out

Hi! Is there a particular part that you're struggling to understand, or that isn't working for you?
Perhaps seeing this play-through would make things clearer: https://www.youtube.com/watch?v=Dhlqip9DtGA
Alternatively, the How to play or Tips & Tricks sections of the README might help?

thanks! the walkthrough helped, what i didn't know was the goal of the game


Have to add another footer

As we have a navbar in two sections, just like that we have to add another footer section.

This footer is already added. You have to add another footer before that, which will contain About Dev Kitchen, Photo Gallery, Business Hours.

@harshita0802goswami would you like to work on that?

@sifa123 above the footer section you want to add this pencil drawn layout in which page

I think in all the pages

@sifa123 as a suggestion footer should contain only About Dev-kitchen, Opening Hours, Location(Address), and Site Map (hyperlinks to the other pages) i think it dosen't contain gallery in footer . If you want to add small gallery section add above the footer like this :

it will look much better .
I apologies if you mind my suggestion .

by the way I want to work on this issue so if possible then assign me.

under the DCP'21

@heet-kumar, yes, it should be on all pages.

I appreciate your suggestion. As you can see in the navbar, we have already a gallery page, so we will not add a gallery section to the home page. But as I have drawn on paper, this photo gallery will be small in size like this

You can also use our DevIncept photo as a background and on DevIncept photo add a like button which will take the user to Facebook page, add a follow button for linkedin and show total followers on LinkedIn.

@sifa123  buttons are required they are already created na google, linkedin , Insta, etc all are already created na

Yeah, it will look bad, then could you design this as I have said at first (About Dev Kitchen, photo gallery and opening closing hours)?

ya sure

for gallery photo can i use any photos or else you will provide it .

Anything you want but base one restaurant :smiley:

Can I try this issue @sifa123 ?

@aditya687 i am working on this issue so find it other issue

No problem, keep going on.
On Mon, 2 Aug, 2021, 7:52 PM Heet kumar Kothadiya, @.***>
wrote:

@aditya687 https://github.com/aditya687 i am working on this issue so
find it other issue
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/sifa123/Dev-Kitchen/issues/33#issuecomment-891069279,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ANVEZPOZPJLUTRXXBM5VIF3T22SYTANCNFSM5AHABYYQ
.


fix patch endpoint of dataset

To test, click the edit button on any dataset and post new name/description

All tests passed for me locally, merging


FormatString(): Examples

The NAV documentation of the Format function has way better detail about the effects of the different Parameters. This is extended by the Link to the Format-Property Where this particular Parameter is documented in even greater detail. I'd recommend copying this content from the NAV-Docs linked below: (You already replicated the Format-Property)
https://docs.microsoft.com/en-us/dynamics-nav/format-function--code--text-

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

ID: c745c7fa-6517-541f-d18a-36226db7fb64
Version Independent ID: f41b2a8c-8545-a5a2-4550-092786b1fde9
Content: Format Method - Business Central
Content Source: dev-itpro/developer/methods-auto/system/system-format-joker-integer-string-method.md
Service: dynamics365-business-central
GitHub Login: @solsen
Microsoft Alias: solsen

Thanks for your feedback. This was due to an auto-generated doc process for the methods, but I have ported the content over and the topic will be refreshed with our next push. Thanks again!


Directory artifact paths

Closes #1570
Previously, only glob patterns were allowed in artifact_paths. The name was confusing and also made certain patterns impossible.  In particular, in a common bash script, it is impossible to unambiguously "unglob" a string. For instance, in a shell script with $BUILDKITE_ARTIFACT_PATHS=foo/**/* and $PWD in an empty directory, the following would create a directory named literally foo/**/* (assuming no globbing shell options were set):
mkdir $BUILDKITE_ARTIFACT_PATHS

Even if you were to try one of the globbing related shell options, there are none that would accomplish the desired effect.
Of course, the workaround would be to "just" mkdir foo in the shell script. However this breaks the decoupling between buildkite and the script as the buildkite configuration must "know" about the shell script and vice versa.
This change also makes new things possible.
One example is the following in a shell script command step:
make prefix=$BUILDKITE_ARTIFACT_PATHS

Which is a common idiom in many build systems.

After some more looking at this, I think it is slightly more complicated than this (but not much).

Ok I think this is a start now. I see that maybe in the past filepath.Walk might have been restrictively slow but now filepath.WalkDir exists 😄 .

A brief test on our CI confirms this does what I want. Though the symlinks need some work and there could be cases of which I am unaware.

Ok tests pass and I think are actually correct.

Hi @sj26 thank you for your feedback!

BUILDKITE_ARTIFACT_PATHS is intended to be a list of globs for artifact upload, not used as an input to shell scripts for commands like mkdir.

Hm. Why is that? I would assume that almost any env var in a shell would be subject to some use by a command.

If you want a shared value for commands and for artifacts then perhaps you want to abstract that. I would suggest doing something like this instead, for example:

steps:

- env:

    - PREFIX=the/place/to/build

  artifact_paths:

    - ${PREFIX}/bin/*

  command: make PREFIX="${PREFIX}"

I can see this being useful, thank you!
I would like to push back on this decision a bit, though.
While I could probably define my own env var for the purpose, my bigger papercuts are listed in #1570.  To recap:
My problems are with the  correctness and violation of the principle of least surprise.

A directory is a valid glob pattern!
Because of that my expectations are violated when a directory I list in $BUILDKITE_ARTIFACT_PATHS is explicitly ignored for upload.
$BUILDKITE_ARTIFACT_PATHS is a misnomer. I get confused when I include a directory in the list (which is a path, as the name suggests) and it gets ignored.

I only list the use of $prefix as a potential upside of supporting directory listings.
In any case, we love Buildkite and use it heavily.  Thank you for your work!

The agent puts all the parameters required to run the job into the environment and then invokes a bootstrap process which consumes a lot of those variables to run hooks etc to run your command and all the surrounding behaviour. $BUILDKITE_ARTIFACT_PATHS is one such env, and is consumed by the buildkite-agent artifact upload command during arifact upload after the command hook.
You can upload the binaries produced by make with something like this:
steps:
- env:
    - PREFIX=the/place/to/build
  artifact_paths: ${PREFIX}/bin/*
  command: make PREFIX="${PREFIX}"

or you could be explicit and handle the upload yourself if you want more control:
steps:
- env:
    - PREFIX=the/place/to/build
  command: |
    make PREFIX="${PREFIX}"
    buildkite-agent artifact upload "${PREFIX}/bin/*"

I reckon we'll add a recursive mode for artifact upload at some point. Those commands need a bit of a rethink for better ergonomics. Maybe something like:
steps:
- env:
    - PREFIX=the/place/to/build
  command: |
    make PREFIX="${PREFIX}"
    # Doesn't work right now, but might at some point in the future
    buildkite-agent artifact upload -r "${PREFIX}/bin"

@sj26

The agent puts all the parameters required to run the job into the environment and then invokes a bootstrap process which consumes a lot of those variables to run hooks etc around your command to provide the surrounding behaviour. $BUILDKITE_ARTIFACT_PATHS is one such env, and is consumed by the buildkite-agent artifact upload command during arifact upload after the command hook.

Ok... can you expand a bit on how that relates to this conversation? Is that an additional maintenance burden? Sorry I'm having trouble seeing the relation.

You can upload the binaries produced by make with something like this:

steps:

- env:

    - PREFIX=the/place/to/build

  artifact_paths: ${PREFIX}/bin/*

  command: make PREFIX="${PREFIX}"

... but importantly not:

  artifact_paths: ${PREFIX}/bin

or you could be explicit and handle the upload yourself if you want more control:

steps:

- env:

    - PREFIX=the/place/to/build

  command: |

    make PREFIX="${PREFIX}"

    buildkite-agent artifact upload "${PREFIX}/bin/*"

But here the glob will expand  by the shell, first, no? You would need to use buildkite-agent artifact upload "${PREFIX}/bin/"'*' to give the agent sub command an in expanded glob.

I reckon we'll add a recursive mode for artifact upload at some point. Those commands need a bit of a rethink for better ergonomics.

That's what this pr does, no?

Perhaps I've been a little too polite here. Not allowing directories in the artifact_paths list is a major usability and correctness bug. Let's use your example to motivate why. Suppose our default make target begins with a single binary output. We start with your pipeline definition:
steps:
- env:
    - PREFIX=the/place/to/build
  artifact_paths:
    - ${PREFIX}/bin/*
  command: make PREFIX="${PREFIX}"

Then one day we decide to add a lib output. Now we would have to go change the pipeline to make sure the lib directory is uploaded:
  steps:
  - env:
      - PREFIX=the/place/to/build
    artifact_paths:
      - ${PREFIX}/bin/*
+     - ${PREFIX}/lib/*
    command: make PREFIX="${PREFIX}"


DTD is not loaded by config.cson

I have the following entry in the config.cson:
{
  priority: 2
  test:
    publicId: "-//OASIS//DTD DITA Topic//EN"
    outcome:
      schemaProps: [
        {
           path: "/home/stefan/workspace/DITA/dita-ot/plugins/org.oasis-open.dita.v1_3/dtd/technicalContent/dtd/topic.dtd"
           xmlCatalog: "/home/stefan/workspace/DITA/dita-ot/plugins/org.oasis-open.dita.v1_3/dtd/catalog.xml"
        }
      ]
}

I try to validate a standard DITA-XML Topic (DTD):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic PUBLIC "-//OASIS//DTD DITA Topic//EN" "topic.dtd">
<topic id="topic">
    <title></title>

</topic>

I get the validation message:
Validation failed: no DTD found ! (DTD)	3:18
Warning	Jing	Could not process schema or catalog: file not found: /home/stefan/Schreibtisch/topic.dtd (Datei oder Verzeichnis nicht gefunden)

The validator tries to load the DTD from the same directory, where the DITA-XML file is saved, but it should use the DTD defined in config.cson. How can I fix this?

Hi Stefan, sorry for the late reply. I think the problem is in config.cson: the xmlCatalog property needs to be a child of outcome. When you move it there, the rules specified in the catalogue file should apply to any document with the PUBLIC ID -//OASIS//DTD DITA Topic//EN (unless other matching rules are stronger than this one). When the catalogue contains a rule like this:
<public
   publicId="-//OASIS//DTD DITA Topic//EN"
   uri="/home/stefan/workspace/DITA/dita-ot/plugins/org.oasis-open.dita.v1_3/dtd/technicalContent/dtd/topic.dtd"/>

you should already be set and get the correct DTD for validation. In this case, you can remove the schemaProps specified in config.cson.

(in case you want to set the schema path in config.cson, add lang: 'dtd' as a sibling property of path)

Closing -- please re-open when you've got further issues / questions


bug: qt3scan - optimize function doesn't handle all exceptions

While there is a try/catch around the optimization function, it only catches nidaq errors. We should change this to handle all errors (since the piezo stage controller may also throw an error).

In particular, it seems that if a scipy optimization fails with an error, the function does not return and all the buttons remain greyed out

Suggested changes
https://github.com/qt3uw/qt3-utils/blob/main/src/qt3utils/datagenerators/piezoscanner.py#L177-L190
change to:
        optimal_position = axis_vals[np.argmax(count_rates)]
        coeff = None
        params = [np.max(count_rates), optimal_position, 1.0, np.min(count_rates)]
        bounds = (len(params)*tuple((0,)), len(params)*tuple((np.inf,)))
        try:
            coeff, var_matrix = scipy.optimize.curve_fit(gauss, axis_vals, count_rates, p0=params, bounds=bounds)
            optimal_position = coeff[1]
            # ensure that the optimal position is within the scan range
            optimal_position = np.max([min_val, optimal_position])
            optimal_position = np.min([max_val, optimal_position])
        except (ValueError, RuntimeError, OptimizeWarning) as e:
            logger.warning(e) #this sends warning to logger
            raise(e)   # optionally, we could throw the error again after logging, and require that the caller handles the Exception
        finally:
            return count_rates, axis_vals, optimal_position, coeff

https://github.com/qt3uw/qt3-utils/blob/main/src/applications/piezoscan.py#L489-L507
change to
        try:
            data, axis_vals, opt_pos, coeff = self.counter_scanner.optimize_position(axis,
                                                                           central,
                                                                           range,
                                                                           step_size)

        except nidaqmx.errors.DaqError as e:
            logger.error(e)
            logger.error('NIDAQ Error. Check for other applications using resources. If not, you may need to restart the application.')

        except (ValueError, RuntimeError, OptimizeWarning) as e:
            logger.error(e)

        finally:
            self.optimized_position[axis] = opt_pos
            self.counter_scanner.stage_controller.go_to_position(**{axis:opt_pos})
            self.view.show_optimization_plot(f'Optimize {axis}',
                                             central,
                                             self.optimized_position[axis],
                                             axis_vals,
                                             data,
                                             coeff)
            self.view.sidepanel.update_go_to_position(**{axis:self.optimized_position[axis]})

            self.view.sidepanel.startButton['state'] = 'normal'
            self.view.sidepanel.stopButton['state'] = 'normal'
            self.view.sidepanel.go_to_z_button['state'] = 'normal'
            self.view.sidepanel.gotoButton['state'] = 'normal'
            self.view.sidepanel.saveScanButton['state'] = 'normal'
            self.view.sidepanel.popOutScanButton['state'] = 'normal'

            self.view.sidepanel.optimize_x_button['state'] = 'normal'
            self.view.sidepanel.optimize_y_button['state'] = 'normal'
            self.view.sidepanel.optimize_z_button['state'] = 'normal'

Also, could use from tkinter import messagebox to display error in window instead of on console. (Thanks to @cmordi for discovering that tool in tkinter..)
        except nidaqmx.errors.DaqError as e:
            error_msg = f"{e}\n NIDAQ Error. Check for other applications using resources. If not, you may need to restart the application."
            messagebox.showerror("Error", error_msg)

        except Exception as e:
            messagebox.showerror("Error", e)

With the solution above, the piezo actuator will be moved to a new optimal position even if the scipy optimize function throws. The new optimal position will be the position with the maximum count rates. This, of course, could be changed. If it is desired to remain in the original position when scipy fails, then perhaps
change
https://github.com/qt3uw/qt3-utils/blob/main/src/qt3utils/datagenerators/piezoscanner.py#L162-L190
to
    def optimize_position(self, axis, center_position, width = 2, step_size = 0.25, return_to_initial_on_failure = True):
        """  (docstring omitted for brevity)
        """
        min_val = center_position - width
        max_val = center_position + width
        if self.stage_controller:
            min_val = np.max([min_val, self.stage_controller.minimum_allowed_position])
            max_val = np.min([max_val, self.stage_controller.maximum_allowed_position])
        else:
            min_val = np.max([min_val, 0.0])
            max_val = np.min([max_val, 80.0])

        initial_position = self.stage_controller.get_current_position()
        initial_position = {'x': initial_position[0], 'y': initial_position[1], 'z': initial_position[2]}

        self.start()
        raw_counts = self.scan_axis(axis, min_val, max_val, step_size)
        self.stop()
        axis_vals = np.arange(min_val, max_val, step_size)
        count_rates = [self.sample_count_rate(count) for count in raw_counts]

        optimal_position = axis_vals[np.argmax(count_rates)]
        coeff = None
        params = [np.max(count_rates), optimal_position, 1.0, np.min(count_rates)]
        bounds = (len(params)*tuple((0,)), len(params)*tuple((np.inf,)))
        try:
            coeff, var_matrix = scipy.optimize.curve_fit(gauss, axis_vals, count_rates, p0=params, bounds=bounds)
            optimal_position = coeff[1]
            # ensure that the optimal position is within the scan range
            optimal_position = np.max([min_val, optimal_position])
            optimal_position = np.min([max_val, optimal_position])
        except (ValueError, RuntimeError, OptimizeWarning) as e:
            if return_to_initial_on_failure:
                optimal_position = initial_position[axis]
            logger.warning(e) #this sends warning to logger
            raise(e)   # optionally, we could throw the error again after logging, and require that the caller handles the Exception
        finally:
            return count_rates, axis_vals, optimal_position, coeff


Detect ELF security features

This is a PoC for detecting specific ELF security features from discovered binaries (mostly ported from the bash script logic found in checksec). Specifically:

stack canaries
NX
RelRO
PIE
SafeStack
CFI
Clang Fortify
selfrando (not finished...)

Dev notes
Until the test harness is really hooked up (see todo) you need to head to syft/file/cataloger/executable/test-fixtures and run make, then you should see the added tests pass:
=== RUN   Test_findELFSecurityFeatures
=== RUN   Test_findELFSecurityFeatures/detect_canary
=== RUN   Test_findELFSecurityFeatures/detect_nx
=== RUN   Test_findELFSecurityFeatures/detect_relro
=== RUN   Test_findELFSecurityFeatures/detect_partial_relro
=== RUN   Test_findELFSecurityFeatures/detect_pie
=== RUN   Test_findELFSecurityFeatures/detect_dso
=== RUN   Test_findELFSecurityFeatures/detect_safestack
=== RUN   Test_findELFSecurityFeatures/detect_cfi
=== RUN   Test_findELFSecurityFeatures/detect_fortify
--- PASS: Test_findELFSecurityFeatures (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_canary (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_nx (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_relro (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_partial_relro (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_pie (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_dso (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_safestack (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_cfi (0.00s)
    --- PASS: Test_findELFSecurityFeatures/detect_fortify (0.00s)
PASS

Process finished with the exit code 0

TODO

[x] determine how file.Executable metadata is ultimately show on the file object in syft-json (including ensuring the models are appropriately incorporated into the JSON schema generation code, which seems like it might be a snowflake depending on the final path)
[x] hook into cataloger infrastructure and application configuration
[x] hook test-fixture makefile into either golang pre-test runner or in top-level fixtures task target
[ ] question: is the current approach to glob inclusion / mirroring file selection correct?
[ ] add macho security features (split into separate issue?)
[ ] add pe security features (split into separate issue?)
[ ] fix/re-incorporate selfrando fixture and write detection mechanism in

Closes #2434

JSON schema diff for reviewers:
# diff schema/json/schema-13.0.0.json schema/json/schema-13.0.1.json
3c3
<   "$id": "anchore.io/schema/syft/json/13.0.0/document",
---
>   "$id": "anchore.io/schema/syft/json/13.0.1/document",
553a554,592
>       ]
>     },
>     "ELFSecurityFeatures": {
>       "properties": {
>         "symbolTableStripped": {
>           "type": "boolean"
>         },
>         "stackCanary": {
>           "type": "boolean"
>         },
>         "nx": {
>           "type": "boolean"
>         },
>         "relRO": {
>           "type": "string"
>         },
>         "pie": {
>           "type": "boolean"
>         },
>         "dso": {
>           "type": "boolean"
>         },
>         "safeStack": {
>           "type": "boolean"
>         },
>         "cfi": {
>           "type": "boolean"
>         },
>         "fortify": {
>           "type": "boolean"
>         }
>       },
>       "type": "object",
>       "required": [
>         "symbolTableStripped",
>         "nx",
>         "relRO",
>         "pie",
>         "dso"
599a639,652
>       ]
>     },
>     "Executable": {
>       "properties": {
>         "format": {
>           "type": "string"
>         },
>         "elfSecurityFeatures": {
>           "$ref": "#/$defs/ELFSecurityFeatures"
>         }
>       },
>       "type": "object",
>       "required": [
>         "format"
626a680,682
>         },
>         "executable": {
>           "$ref": "#/$defs/Executable"


safeguard from adoption of a resource by kapp

This morning kapp created major havoc on the cluster when I was trying it out
Deployment command:
helmfile -e sandbox template | kapp -y deploy -a postgres -f -

helmfile is a wrapper on top of help, and the helmfile -e sandbox template generates definitions for four objects, all objects listed below except the first one. I am not sure why kapp thinks it needs to update the postgres/PostgresVersion resource.
Namespace  Name                 Kind             Conds.  Age  Op      Wait to    Rs  Ri
(cluster)  postgres             PostgresVersion  -       5m   update  reconcile  ok  -
pg2        postgres             Postgres         -       -    create  reconcile  -   -
^          postgres-gcs-secret  Secret           -       -    create  reconcile  -   -
^          postgres-init        ConfigMap        -       -    create  reconcile  -   -
^          postgres-secret      Secret           -       -    create  reconcile  -   -

Op:      4 create, 0 delete, 1 update, 0 noop
Wait to: 5 reconcile, 0 delete, 0 noop

I then ran
kapp delete -a postgres

and as you can see kapp decided to delete the postgres/PostgresVersion resource it didn't create
Namespace  Name                 Kind             Conds.  Age  Op      Wait to  Rs  Ri
(cluster)  postgres             PostgresVersion  -       13m  delete  delete   ok  -
pg2        postgres             AppBinding       -       7m   -       delete   ok  -
^          postgres             Endpoints        -       7m   -       delete   ok  -
^          postgres             Postgres         -       7m   delete  delete   ok  -
^          postgres             Role             -       7m   -       delete   ok  -
^          postgres             RoleBinding      -       7m   -       delete   ok  -
^          postgres             Service          -       7m   -       delete   ok  -
^          postgres             ServiceAccount   -       7m   -       delete   ok  -
^          postgres             StatefulSet      -       7m   -       delete   ok  -
^          postgres-gcs-secret  Secret           -       7m   delete  delete   ok  -
^          postgres-init        ConfigMap        -       7m   delete  delete   ok  -
^          postgres-replicas    Endpoints        -       7m   -       delete   ok  -
^          postgres-replicas    Service          -       7m   -       delete   ok  -
^          postgres-secret      Secret           -       7m   delete  delete   ok  -
^          postgres-snapshot    Role             -       7m   -       delete   ok  -
^          postgres-snapshot    RoleBinding      -       7m   -       delete   ok  -
^          postgres-snapshot    ServiceAccount   -       7m   -       delete   ok  -

Op:      0 create, 5 delete, 0 update, 12 noop
Wait to: 0 reconcile, 17 delete, 0 noop

I didn't spot it right away, my fault, but needless to say, I don't think kapp should be deleting the (cluster-wide) resource it didn't create.
Note: the postgres resources in the chart are managed by [kubedb operator](for https://kubedb.com/docs/0.12.0/welcome/)
I had to re-install the kubedb operator to fix the cluster operations.
I was really excited about kapp, but the above is a major issue, which obviously prevents us from using the tool. I am just curious as to why kapp behaves this way.
This very well might be an issue with kubedb, but a lack of safeguard in kapp for deleting something it didn't create still worries me.

This morning kapp created major havoc on the cluster when I was trying it out

that's unfortunate. let's see what happened...

helmfile -e sandbox template | kapp -y deploy -a postgres -f -
generates definitions for four objects, all objects listed below except the first one.

based on your first snippet kapp was updating (cluster)  postgres  PostgresVersion resource. given this information kapp did receive that resource from the helmfile -e sandbox template output. can we snippet what is helmfile returning?
one way to have more control of kapp (especially during experimentation) when piping output is to use process substitution, this way kapp will prompt you whether you want to apply changes:
kapp deploy -a postgres -f <(helmfile -e sandbox template)

you can also throw in -c (or longer --diff-changes) to see full diff.

I don't think kapp should be deleting the (cluster-wide) resource it didn't create.

because kapp received that resource in its configuration, it began to own that resource (because it made updates to it). since it was "owned" by kapp, when you asked to delete that application it deleted all resources that were owned by it, including that one.

but a lack of safeguard in kapp for deleting something it didn't create still worries me.

one safeguard that we did built into kapp is to present action summary before executing it. in this case that did not quite help you. i could see adding additional safeguards but im still not clear why helmfile output included resource you did not expect. should that have been highlighted in a more prominent manner, but even then since you were running it with -y you wouldnt have opportunity to do anything about that.
to me the "problem" happened earlier -- at the time of the initial deploy, when resource was updated -- e.g. what should we do with resources that we need to update and are already found in cluster? kapp, today, assumes that it will take ownership of them, which is typically desired.

given this information kapp did receive that resource from the helmfile -e sandbox template output. . can we snippet what is helmfile returning?

Yes, you are right, I rushed through the original analysis, my apologies. Thank you for being super patient and helpful. Below is the scrubbed version of the helmfile -e sandbox template output:
---
# Source: postgres/templates/db_secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: postgres-secret
  labels:
    app.kubernetes.io/name: postgres
    helm.sh/chart: postgres-0.6.0
    app.kubernetes.io/instance: postgres
    app.kubernetes.io/managed-by: Helm
type: Opaque
data:
  POSTGRES_PASSWORD: "<scrubbed>"
---
# Source: postgres/templates/gcs_secrets.yaml
apiVersion: v1
kind: Secret
metadata:
  name: postgres-gcs-secret
  labels:
    app.kubernetes.io/name: postgres
    helm.sh/chart: postgres-0.6.0
    app.kubernetes.io/instance: postgres
    app.kubernetes.io/managed-by: Helm
type: Opaque
data:
  GOOGLE_PROJECT_ID: "<scrubbed>"
  GOOGLE_SERVICE_ACCOUNT_JSON_KEY: "<scrubbed>"
---
# Source: postgres/templates/configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgres-init
  labels:
    app.kubernetes.io/name: postgres
    helm.sh/chart: postgres-0.6.0
    app.kubernetes.io/instance: postgres
    app.kubernetes.io/managed-by: Helm
binaryData:
  init.sql: "<scrubbed>"
---
# Source: postgres/templates/postgres.yaml
apiVersion: kubedb.com/v1alpha1
kind: Postgres
metadata:
  name: postgres
  labels:
    app.kubernetes.io/name: postgres
    helm.sh/chart: postgres-0.6.0
    app.kubernetes.io/instance: postgres
    app.kubernetes.io/managed-by: Helm
spec:
  replicas: 1
  version: postgres
  databaseSecret:
    secretName: postgres-secret
  storageType: Durable
  storage:
    storageClassName: "standard"
    standbyMode: Warm
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 10Gi
  terminationPolicy: WipeOut
  archiver:
    storage:
      storageSecretName: postgres-gcs-secret
      gcs:
        bucket: <scrubbed>
        prefix: pg2
  init:
    scriptSource:
      configMap:
        name: postgres-init
---
# Source: postgres/templates/postgres_version.yaml
apiVersion: catalog.kubedb.com/v1alpha1
kind: PostgresVersion
metadata:
  name: postgres
  labels:
    app.kubernetes.io/name: postgres
    helm.sh/chart: postgres-0.6.0
    app.kubernetes.io/instance: postgres
    app.kubernetes.io/managed-by: Helm
  annotations:
    "helm.sh/hook": pre-install
    "helm.sh/hook-delete-policy": "before-hook-creation"
spec:
  version: 9.6-v3
  podSecurityPolicies:
    databasePolicyName: "postgres-db"
    snapshotterPolicyName: "postgres-snapshot"
  db:
    image: "<scrubbed>"
  exporter:
    image: "kubedb/postgres_exporter:v0.4.6"
  tools:
    image: "kubedb/postgres-tools:9.6-v3"

The interesting part is that the PostgresVersion object has Helm hook annotations, which explains why Helm doesn't delete it. Does kapp by any chance has a mechanism that emulates Helm behavior (as bad as it can be)? Is there an annotation that would make kapp delete skip resource deletion?

Thank you for being super patient and helpful.

here to help :)

Does kapp by any chance has a mechanism that emulates Helm behavior (as bad as it can be)? Is there an annotation that would make kapp delete skip resource deletion?

there is a kapp.k14s.io/delete-strategy annotation with "orphan" value (https://github.com/k14s/kapp/blob/master/docs/apply.md#controlling-apply-via-resource-annotations); however, next time you deploy with kapp and that resource is defined, kapp will complain that resource was already "owned" by a different (deleted) app. arguably we should add another strategy value like  "orphan-and-disassociate". (there is a way to get around that but i discourage its use: https://github.com/k14s/kapp/blob/master/docs/dangerous-flags.md#--dangerous-override-ownership-of-existing-resources)
it seems that this resource is more of a "global resource" (that defines available postgres versions) than a resource that is related to this particular postgres app. could you separate it out into a different kapp deploy? you could do it via builtin filtering or via tools like get-ytt.io.
# deploy shared stuff
kapp deploy -a shared-pg -f <(...) --filter-kind PostgresVersion
# deploy an instance of postgres
kapp deploy -a pg1 -f <(...) --filter '{"not":{"resource":{"kinds":["PostgresVersion"]}}}'

Thank you for the additional info.

it seems that this resource is more of a "global resource" (that defines available postgres versions) than a resource that is related to this particular postgres app

Yes, you are right. The original helm chart is doing something very questionable.  A chart that is deployed into a namespace should not be overriding a global (cluster-wide) object. I picked that particular chart to experiment with kapp because we are having an issue deleting the Kubernetes objects deployed by the chart: the objects get deleted in the wrong order, which causes the kubedb finalizer to get stuck. I thought that chart would be a good one to try out kapp ordering capabilities. I wasn't the original developer for the chart, and I missed the chart's questionable behavior of updating the global object. Thank you for the proposed workaround though.

A chart that is deployed into a namespace should not be overriding a global (cluster-wide) object

well. that depends. i dont personally see anything wrong with cluster level objects being in an "app"; however, kapp follows a philosophy that only one app owns a particular objects. that leads to clearer ownership semantics without getting into reference counting style tracking.

I wasn't the original developer for the chart, and I missed the chart's questionable behavior of updating the global object. Thank you for the proposed workaround though.

understood. btw here is another alternative that i personally prefer: use get-ytt.io to apply an overlay that makes PostgresVersion cluster resource specific to a particular application. if you decide to deploy multiple of those things you can give PostgresVersion a different name.
kapp -y deploy -a postgres -f <(helmfile -e sandbox template | ytt --ignore-unknown-comments -f- -f fix-version.yml)

fix-version.yml
#@ load("@ytt:overlay", "overlay")

#@overlay/match by=overlay.subset({"kind":"PostgresVersion"})
---
metadata:
  name: app1-postgres-version

#@overlay/match by=overlay.subset({"kind":"Postgres"})
---
spec:
  version: app1-postgres-version

PostgresVersion belongs to another chart, a third-party kubedb-catalog chart. That is why I am saying that updating PostgresVersion from our custom chart is wrong: we are breaking the single-owner rule. The scopes (cluster vs namespace) and the volatilities (when the two charts get installed/updated/removed) do not match either, so our chart has not business updating PostgresVersion.
If we need to update the docker image referenced by the PostgresVersion manifest (this is the whole reason we are updating it), we should update the kubedb-catalog chart.
I am using Helm terminology but obviously the same can be done using two separate kapps apps.

That is why I am saying that updating PostgresVersion from our custom chart is wrong

ah, this makes sense to me now in how you it's setup. i didnt realize multiple charts were involved here.


Normative language improvements

Normative terms (MUST, SHOULD, MAY, etc.) are now all capitalised. Non-normative uses of those terms (which were mostly lower-case) have been replaced or rephrased.
Some other language improvements also included and a little reformatting.

Things that I think are outstanding:

Writing up an NMOS specifications style guide
Copying changes to common language in the early sections to other specs that repeat it
Rewriting the stuff about Query API Subscriptions/WebSocket connections
Maybe adding a note about first and last - https://github.com/AMWA-TV/nmos-discovery-registration/pull/158#discussion_r605825733
Thinking about a BCP for RQL - https://github.com/AMWA-TV/nmos-discovery-registration/pull/158#discussion_r605836088
Looking at the text around href specialisation - https://github.com/AMWA-TV/nmos-discovery-registration/pull/158#discussion_r606086882
Connection Upgrade for converting to WebSocket... in or out? - https://github.com/AMWA-TV/nmos-discovery-registration/pull/158#discussion_r606086882
Flows for other Nodes' Sources? - https://github.com/AMWA-TV/nmos-discovery-registration/pull/158#discussion_r606143745
Virtual Node id mapping - https://github.com/AMWA-TV/nmos-discovery-registration/pull/158#discussion_r606144352

https://github.com/AMWA-TV/nmos-template/issues/19 suggests a style guide


update golangci-lint

Update of golangci-lint and go version used in linters actions.

Should the PR fix linting errors before getting merged?

Should the PR fix linting errors before getting merged?

This PR is just for updating the version of golangci-lint, not for fixing the issues.

@cbartoszDell Linting issues were addressed in an earlier PR #185. This is a regression.

Should the PR fix linting errors before getting merged?

This PR is just for updating the version of golangci-lint, not for fixing the issues.

If we are not fixing linting error, what is the point of version upgrade?

This PR is only for upgrading the versions on Go and golangci-lint action. @alikdell This is required to make sure that golangci-lint is always the latest version and is working with the latest version of Go. This requests is being made to all CSM drivers and modules to make sure linter action keeps working. Fixing linter warnings is not a part of scope of this upgrade PR.

This PR is only for upgrading the versions on Go and golangci-lint action. @alikdell This is required to make sure that golangci-lint is always the latest version and is working with the latest version of Go. This requests is being made to all CSM drivers and modules to make sure linter action keeps working. Fixing linter warnings is not a part of scope of this upgrade PR.

The lintings errors were fixed. Now any PR goes that must fix any remaining linting error. Scope or not scope do not come up. You have linting error, fix it.

Yes I second Alik and others, the linting errors were fixed last week, we should not allow them to regress.


note that /tmp doesn't seem to map correctly as a volume when using docker for mac

this is an issue for file-drop that uses the default vent.cfg setting:
[main]
files = /tmp/vent_files


fix(_cleanStyle)

fix for when window.getComputedStyle(context.element.wysiwyg) does not contain style tag
I have a .docx file that contains an element with a style tag mso-element that does not exist in the getComputedStyle resulting in
this.wwComputedStyle[k] being undefined and calling replace on it breaks the editor content. My users were saving a react-hook-form and the editor contents were always empty.
I have attached the word document that breaks the editor. Try to Ctr + A and Ctrl + C, paste the contents in the editor and see the console.
v2.46.4

@JiHong88 it doesn't let me add a reviewer so I thought I could tag you here


Use the static endpoint for downloading crates to load crates.io less

Per advice on https://www.pietroalbini.org/blog/downloading-crates-io/

Great, thanks a million!
This seems to be a win-win as crates.io can save a re-direct and criner can cut out some latency.


per-checksum score submission locks to prevent score duplicates

Describe your changes
Related Issues / Projects
Checklist

[ ] I've manually tested my code

cc @minisbett


feat: use starknet-bootstrap in genesis loader

Feature Request
Describe the Feature Request

We need a better way to initialise the chain state that doesn't require hardcoding storage keys/values in the config unless for very specific needs but it shouldn't be the baseline.
Describe Preferred Solution

Recently release, we can leverage the starknet-boostrap repo, which is used to bootstrap the new Starknet Sepolia Testnet.
This could then be further extended to fit the needs of any app-chain.

@EvolveArt  can you assign to me please, I will manage that after my current task.

starknet-bootstrap is not maintained anymore (last commit 6 month ago)
Are you aware of another tool @EvolveArt ?


Which languages does the parser accept?

@epageperron:
We are working Old Persian texts and found out that Tinney's parser cannot handle the ASCII version of the transliteration, it would be great if our parser could handle more than Akkadian and Sumerian http://oracc.museum.upenn.edu/doc/help/languages/oldpersian/index.html (Old Persian)

For now the parser supports all forms of Mesopotamian cuneiform (including proto-Cuneiform and proto-Elamite), as well as references to sign lists, but probably not OP or Ugaritic. This should be easy to implement.
Are there CDLI ATF examples for the additional scripts?

http://oracc.iaas.upenn.edu/aemw/ugarit/P520793/html

We don't have any Ugaritic text in yet but that would be amazing :)