text:
Move towards a more standard JSON/REST API

I'd like to consider adopting a more formalized API format, and I'd like to consider something like JSON:API, but maybe leave out some of the complicated relationship stuff and keep it simple?
Today the project's API is running on decisions I made a long time ago, before I really knew much of REST or status codes or any of that. API calls return 200 even if there is an error, and the payload varies depending on what the object is (/api/queries I think returns a { queries: [] }  response, and /api/users returns { users: [] }, and I think it'd be nice if they just both returned { data: [] })
Main things I'd like to adopt:

Use status codes accordingly (200 ok, 500 for server error, 4xx for client errors, etc)
Use data field for payload, errors for an array of errors object
support top level id & type fields

@koszti @gonace any thoughts on this?

Now that I'm getting around to implementing this... I'm going to back off of trying to get the minimum JSON:API implementation in at this point.
Providing resource objects in the form of { id, type, attributes } would involve a lot of changes, particularly when SQLPad uses _id and has attributes top-level. Updating all that for all the POST, PUT, and GETs seems like a lot for little benefit at this point.
For v5 /api responses will return a standardized data object if success, errors array if not. HTTP status codes will be used, so 200 is ok, but 400 or 500 for errors (along with 401/403 for auth stuff).
Once this transition is done, and data is moved into SQLite and has a standard id property, I'd entertain supporting the { id, type, attributes } format if someone wants to implement it. Or maybe that's a longer term thing...

Alright I'm gradually becoming less set on using JSON:API. Some things in SQLPad don't follow convention, and it feels a bit off trying to force the API and data to work.
For example, the route /*/api/app is a one-off route used by the front-end to figure out what the baseUrl is for the application, as well as get other app-specific info (app version, logged in user, config).
This API doesn't fit JSON:API at all. Even if an arbitrary id was used, this top-level app route sits at a place where a plural noun would that returns a list.
I did more research on this and ended up several places:

https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api
https://docs.microsoft.com/en-us/azure/architecture/best-practices/api-design
https://dev.to/tiguchi/where-to-put-response-metadata---envelope-or-http-headers-4ai9
https://tools.ietf.org/html/rfc5988#page-6

I've never even heard about enveloping before, but as I look into it I'm even more convinced I don't want it.
After getting the partial JSON:API implemention functional, I realized I was never paying attention to the surrounding HTTP stuff. HTTP status codes were ignored, because I was checking the data or errors envelope.
Plus I'm adding code to ensure envelopes match a certain spec set by JSON:API, code that won't be necessary if the response is the data.
Also headers... I get the sense that a lot of front-end devs don't get into the nitty-gritty of HTTP functionality. I know I put off learning about headers for a long time (they seemed intimidating for some reason).
So all this to say... Instead of trying to force this app to use a specific arbitrary spec or inventing a new envelope, I'm going to follow guidance in this post (https://www.vinaysahni.com/best-practices-for-a-pragmatic-restful-api) along with some of the others and "use the platform"
HTTP status codes will be used appropriately. The body of the response will be the thing it is (either an item, an array or items, or an error object).

repo: rickbergfalk/sqlpad


text:
start php-fpm-7.1 fails on new PHP Elasticbeanstalk platform

The new ElasticBeanstalk PHP platform is using php7.2 by default now. When I use my old, working .ebextensions configs based off this repo, I get errors related to starting php-fpm-7.1. I am testing installing php72-fpm package and changing all the 7.1 refrences to 7.2 now. Will report back on progress

Were you able to find any fixes for this, at the moment I am experiencing a failed build every time I deploy due to ELB upgrading to php 7.2

source: gharchive/issue

authors: jasondewitt mezlad

repo: ricktbaker/beanstalk-nginx-php-fpm

license: MIT

license_type: permissive

license_source: github-api


text:
New feautures implementations

After some user requests to implement new features, I thought I'd open this issue to be able to do a review and decide whether or not to implement the requests made.

Dynamic cell width #9
Filter data #3
Select a row #2

@RichiB20

I am just start to use ur package, but I like it already ( cuz it has expand support ) About feature request, select a row totally useless cuz it can be implemented by out own, same as filters. So I will vote for Dynamic cell

I need somehow set same horizontal scroller for multiple indentical separate tables.

authors: oleksii-pimenov rickypid rmasarovic


text:
Failing build

@ampolloreno and @vtomole
Please fix the failing build.  Looks like it was induced by your PR

Just reran the build, and everything passed. Closing.

authors: ampolloreno ncrubin

repo: rigetticomputing/grove

license_source: bigquery


text:
Incorrect return type

https://github.com/rigetticomputing/pyquil/blob/e5ae01145c1f0eda38863c5f1af058133ad3a1e2/pyquil/paulis.py#L677
exponential_map does not return a Program, it returns a function.

The fix for this issue has been merged. We can close it now.

authors: jonathanward vtomole

repo: rigetticomputing/pyquil


text:
add a public get_tree() method and have print_tree use it

Note that I found this useful when debugging and I didn't have access to a
normal stdout.

I don't think exposing a string representation of the internal state is a good idead.
It would be better to just change the println! calls with debug! calls from the log crate. This way you could add a different log targets depending on your needs, without exposing internal state.

merged it into actors.rs

Hi @tupshin thanks for the input. I think you've identified a valid problem, however @hardliner66 has a valid point re not using a string representation. My concern would be larger actor systems that have several thousand or more actors and the allocation to append each actor name. Maybe there is a more effective way to solve the problem that you've identified?

source: gharchive/pull-request

authors: hardliner66 leenozara olexiyb tupshin

repo: riker-rs/riker


text:
Add support for rest pattern

As discussed in #101, I added support for it.

Rebased and fixed clippy. CI is finally happy. :)

And done. :)

repo: rinja-rs/rinja


text:
Nested State Replacement

Currently there is no nested state for the reducer functions/methods, like the createReducer function in Redux Framework. Updating a single subpath in action methods can be tedious and prone to errors especially in case of state structure refactors. Is there a plan for a nested state support?

@berserk81, agree. Working on a solution. I will make it available soon.

repo: rintoj/statex

license: mit


text:
Changed strand_.post to strand_.dispatch

asio already has a built-in function for this operation.
You can check source code: https://github.com/chriskohlhoff/asio/blob/master/asio/include/asio/detail/impl/strand_service.hpp#L58-L63
Referance: http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/io_service/dispatch.html

@tanisman, do you plan on updating this PR to address the feedback by David Schwartz? If not, should we consider closing this for now?

authors: nbougalis tanisman

repo: ripple/rippled

license: ISC


text:
Tests for CASSANDRA-10854

Two tests for CASSANDRA-10854, I did not use @require since the ticket is already in status ready to commit so you may want to wait until the ticket is committed before merging or I can merge myself once I have your +1 and the ticket is committed.

+1

repo: riptano/cassandra-dtest


text:
WEB3-179: feat: Steel history

Add new historical commitments that allow you to separate the EVM execution block from the commitment block. They work as follows
Call the Beacon Roots contract for t_0 - 24h (which is in the valid HISTORY_BUFFER_LENGTH) using the current state S_0 to prove that the previously loaded state S_1 is indeed the correct blockchain state from 24h ago, then call the Beacon Roots contract on S_1 for t - 48h to verify the state S_2 from 48h ago, and so on until we reach the desired state S_n in the past, which is then used to execute the actual contract call.
Assuming that the block hash or beacon root of S_0 is part of the canonical chain, this shows that S_n was indeed in its history.
Closes WEB3-179

No tests currently cover the new functionality in CI.

I've created issue #307 to add the history commitment to the CI E2E test.
In addition, we already have two unit tests history::tests::from_beacon_commit_and_header and host::builder::tests::build_history_env that test this feature. However, since they test against the live Ethereum testnet, they are ignored by default. (We might consider enabling them under certain conditions.)

We should have some documentation about this feature and make sure it's easy to find. Probably just start with an update to the README and/or steel/docs, as well as a comment in the CHANGELOG of course.

CHANGELOG changes have been added to this PR, the missing documentation is documented in #308.

Should we mark the history functionality with unstable?

I am not sure how this would actually work... The only out-facing API change is adding .commitment_block() to the builder everything else including the history module is just adding a new variant to an enum which should be transparent to the user.


text:
Guest builds fail due to cc crate 1.0.80

After the release of cc crate 1.0.80 the zkvm guest build fails with the following errors:
method_name: error[E0152]: duplicate lang item in crate `core` (which `rustc_std_workspace_core` depends on): `sized`.
method_name:   |
method_name:   = note: the lang item is first defined in crate `core` (which `std` depends on)
method_name:   = note: first definition in `core` loaded from /home/user/.rustup/toolchains/nightly-2023-03-06-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-05898138a596088a.rlib
method_name:   = note: second definition in `core` loaded from /home/user/tmp/cc-bug/target/riscv-guest/release/deps/libcore-d6bc9e683b556e25.rmeta
<snip>

Workaround:
Place the following config:
[patch.crates-io]
cc = { git = "https://github.com/rust-lang/cc-rs", rev = "e5bbdfa" }

into either:

Your current rust workspace root .cargo/config.toml
Or system wide at ~/.cargo/config.toml

Origin
Appears to be related to the following commit https://github.com/rust-lang/cc-rs/commit/17c8858efbeec6094c21973e3d2e9773916b6aa2 and respective PR in cc-rs: https://github.com/rust-lang/cc-rs/pull/780
cc is not in the default guest cargo depenendency tree but is in the build-std build tree so its most likely a mix up within our std building.

same. thanks for the workaround -- it worked.

Super appreciated!

@Amosel Can you also apply this hot fix to risc0 main repo? Thanks.

This has been applied in https://github.com/risc0/risc0/pull/757

authors: 0xfuturistic Amosel flaub jiayaoqijia mothran


text:
definition of machine time compare register event

In V1.12-draft, the logic for the timer event is "mtime < mtimecmp" using an unsigned comparison.  The specification does not say what happens when mtime overflows.
The alternative definition "0 <= (mtime - mtimecmp)" using signed comparison would allow for the timer to overflow, thus allowing the system to run indefinitely.  The cost is that the maximum timeout period can only be half of the precision of the timer register (so 2^63 ticks) and that a true subtraction circuit rather than digital comparator is needed.
The procedure for changing mtimecmp on a 32-bit machine remains the same: first change the lower word to the largest possible value, then change the higher word to the proper value, then change the lower word to the proper value.  This results in a window where a spurious event could be triggered, but this is no different from the original situation.

Change ad315fe raises the question what the mtimecmp register should do when mtime overflows.  Should it reset or stay set?
The advantage of the proposed definition for the timer event in #480 above is that it continues to work in the face of mtime overflows.
If you don't want to use the definition given in #480, I think it would be better to note that with a tick period of 1 ns, the 64-bit mtime will overflow after 584 years and hence the standard does not mandate a behavior.

It’s a level, not an edge—the interrupt is pending whenever mtime >=
mtimecmp, so in most overflow scenarios, the interrupt goes low on
overflow, unless mtimecmp=0.
On Thu, Mar 5, 2020 at 8:18 AM Konrad Schwarz notifications@github.com
wrote:

Change ad315fe
https://github.com/riscv/riscv-isa-manual/commit/ad315fe5812046abbf77f34580b5351bed54a3a4
raises the question what the mtimecmp register should do when mtime
overflows. Should it reset or stay set?
The advantage of the proposed definition for the timer event in #480
https://github.com/riscv/riscv-isa-manual/issues/480 above is that it
continues to work in the face of mtime overflows.
If you don't want to use the definition given in #480
https://github.com/riscv/riscv-isa-manual/issues/480, I think it would
be better to note that with a tick period of 1 ns, the 64-bit mtime will
overflow after 584 years and hence the standard does not mandate a behavior.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/riscv/riscv-isa-manual/issues/480?email_source=notifications&email_token=AAH3XQQKER4KKYR6RDSTAPDRF7GGDA5CNFSM4KNEP5FKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN54UCQ#issuecomment-595315210,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAH3XQTLTKIZGDDDXEXN2JDRF7GGDANCNFSM4KNEP5FA
.

So on overflow, the interrupt is (silently) retracted -- obviously an undesirable outcome.
Note that the unprivileged spec says, in 10.1:

The underlying 64-bit counter should
never overflow in practice.
Why not have the privileged spec use the same approach?

IMO,
The spec just says:
(unsigned)N > (unsigned)O means N is a newer timestamp, and O is an elder timestamp.
N/O is unsigned value, > is (greater than).
It says nothing about delta.
It depends on the implementation to comprehend.
Say:
(unsigned)N > (unsigned)O
can be converted into:
(unsigned)N - (unsigned)O > 0
The spec doesn't say something about delta value:
(unsigned)((unsigned)N - (unsigned)O) > 0
Have we seen a definition forcing that the delta must be unsigned?
So why bother?
The implementation apparently can consider a wrap-over safe implementation w/o violating the spec.

authors: aswaterman konrad-schwarz zetalog

repo: riscv/riscv-isa-manual


text:
AMOs and indexed loads/stores use XLEN-bit indices, no matter SEW

Resolves #381

Andrew, I think this introduces new vector register overlap constraints that need to be documented as part of the change.

@JamesKenneyImperas yes indeed, fixed (I think).

Andrew, another issue that requires clarification: what happens for implementations where XLEN>ELEN? We have had several enquiries about implementations where XLEN=64 and ELEN=32, for example.
One solution could be:

Define new ILEN (index length) as ILEN=min(XLEN,ELEN);
Recast your definition to use ILEN instead of XLEN throughout;
Specify that if ILEN<XLEN, the intermediate index is sign-extended to XLEN.

There are various other possibilities which seem worse to me:

Require ELEN>=XLEN in all implementations;
Make these Illegal Instructions if XLEN>ELEN;
Use the preferred solution above, but fix ILEN to the always-supported value 32;
Specify that an element size of XLEN must be supported in this special case even if XLEN>ELEN in general.

We definitely aren't trying to preclude machines with XLEN > ELEN.  Your IDXLEN proposal seems workable.  (Note, ILEN is already used to refer to the width of the widest instruction the machine supports.)
Regarding your less-preferred alternatives:

Alternative 4 actually seems preferable to me.  For implementations whose spatial datapath width is already greater than ELEN, the main cost in increasing ELEN is in building functional units whose costs scale superlinearly in ELEN.  In that context, supporting larger ELEN only for these instructions is inexpensive.  (For machines where XLEN > ELEN and the spatial datapath width is only ELEN, there is a cost increase, but such machines seem quite contrived to me.)
Platforms are always free to opt for alternatives 1 or 2, regardless of what we specify here.
Alternative 3 is a non-starter, since that precludes gathering from arrays of pointers.

I would like @kasanovic and the rest of the TG to choose between your proposal (define IDXLEN = min(XLEN, ELEN) and use that), or your alternative 4 (support wider ELEN for these instructions only).

I modified my earlier post to use IDXLEN to avoid confusion.
Note that for alternative 4, in a legal-but-perhaps-unlikely implementation with XLEN=64, ELEN=32 and SLEN=32 the index value will be distributed across vector registers. I don't know if this is of any relevence from a hardware perspective but I thought it was worth mentioning.

@JamesKenneyImperas

One solution could be:
1   Define new IDXLEN (index length) as IDXLEN=min(XLEN,ELEN);
2   Recast your definition to use IDXLEN instead of XLEN throughout;
3   Specify that if IDXLEN<XLEN, the intermediate index is sign-extended to XLEN.

I prefer this approach, however I disagree with point 3.
I believe the current choice for zero-extension is preferred, conceptually easier for most applications. To handle as a signed index  subtract 2 ** (ELEN -1) from the base register and add to the vector elements.
@aswaterman

... Alternative 4 actually seems preferable to me, though.

4. Specify that an element size of XLEN must be supported in this special case even if XLEN>ELEN in general.

I see this as problematic.
In practice XLEN>ELEN means XLEN=2 * ELEN. [[For current targets, XLEN = 4 * ELEN is not a likely design point . With XLEN=64 an ELEN of 16 is improbably, and an ELEN=8 is ridiculous regardless of XLEN.]]
As much as support for index of pointers is desirable, is it practical when XLEN=2 * ELEN?
Alternative 4 does not have supporting instructions/modes to set up the indexes. This would require software to manipulate high-low element pairs if XLEN = 2 * ELEN. This is a high cost for the typical case when providing an offset rather than an address.
In many cases these high end elements value would be the same for all pairs. In which case IDXLEN = ELEN (alternative 1)  is not problematic, just add the upper constant to the base register.
I will suggest a escape mechanism from IDXLEN, rs1 is zero.
rs1=0  zero.can be reserved in all load/store.
But in indexed/AMO it means vs2 is an XLEN pointer rather than an IDXLEN offset..

@David-Horner Yes and no... you've already presupposed 32-bit indices are sufficient for these systems, so there isn't any need to provide the full arithmetic set for SEW=64.  You just need the sign-/zero-extension operations, whose cost is trivial.  You can do all the computation with SEW=32, then widen the result to 64 bits, then do an indexed memory access.

You just need the sign-/zero-extension operations, whose cost is trivial. You can do all the computation with SEW=32, then widen the result to 64 bits, then do an indexed memory access.

Are you proposing augmenting Alternative 4 to include that extend to XLEN instruction?
It appears a relatively high incremental cost. Rather the expansion can be done in software.
I don't think there needs to be such a presupposition.
It will only be in the context of a finalized RVV design that hardware designers will determine if ELEN < XLEN meets their target audience. Handling 64-bit indices in software (using ELEN operations) may be sufficient when there is a mechanism (pointers) to provide the actual load/store/AMO.
For XLEN=64 ELEN=32:
64bit arithmetic has many software approaches, but none are low overhead for ELEN=32 (especially as element-pairs) . Thus such cost could be paid for pointers only, when 32-bit offsets are sufficient.

Some arguments in this discussion leverage the possibility that ELEN < XLEN; whether or not this is actually permitted is being discussed over at #404.

@David-Horner

Are you [@aswaterman] proposing augmenting Alternative 4 to include that extend to XLEN instruction?

Over at #404 relaxing widening constraints provides that function:
Allowing 2 * ELEN is low cost for integer widening operations add/subtract, somewhat more so for multiply/multiply-add. The tie-in to #401 is that for XLEN = 2 * ELEN, these 2 * ELEN widening operations allow building complex XLEN offsets based on successive multiplication and additions of matrix indices.
This option of using Alternative 4 with XLEN = 2 * ELEN widening ops ,  and my proposal for rs1=x0 to differentiate between offsets and pointers are not mutually exclusive but they provide some weighing towards Andrew's proposal.

Superseded by recent changes.

authors: David-Horner JamesKenneyImperas aswaterman knightsifive

repo: riscv/riscv-v-spec


text:
bookmyshow cities  doesn't show err for non-existing city

bookmyshow cities <city> which random  name should give an error for which the city doesn't exist as :
 throw new Error('Oops! City not found');  in cities.ts
but it only giving table like

@rishavanand can you clarify this behavior,  this should be a bug or feature tag ?

@rohanprasadofficial For me it should be a feature. A feature that will clearly clarify that the city entered by the user could not be found.

@rishavanand  Great

authors: rishavanand rohanprasadofficial

repo: rishavanand/bookmyshow-cli


text:
[semver:FOO] First hello world custom orb

[semver:FOO] First hello world custom orb

[semver:FOO] First hello world custom orb

repo: rishikhuranasufi/custom-orbs


text:
Add different DSA algorithm

Illustration of different DSA algorithms are wanted.
Please contribute to DSA/Language Name/Folder(Algorithm)/Script
If folders for your suitable language is not included please add one, and then contribute.
Readme file is mandatory for all PRs

I'll do it

I'll do it
Please proceed. Follow contributor's guideline.

I would also like to contribute in this repository as my first issue and participation in Hacktoberfest 2022

I have added few files and sent the pull request can you please verify

I would also like to contribute in this repository.

I would also like to contribute in this repository.

okay contribute. But make sure your algorithm is different from already added algorithms.

@sudipg4112001
Please assign this to me

repo: risingstar-bit/Compose-Community


text:
remote sink writer gets stuck when connector node throws exception

Describe the bug
When using jdbc sink, the sink writer gets stuck when the connector node throws an exception while writing a chunk to the external database.
Barriers get piled up. Sink executor has no throughput.
Error message/log
No response
To Reproduce
No response
Expected behavior
Manually comment out some code and keep only the following logic

remote sink writer ignores all checkpoint barrier and on barrier it only sends a barrier request that don't need waiting for a response.
remove all code of jdbc sink, and only keep some dummy logic to make the code compile
on connector node, in the sink stream observer, manually throw an exception when processing the 10th write batch.

When we create the following datagen source and jdbc sink
CREATE source s1 (seq_id bigint, user_id bigint,
  user_name varchar)
WITH (
     connector = 'datagen',
     fields.seq_id.kind = 'sequence',
     fields.seq_id.start = '1',
     fields.seq_id.end = '100000000',
     fields.user_id.kind = 'random',
     fields.user_id.min = '1',
     fields.user_id.max = '10000000',
     fields.user_name.kind = 'random',
     fields.user_name.length = '10',
     datagen.rows.per.second = '500000'
 ) format plain encode JSON;

create sink s1_sink from s1
with (
connector = 'jdbc', type='append-only'

The sink writer gets stuck.
How did you deploy RisingWave?
No response
The version of RisingWave
No response
Additional context
No response

Our current logic of remote sink writer:
On client side we have an bounded request channel. The receiver side is passed to the grpc client when making a new request. The remote sink writer holds a sender to send the request. For WriteBatch non-checkpoint Barrier request, we only send the request without waiting for a response. For checkpoint Barrier request, we will wait for the commit response from the server.
On server side, our implemented stream observer is like the following
void onNext() {
    try {
          // may throw some exception
    } catch (Exception ex) {
          responseObserver.onError(ex);
    }
}

Just had a test on the behavior of java grpc server.
In our current implementation, when any exception is thrown in onNext, it will be caught with a try-catch. The exception is not thrown again, but will be passed to the responseObserver.onError.
Since responseObserver.onError is called, the stream handler will stop handling any new request. On client side, though the responseObserver.onError is called, since we only poll new response when we see a checkpoint barrier, if no checkpoint barrier is coming, we are not able to see the error in the response stream. Meanwhile, it seems that though the java stream handler has stopped working, the grpc stream still exists, and therefore the request receiver will not be dropped, and we can keep sending new request, and finally get stuck when the bounded channel gets full.

Some new test.
If we change the logic to throw the caught exception
void onNext() {
    try {
          // may throw some exception
    } catch (Exception ex) {
          responseObserver.onError(ex);
          throw ex;
    }
}

The behavior is the same. The log of connector node will have an exception log from the grpc runtime.
SEVERE: Exception while executing runnable io.grpc.internal.ServerImpl

The onError or onComplete of the request observer will not be called.

In conclusion, on either responseObserver.onError is called, or any exception is thrown from the call on onNext, the request handler will be seen as finished, and no more onError or onComplete will be called. Therefore we should also do the cleanup when any exception is thrown.
But in either way, on client side, the request receiver will not be dropped, and we can still send new request with the sender without any error, and will get stuck when the bounded channel gets full. The only way for the client to know about the error in stream is to poll the response stream.

repo: risingwavelabs/risingwave


text:
failed to parse column 'date_time' from json

Describe the bug
ERROR risingwave_source::parser::json_parser: failed to process value ({"_row_id":23957,"date_time":"2022-09-21 09:45:47.387344020"}): failed to parse column 'date_time' from json: Parse error: Can't cast string to timestamp (expected format is YYYY-MM-DD HH:MM:SS[.MS] or YYYY-MM-DD HH:MM or YYYY-MM-DD or ISO 8601 format)

To Reproduce
On EC2,
./risedev d full
create source s1 (date_time Timestamp) with (connector = 'datagen') row format json;
create materialized view m1 as select * from s1;

commit 9520c748a90d201bc9c716feff45333f7aa49356
No error on my laptop..
Expected behavior
No response
Additional context
No response
@jon-chuang

Test all data types generation(connector = datagen) in e2e tests

I get the error on my Linux, x86 laptop. I guess the issue must be risedev build on mac.

Actually, it is weird if you can't reproduce locally. Please try again to confirm.

authors: jon-chuang lmatz


text:
feat(streaming): arrangement backfill

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
RFC: https://www.notion.so/risingwave-labs/Arrangement-Backfill-31d4d0044726451c9cc77dc84a0f8bb2
We implement the arrangement backfill executor in this PR.
Integration tests are difficult to write for it, since CreateMviewProgress needs to be mocked as well, which does not seem trivial to me.
Since this is not used yet, I think it is fine to just do a code review of the corresponding changes to the code base before merging. I will defer frontend changes to later to avoid too large a PR.
It will be tested later when frontend support is added too. When that happens I will test it e2e with existing e2e test + adding some scale and recovery tests specific to arrangement backfill.
It will also be benchmarked against backfill then.
Comparison to backfill:

StateTable is needed for replication. So it uses StateTable instead of StorageTable. Later frontend will need to take care of instantiating the table, making sure it is of type is_replicated. We should add an assertion for ArrangementBackfill::new when that's done.
When we receive barrier, we have to flush the changes to state_table, to ensure it is replicated, before any new snapshot read.
Because this involves a write to StateTable, this also means we have to break out of the backfill stream loop first. This is so we drop the immutable reference to StateTable, which is used to read snapshot.
As a result we shift the entire barrier processing logic to outside the backfill stream loop.
It makes the logic a little convoluted, I welcome ideas to simplify it further. Refactoring it into a function (process_barrier) does not seem ideal as well, since it covers many variables >= 10.

Here are further changes to existing interfaces:

These changes are mainly for state table to support reads (previously we use interface of StorageTable, which already supported our read pattern). Our read pattern is different, so we need additional interfaces.
Implement state table interface for iterating through state_table by vnodes.
This is supported by the iter_all_vnodes_with_pk_range.
Support ordered iteration of rows. This is done by duplicating merge_sort implementation from batch. Ideally I would like to reuse the original merge_sort there, but there are some difficulties as described in the docstring.
Also support iter by chunk, via collect_data_chunk. I managed to refactor it so it could be reused, but can't quite keep this method in a trait, due to orphan instance rules.
I kept the TableIter interface, since several locations use its next_row method still. It can be removed next time.

Regarding persisting arrangement backfill state:

Currently I keep the logic from backfill used to persist the state.
This is because it seems to require minimal logic (just need to update pk_in_output_indices) to maintain it.
If it causes trouble after arrangement_backfill is implemented e2e, I will remove it.
Otherwise it makes sense to keep it, since it will be much harder to add back later.

Checklist For Contributors

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
[ ] All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

[ ] I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

[x] My PR DOES NOT contain user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

Add back user-facing-changes in https://github.com/risingwavelabs/risingwave/pull/10400. This PR does not change anything for end user.

I would like to take a look as well later. 🥰

Have updated the implementation, it should match the proposal from patrick now: https://github.com/risingwavelabs/risingwave/pull/10266#discussion_r1241042988.
Will leave some comments on certain parts which may need further review.
Will do a second pass tomorrow as well.

The new snapshot_read_per_vnode LGTM.

authors: BugenZhao chenzl25 kwannoel


text:
fix(meta): rename --license-key-file to --license-key-path

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?
The new argument introduced in https://github.com/risingwavelabs/risingwave/pull/18768 was mistakenly named --license-key-file, while the env var and internal names are license_key_path. This PR unifies the naming.
See also:

https://github.com/risingwavelabs/risingwave/pull/18768#discussion_r1794983086
https://github.com/risingwavelabs/risingwave-operator/pull/732

Checklist

[x] I have written necessary rustdoc comments
[x] I have added necessary unit tests and integration tests
[x] All checks passed in ./risedev check (or alias, ./risedev c)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#18838  👈
#18823
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @BugenZhao and the rest of your teammates on  Graphite

Merge activity

Oct 11, 12:47 AM EDT: A user started a stack merge that includes this pull request via Graphite.


text:
Contributing templates

You get no PR message this time.

Thanks! For the record, see #14.


text:
live server issues

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Other: <!-- Please describe: -->

Current behavior

Expected behavior

Environment
Browser:

- [ ] Chrome (desktop) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] IE version XX
- [ ] Edge version XX

For Tooling issues:

- Live Server: <!-- Check which version is installed -->
- Platform:  <!-- Mac, Linux, Windows -->
- Visual Studio Code: <!-- `code --version` -->

Others

????

repo: ritwickdey/vscode-live-server


text:
Change unwrap!() to handle results

Changes

Current dependencies on/for this PR:

main

PR #275

PR #276   👈

This stack of pull requests is managed by Graphite.

Leave your own ReviewMojis with Graphite!

Leave your own ReviewMojis with Graphite!

Nick is about to see some wacky macro magic

authors: AngelOnFira NathanFlurry

repo: rivet-gg/rivet


text:
revise arbitrary data

Currently arbitrary data is:

optional
2 dimensional and no size limit
requires a prefix NonSia

Instead I propose arbitrary data to:

remain optional
be 1 dimensional and have a size limit
require no prefix and leave the format up to the use case

We can do this as there is no reason we would ever want to use arbitrary data for any serious purpose. Even if somehow we have a new destination for the arbitrary data, we could still for that purpose check if it has the format we would expect, and if so, use it, otherwise it's just to be seen as any other arbitrary data.

~have a size limit~

for now this idea is cancelled, as size limit is already implicitly defined due to the fact that it has to fit into a block

Closed in 835929e.

repo: rivine/rivine


text:
🛑 1bitcoin is down

In ebd96b3, 1bitcoin (https://www.satubitcoin.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: 1bitcoin is back up in fb3e514 after 12 minutes.

repo: rizalrenaldi/ruptime


text:
Memory Leak

Memory usage gradually increases throughout experiment run.

Seems like calls to both ClientCluster.train_clients() and ClientCluster.eval_model() trigger jumps in memory usage.

Thought this would be a Ray memory management issue like this but it seems like issue is in the Client training. Removing the return value in Client._train causes the issue to persist:
def _train(self, num_epochs: int = 1, batch_size: int = 10) -> tuple:
        self.num_epochs = num_epochs
        self.batch_size = batch_size

        self.metrics = {}

        update = self.train()

        training_result = {
            constants.CLIENT_ID_KEY: self.id,
            constants.NUM_SAMPLES_KEY: self.num_train_samples,
            constants.METRICS_KEY: self.metrics
        }

        if type(update) == dict:
            training_result.update(update)
        else:
            training_result[constants.UPDATE_KEY] = update

        # return training_result

However, removing the entire function substantially reduces (by several orders of magnitude) the memory usage:
def _train(self, num_epochs: int = 1, batch_size: int = 10) -> tuple:
        pass

Issue seems to be in update = self.train(), as commenting out just this line (and references to update and the return) also largely eliminates the memory leak.

Memory leak is unrelated to the model training process. Issue persists when flops = self.model.train_model(self.train_data, self.num_epochs, self.batch_size, self.device) is commented out from Client.

When self.model.to(self.device) and self.model.to("cpu") are commented out from Client, memory leakage seems to reduce significantly but not as much as just commenting out the whole function.

When compute_grads is set to False along with removing self.model.tos, self.model.train_model, and return in Client._train, memory leaks become negligible. I suspect the issue is with Tensor cloning for creating the grads as well as something with the self.model.to calls.

repo: rizhu/rayleaf-source


text:
Possibly my mistake, but I keep getting this error

Describe the bug
I am connecting to a local LM Studio instance running the API. I know this works because the Twinny chat completion is working.
But when I try code completion I get this error in LMStudio:

Do I have to set the prompt in twinny myself? In LMStudio? Thanks for help with a noob problem.
Expected behavior
Code completion

Hello @russsavagedentsu, it was my fault, I broke it in previous release.  I just pushed a fix in 3.10.11.  Please could you let me know how you get on, I have tested it and it works.
Many thanks

No worries, thanks!

authors: rjmacarthy russsavagedentsu

repo: rjmacarthy/twinny


text:
[fix-2] ListNode stub is changed to spy

Приветствую.
На текущий момент в тестах к заданию 14-queue конструктор ListNode подменяется заглушкой. Из-за этого тест падает в случаях, когда решение основано на передаче в данный конструктор значения для ноды очереди.
Пруфы, что проблемы не только у меня: 1, 2. Также, если посмотреть работы уже сдавших задание студентов, то будет видно, что они все так или иначе используют обходные решения: или в дополнение к основной очереди (основанной на ListNode) заводят ещё одну, или не используют конструктор, а задают значение для ноды напрямую.
Данный фикс чинит тесты, заменяя sinon.stab() на обёртку sinon.spy(), тем самым сохраняя изначальный функционал конструктора.
До фикса:

После фикса (если не подключить ListNode):

После фикса (если подключить ListNode, как указано в задании):

@no-regerts спасибо большое, можно было бы и без пруфа :)

authors: no-regerts rkhaslarov


text:
🛑 Library is down

In 8a7e246, Library (http://library.cvsu.edu.ph) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Library is back up in 47b2999 after 2 days, 10 hours, 13 minutes.

repo: rlvillacarlos/cvsu-site-monitor


text:
Consider change url submodule from ssh to https

Hello! Consider change url submodule from ssh to https
https://github.com/rmboggs/DocxToSource/blob/master/.gitmodules#L3
it is not convenient for new users
Workaround:
in root directory
git config submodule."src/Serialize.OpenXml.CodeGen".url https://github.com/rmboggs/Serialize.OpenXml.CodeGen.git

Yeah, your right.  I'll see if I can fix this when I get back from vacation, sometime next week.

Should be good now....

https://github.com/rmboggs/DocxToSource/commit/36399ce7b84cb141fb62e4baf393afd0c3c73901

authors: rmboggs rstm-sf

repo: rmboggs/DocxToSource


text:
Empty password fix and syslog output

Fix empty password handling (=> deny them) and add pam_unix.so-like syslog output.

Updated the PR to avoid syslog-ging the password

Thanks!


text:
Remove CHANGELOG.md or keep it up to date

Thanks for a nice package 👍
I really love a good CHANGELOG to get to know what's new in a version, but what's worse than no CHANGELOG is an outdated one – especially for an Atom package as Atom itself highlights the CHANGELOG on the package's page in the app.
As it looks like the CHANGELOG is no longer intended to be updated, then it should in my opinion be removed.

Thanks for responding so quickly and for keeping the changelog 😊👍

repo: rmosolgo/language-graphql


text:
composer crushes -  Invalid version string "v4.1.*"

[RuntimeException]
Could not load package rmrevin/yii2-fontawesome in http://packagist.org: [UnexpectedValueException] Could
not parse version constraint v4.1.: Invalid version string "v4.1."
[UnexpectedValueException]
Could not parse version constraint v4.1.: Invalid version string "v4.1."

Versions of extension rmrevin/yii2-fontawesome are not versions of the font.
Lastes version of rmrevin/yii2-fontawesome is 2.13.0

Совет не о чем.
Попробуй сделать апдейт и увидишь ту же ошибку у себя. плюсую топик стартеру.

@achertovsky
вопрос ни о чём.
У моего расширения нет версии v4.1.
Композер ясно об этом говорит.

в композере указана версия ~2.11

@rmrevin
http://screencloud.net/v/3kfK

error received when trying to update composer with fontawesome, it is looking for fontawesome 4.1.* version:
/.composer/cache/repo/https---packagist.org/provider-rmrevin$yii2-fontawesome.json from cache
[RuntimeException]
Could not load package rmrevin/yii2-fontawesome in http://packagist.org: [UnexpectedValueException] Could not parse version constraint v4.1.: Invalid version stri
ng "v4.1."

@spi7fire @achertovsky
You do composer update or composer install?

@rmrevin
same result for install and update.

Version v4.1.* is version of fontawesome in extension version 1.2.0 (old version) https://github.com/rmrevin/yii2-fontawesome/releases/tag/1.2.0.
Since then expansion has came to use bower package.
And for some reason the developers was renamed this release.
http://i.imgur.com/FNp0dBA.png (version 4.1.0 without v)
Just checked, the package is installed without problems.
Try to remove and reinstall the package.
composer require rmrevin/yii2-fontawesome --prefer-dist
Using version ^2.13 for rmrevin/yii2-fontawesome
./composer.json has been updated
Updating dependencies (including require-dev)
  - Installing bower-asset/fontawesome (v4.5.0)
    Loading from cache

  - Installing rmrevin/yii2-fontawesome (2.13.0)
    Loading from cache

Writing lock file
Generating autoload files

Developers make two tags 4.1.0 and v4.1.0 http://i.imgur.com/uGrIZyw.png
Packagist apparently later changed his tag to a fresh or merged two versions.

@rmrevin
so u want to tell that this bug is temporary?

No, not temporary. At the time of release 1.2.0 of this god it was not.
If you want to use a branch 1.*, you must install version 1.2.1. There's this bug is fixed.
https://github.com/rmrevin/yii2-fontawesome/releases/tag/1.2.1

@rmrevin
http://screencloud.net/v/knTB

Obviously, you composer establishes an older version.
Try to update composer, update the plugin fxp/composer-asset-plugin and clear the cache composer.
And repeat the installation.

@rmrevin
looks like cache. ty for u'r time!

I'm glad I could help.
Can you put a star to this extension.

@rmrevin
done

Thanks!

authors: achertovsky rmrevin spi7fire


text:
Setting virtualHost automatically

#2
folders:
  - map: ~/applicationPath
    to: /home/vagrant/applicationPath
sites:
  - map: gardening.app
    to: "/home/vagrant/applicationPath/public"

make nginx.conf -> set virtualhost

repo: rnitame/Vagrantfile


text:
[Bug]: Offline manager not downloading beyond zoom level 15?

Mapbox Implementation
Mapbox
Mapbox Version
default
Platform
iOS, Android
@rnmapbox/maps version
10.1.0-rc.4
Standalone component to reproduce
import geoViewport from '@mapbox/geo-viewport';
import Mapbox, {
    Camera,
    MapView,
    offlineManager,
    StyleURL,
} from '@rnmapbox/maps';
import React, { useState } from 'react';
import { Button, Dimensions, TextInput } from 'react-native';

const CENTER_COORD = [-73.970895, 40.723279];
const MAPBOX_VECTOR_TILE_SIZE = 512;
console.log('=> Mapbox[0]:', Mapbox);
console.log('=> Mapbox.StyleURL[1]:', Mapbox.StyleURL);
console.log('=> StyleURL[2]:', StyleURL);
const STYLE_URL = Mapbox.StyleURL.Satellite;

const OfflineExample = () => {
    const [packName, setPackName] = useState('pack-1');
    const [showEditTitle, setShowEditTitle] = useState(false);

    return (
        <>
            <Button
                title={`Pack name: ${packName}`}
                onPress={() => {
                    setShowEditTitle(!showEditTitle);
                }}
            />
            {showEditTitle && (
                <TextInput
                    value={packName}
                    autoFocus={true}
                    onChangeText={(text) => setPackName(text)}
                    onBlur={() => setShowEditTitle(false)}
                />
            )}
            <Button
                title="Get all packs"
                onPress={async () => {
                    const packs = await offlineManager.getPacks();
                    console.log('=> packs:', packs);
                    packs.forEach((pack) => {
                        console.log(
                            'pack:',
                            pack,
                            'name:',
                            pack.name,
                            'bounds:',
                            pack?.bounds,
                            'metadata',
                            pack?.metadata,
                        );
                    });
                }}
            />
            <Button
                title="Get pack"
                onPress={async () => {
                    const pack = await offlineManager.getPack(packName);
                    if (pack) {
                        console.log(
                            'pack:',
                            pack,
                            'name:',
                            pack.name,
                            'bounds:',
                            pack?.bounds,
                            'metadata',
                            pack?.metadata,
                        );

                        console.log('=> status', await pack?.status());
                    }
                }}
            />
            <Button
                title="Resume pack"
                onPress={async () => {
                    const pack = await offlineManager.getPack(packName);
                    if (pack) {
                        await pack.resume();
                    }
                }}
            />
            <Button
                title="Remove packs"
                onPress={async () => {
                    const result = await offlineManager.resetDatabase();
                    console.log('Reset DB done:', result);
                }}
            />
            <Button
                title="Create Pack"
                onPress={() => {
                    const { width, height } = Dimensions.get('window');
                    const bounds = geoViewport.bounds(
                        CENTER_COORD,
                        12,
                        [width, height],
                        MAPBOX_VECTOR_TILE_SIZE,
                    );

                    const options = {
                        name: packName,
                        styleURL: STYLE_URL,
                        bounds: [
                            [bounds[0], bounds[1]],
                            [bounds[2], bounds[3]],
                        ],
                        minZoom: 16,
                        maxZoom: 20,
                        metadata: {
                            whatIsThat: 'foo',
                        },
                    };
                    offlineManager.createPack(options, (region, status) =>
                        console.log(
                            '=> progress callback region:',
                            'status: ',
                            status,
                        ),
                    );
                }}
            />
            <MapView style={{ flex: 1 }} styleURL={STYLE_URL}>
                <Camera zoomLevel={10} centerCoordinate={CENTER_COORD} />
            </MapView>
        </>
    );
};

export default OfflineExample;

/* end-example-doc */

Observed behavior and steps to reproduce
Using the Offline Example I am able to successfully download an offline tilepack for zoom levels 10-20.
When the minZoom level is changed to be greater than or equal to 16, the download will fail, showing the progress percentage as 'NaN'
 LOG  => progress callback region: status:  {"completedResourceCount": 0, "completedResourceSize": 0, "erroredResourceCount": 0, "loadedResourceCount": 0, "loadedResourceSize": 0, "name": "pack-1", "percentage": NaN, "requiredResourceCount": 0, "state": "complete"}

Expected behavior
Offline manager should create a tilepack for the zoom levels request
Notes / preliminary analysis
Even when the minZoom is less than 16, the actual downloaded tiles don't contain any tiles for any zoom level past 15.  This can be confirmed by creating a tilepack for zoom levels 10-20 and another for zoom levels 10-15, then comparing the resource size and noticing that they are exactly the same.
Additional links and references
https://github.com/rnmapbox/maps/blob/main/example/src/examples/Map/OfflineExample.tsx

See also:
https://github.com/mapbox/mapbox-maps-ios/issues/1056

See also: mapbox/mapbox-maps-ios#1056

@mfazekas in the link you posted about this upstream issue above, the person there recommended to continue using the legacy offline APIs for offline support of zooms higher than 16. Is there any way in version 10 of this repo to use the legacy offline APIs mentioned in the ticket? Thanks!

@ZiZasaurus can you look this problem
https://github.com/rnmapbox/maps/issues/3076#issuecomment-2011396346

@jgrant41475 , am also facing the same  if you solved the problem , please can you guide me.

@jgrant41475 , am also facing the same if you solved the problem , please can you guide me.

Hey @sampathkumarch, sorry for the late response I'm pretty bad at checking my notifications.
After discussing with the mapbox community team, we ultimately decided to accept the zoom limitations with the mapbox SDK.
The limitation stems from the fact that the default tiling scheme only goes up to zoom level 16, so if you are able to use a custom imagery source that does contain higher zoom levels, then the SDK should work as expected.  Unfortunately, for our needs, this was not a feasible solution.
Below is a snippet of the communication that I hope provides useful context for others with this issue:

So I've learned from the team that the core restriction actually stems from the Tiling Scheme of the core SDK. The default (which was decided based on vector tiles, as you note) only goes up to level 16, which means that if a tiling scheme is not specified by the TileJSON for the tileset source, then GL native uses the default one (z16). To enable caching of higher zoom levels, the source (in this case, the core Mapbox satellite tileset) would need to include a custom tiling scheme that includes the higher zoom levels.

authors: chris-gaona jgrant41475 mfazekas sampathkumarch

repo: rnmapbox/maps


text:
WIP: CFDP Handler Init

Fixes for documentation
Internal simplifications, a lot number of globals reduced by grouping related configuration
CFDP Handler added

Codecov Report

Merging #45 (ec1a049) into develop (75fda59) will increase coverage by 1.16%.
The diff coverage is 59.35%.

@@             Coverage Diff             @@
##           develop      #45      +/-   ##
===========================================
+ Coverage    45.57%   46.74%   +1.16%
===========================================
  Files           54       58       +4
  Lines         3945     4300     +355
===========================================
+ Hits          1798     2010     +212
- Misses        2147     2290     +143

Flag
Coverage Δ

unittests
46.74% <59.35%> (+1.16%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

src/tmtccmd/config/args.py
14.48% <0.00%> (-0.63%)
:arrow_down:

src/tmtccmd/config/com_if.py
24.79% <0.00%> (-0.42%)
:arrow_down:

.../tmtccmd/sendreceive/sequential_sender_receiver.py
23.68% <ø> (ø)

src/tmtccmd/sendreceive/tm_listener.py
28.03% <0.00%> (-0.12%)
:arrow_down:

src/tmtccmd/sendreceive/cmd_sender_receiver.py
16.52% <33.33%> (+0.52%)
:arrow_up:

src/tmtccmd/config/globals.py
40.50% <36.00%> (-1.27%)
:arrow_down:

src/tmtccmd/core/backend.py
41.08% <38.09%> (-1.09%)
:arrow_down:

src/tmtccmd/core/globals_manager.py
69.56% <40.00%> (ø)

src/tmtccmd/cfdp/filestore.py
53.28% <53.28%> (ø)

src/tmtccmd/config/hook.py
70.12% <60.00%> (+0.26%)
:arrow_up:

... and 7 more

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 75fda59...ec1a049. Read the comment docs.

authors: codecov-commenter robamu

repo: robamu-org/tmtccmd


text:
"Typo" in documentation for range of midi channel

This is a bit of a smart ass "issue" but in "https://github.com/robbert-vdh/nih-plug/blob/master/src/midi.rs" the channel of NoteEvent (For messages that have a channel) is declared as:
    /// The note's channel, from 0 to 16.
    channel: u8,

It should probably read 0 to 15 (4-Bit) if it is zero based or 1-16. From my experience it is zero based.
https://www.cs.cmu.edu/~music/cmsip/readings/MIDI tutorial for programmers.html

It's 0..16. The to is exclusive here. I'll probably rewrite all of these comments at some point to use Rust's range syntax at some point.

Thanks for the response! Should I close the issue?

Can keep it open, I'll need change this at some point. 'x to y' means that y is exclusive to most people (as opposed to 'x through y'), but since that's apparently still ambiguous it's probably best to just use Rust range syntax here.

I tried a couple things but all the alternatives just read worse. So instead I added a note on what from x to y means and I changed all floating point ranges to be in the standard [x, y] interval notation.

Hi, thank you for the fixes. I hate to say that now it is wrong in another place :-/, because in the next line where the note value is defined, it says it goes from 0 to 127. But in this case it 127 should be included. If I may make a suggestion:
pub enum NoteEvent {
    /// A note on event, available on [`MidiConfig::Basic`] and up.
    NoteOn {
        timing: u32,
        /// A unique identifier for this note, if available. Using this to refer to a note is
        /// required when allowing overlapping voices for CLAP plugins.
        voice_id: Option<i32>,
        /// The note's channel, with values from 0 to 15 inclusive.
        channel: u8,
        /// The note's MIDI key number, with values from 0 to 127 inclusive.
        note: u8,
        /// The note's velocity, in the range `[0, 1]`. Some plugin APIs may allow higher precision
        /// than the 127 levels available in MIDI.
        velocity: f32,
    },
   //...
}

I think it is better to keep it simple and unambigious. Also it is might be better to keep it in one place, because if I look it up in the reference I will usually not look at the beginning of the file or read the full text. A reference is not meant to be read completely but to look up specific things. Also if you hover it in any IDE it will not show the explanation in the beginning.
If you agree I can try to make a PR if you like.

repo: robbert-vdh/nih-plug


text:
Move wiki to sphinx

Using sphinx for documentation would both be easier to browse and to maintain through pull requests. Pull requests that modify functionality or add features could also directly contain the updated documentation so that both get updated if the PR is merged.
I would be able to assist merging the wiki over to sphinx through an initial pull request. Sphinx can be found at http://sphinx-doc.org/.

@darayus One of things that I'd like to see happen is have more documentation within the actual code base (in individual README.x files for each plugin).

authors: darayus robbyrussell

repo: robbyrussell/oh-my-zsh


text:
Revert "FIX: Db.save inside a transaction fails if DocumentQuery.searchable i…"

Reverts robconery/moebius#54

@robconery is this still needed?

Crap - I think I screwed up. Can you send the PR again - sorry for being so lame!

sure, will do

authors: amagdas robconery

repo: robconery/moebius


text:
Umstellung auf Impf-Abrechnungsdaten der Vertragsärzte für das 4. Quartal 2021

Liebe Alle,
wir möchten über die nächste planmäßige Umstellung im Impfquoten-Monitoring informieren:
Zum 22.06.2022 werden die COVID-19-Impfdaten aus dem KBV-Meldeportal für das 4. Quartal 2021 mit den Impf-Abrechnungsdaten der Vertragsärzte aus allen 17 KVen ersetzt. Die Impfquoten ändern sich wiederum leicht und geben den Stand der Impfinanspruchnahme in besserer Vollständigkeit und damit genauer wieder.
Hinweis zur Umstellung der Altersgruppe unter 18 Jahren
Für den Zeitraum 14.12.-31.12.21 liegen die KV-Abrechnungsdaten der <18-Jährigen nur für die Gesamtaltersgruppe vor, nicht aber weiter differenziert nach 5-11 Jahre und 12-17 Jahre. Daher wurde eine Ersetzung der KBV-Daten durch die KV-Daten für diesen Zeitraum zwar für die Gesamtgruppe <18 Jahre vorgenommen, nicht jedoch für die beiden Einzelaltersgruppen 5-11 und 12-17 Jahre, für die weiterhin die KBV-Daten verwendet wurden. Somit können rund 35.000 Impfungen im Alter <18 Jahren nicht korrekt den beiden Einzelaltersgruppen zugewiesen werden.
Weiterführende Informationen
Die aktuellen Daten und weitere Informationen finden Sie dann wie gewohnt unter www.rki.de/covid-19-impfquoten und in der Datensatzdokumentation.
Antworten auf häufig gestellte Fragen zum Impfquotenmonitoring sind unter www.rki.de/covid-19-faq-impfen > Impfquotenmonitoring abrufbar.
Mit besten Grüßen
@HannesWuensche
für das Team RKI | Open Data

Eine kurze Frage dazu - mit der Umstellung gab es einen gewaltigen Sprung der Impfzahlen für Bayern:

Impfung +41732
Impfung +49163
Impfung +192152
Impfung +3987 (was eher normal scheint)

Ist das nur durch diese Umstellung zu erklären?
Jan

Hallo Jan,
die Sprünge in den Anzahlen stammen aus der hier angekündigten Umstellung (Ersetzung KBV-Schnellmeldedaten durch KV-Abrechnungsdaten für Q4 2021). Der Impfquoten-Datensatz stellt die kumulierten Impfzahlen bis einschließlich dem Vortag dar und beinhaltet mit der Veröffentlichung am 22.06.22 das erste Mal die KV-Abrechnungsdaten für Q4 2021 (siehe Datensatzbeschreibung).
Mit besten Grüßen,
@fischerc-rki
für das Team RKI | Fachgebiet IT 4 (Development)

Danke für die Erklärung. Sieht zwar heftig aus in meiner Tabelle, aber ist dann halt so :)

Einen schönen Tag noch und nochmals Danke!
Jan

authors: HannesWuensche fischerc-rki jwildeboer


text:
Add a parameter to set the character separator between the package name and the package version when a cache folder is created to contain external binaries

For e.g. sysinternals package version 2023.7.26, the original ChocolateStore project creates a folder sysinternals-2023.7.26 where the external binaries called by sysinternals.2023.7.26.nupkg are downloaded.
This new ChocolateStoreCore project now creates a folder sysinternals.2023.7.26 (i.e. with a . in the middle instead of -).
This is not a problem for the sysinternals package since it works well but it may cause conflicts for packages where we need/want to edit ourselves the .nupkg (e.g. some packages need manual modification to really work offline) since when we extract the .nupkg, its content would be merged with the folder containing existing (and possibly wrong) binaries, which might not be desired.
That being said, it is not an important issue since an obvious workaround is to extract the .nupkg elsewhere but I would say it is a minor regression/breaking change compared to the original ChocolateStore project. A parameter to choose between the . or - (or something else) could be an idea for that.

I added a new version. Please check it out.

authors: lebarsfa robertZaufall

repo: robertZaufall/ChocolateStoreCore


text:
HTML icon broken/missing

After the latest update, 4.2.0, the new svg version of the html icon doesn't appear and instead defaults to the fallback "white-paper" icon.
Screenshot

VS Code info
Version: 1.8.0
Commit: 38746938a4ab94f2f57d9e1309c51fd6fb37553d
Date: 2016-12-13T17:45:32.595Z
Shell: 1.4.6
Renderer: 53.0.2785.143
Node: 6.5.0
Windows Version: 7 Enterprise SP1
DOM

    index.html

But any icon but html will be displayed normally?

I'm seeing it... can you try to reinstall the extension?

It works too, in my enviroment.

Uninstalling, then reinstalling the extension didn't produce any different results.

Which vscode version are you using?

Just updated the issue with all that info, actually.

Go to C:\Users\<youruser>\.vscode\extensions\robertohuertasm.vscode-icons-4.2.0 and remove it manually.
Then reinstall again the extension and let me know.

No change.

Ran all the icons through svgo and didn't get any changes either.
Also added an actual DOM node to the issue.

Figured it out @robertohuertasm. The language ID is overriding the extension icon. Since I'm using JonathanWolfe/language-polymer and associate all HTML files to that type, it's trying to give it that icon (but there isn't one), and instead of falling back to the extension, it falls back to the default icon.

Great!

I'm guessing there's nothing this repo could do to fix it? Should I go open an issue on the vs-code repo?

This is a candidate on

Sure, I'll add the icon after lunch.

If you can use svg that would be awesome!

authors: JonathanWolfe jens1o robertohuertasm

repo: robertohuertasm/vscode-icons


text:
🛑 Revista Cómo ves is down

In 7a61264, Revista Cómo ves (http://www.comoves.unam.mx) was down:

HTTP code: 502
Response time: 516 ms

Resolved: Revista Cómo ves is back up in 693b8f8.

repo: robertormzg/upptime-dgdc


text:
Update introduction.rst

Typo correction

Thank you!

authors: nuin robinandeer

repo: robinandeer/chanjo


text:
bug: Podfile : There are multiple dependencies with different sources

Describe the bug
On the iOS build, at the podfile install, the build fail with an error of 'multiple dependencies with different sources'.
CapacitorFirebaseAuthentication is present on the def capacitor_pods list, but already on the target app with CapacitorFirebaseAuthentication/Facebook + CapacitorFirebaseAuthentication/Google
To Reproduce
Steps to reproduce the behavior:

Clone https://github.com/robingenz/capacitor-firebase-authentication-demo repo
pnpm install
ionic build
npx cap sync ios

Expected behavior
iOS build has no error
Screenshots

Desktop (please complete the following information):
Ionic:
   Ionic CLI                     : 6.20.8 (/Users/julienkermarec/.nvm/versions/node/v18.14.0/lib/node_modules/@ionic/cli)
   Ionic Framework               : @ionic/angular 6.2.1
   @angular-devkit/build-angular : 14.1.1
   @angular-devkit/schematics    : not installed
   @angular/cli                  : 14.1.1
   @ionic/angular-toolkit        : 7.0.0

Capacitor:

   Capacitor CLI      : 5.0.0
   @capacitor/android : 5.0.0
   @capacitor/core    : 5.0.0
   @capacitor/ios     : 5.0.0

Utility:

   cordova-res                          : 0.15.4
   native-run (update available: 1.7.4) : 0.3.0

System:

   NodeJS : v18.14.0 (/Users/julienkermarec/.nvm/versions/node/v18.14.0/bin/node)
   npm    : 9.3.1
   OS     : macOS
   Xcode : 15.0.1

Additional context

Console error :

➜  capacitor-firebase-authentication-demo-main npx cap sync ios
[warn] The bundledWebRuntime configuration option has been deprecated. Can be
       safely deleted.
✔ Copying web assets from www to ios/App/App/public in 240.03ms
✔ Creating capacitor.config.json in ios/App/App in 2.49ms
✔ copy ios in 305.95ms
✔ Updating iOS plugins in 11.96ms
[info] Found 4 Capacitor plugins for ios:
       @capacitor-firebase/authentication@5.1.0
       @capacitor/app@5.0.0
       @capacitor/haptics@5.0.0
       @capacitor/keyboard@5.0.0
✖ Updating iOS native dependencies with pod install - failed!
✖ update ios - failed!
[error] Analyzing dependencies
        [!] There are multiple dependencies with different sources for
        `CapacitorFirebaseAuthentication` in `Podfile`:

        - CapacitorFirebaseAuthentication (from
        `../../node_modules/.pnpm/@capacitor-firebase+authentication@5.1.0_mehzrf7cuo37n24skfzwzyfrom/node_modules/@capacitor-firebase/authentication`)
        - CapacitorFirebaseAuthentication/Facebook (from
        `../../node_modules/@capacitor-firebase/authentication`)
        - CapacitorFirebaseAuthentication/Google (from
        `../../node_modules/@capacitor-firebase/authentication`)

Podfile :

require_relative '../../node_modules/@capacitor/ios/scripts/pods_helpers'

platform :ios, '13.0'
use_frameworks!

install! 'cocoapods', :disable_input_output_paths => true

def capacitor_pods
  pod 'Capacitor', :path => '../../node_modules/.pnpm/@capacitor+ios@5.0.0_@capacitor+core@5.0.0/node_modules/@capacitor/ios'
  pod 'CapacitorCordova', :path => '../../node_modules/.pnpm/@capacitor+ios@5.0.0_@capacitor+core@5.0.0/node_modules/@capacitor/ios'
  pod 'CapacitorFirebaseAuthentication', :path => '../../node_modules/.pnpm/@capacitor-firebase+authentication@5.1.0_mehzrf7cuo37n24skfzwzyfrom/node_modules/@capacitor-firebase/authentication'
  pod 'CapacitorApp', :path => '../../node_modules/.pnpm/@capacitor+app@5.0.0_@capacitor+core@5.0.0/node_modules/@capacitor/app'
  pod 'CapacitorHaptics', :path => '../../node_modules/.pnpm/@capacitor+haptics@5.0.0_@capacitor+core@5.0.0/node_modules/@capacitor/haptics'
  pod 'CapacitorKeyboard', :path => '../../node_modules/.pnpm/@capacitor+keyboard@5.0.0_@capacitor+core@5.0.0/node_modules/@capacitor/keyboard'
end

target 'App' do
  capacitor_pods
  # Add your Pods here
  pod 'CapacitorFirebaseAuthentication/Facebook', :path => '../../node_modules/@capacitor-firebase/authentication'
  pod 'CapacitorFirebaseAuthentication/Google', :path => '../../node_modules/@capacitor-firebase/authentication'
end

# Source: https://www.jessesquires.com/blog/2020/07/20/xcode-12-drops-support-for-ios-8-fix-for-cocoapods/
post_install do |installer|
  assertDeploymentTarget(installer)
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      config.build_settings.delete 'IPHONEOS_DEPLOYMENT_TARGET'
    end
    if target.respond_to?(:product_type) and target.product_type == "com.apple.product-type.bundle"
      target.build_configurations.each do |config|
          config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
      end
    end
  end
end

This is an issue with pnpm. I close this as duplicate of https://github.com/capawesome-team/capacitor-firebase/discussions/308. Here you can find a workaround: https://github.com/capawesome-team/capacitor-firebase/discussions/308#discussioncomment-5380508

authors: julienkermarec robingenz


text:
Improved Docker Build Process

Improve Docker Build by attempting to find better mirror and by using pre-built utility images.

Awesome!!!

authors: FanDjango robinrodricks

repo: robinrodricks/FluentFTP


text:
"Called without a valid file" on specific files

Hey,
I'm trying to retrieve artist and title tags from a couple of mp3 files that belong to the same album so they have the same codec, tag format, etc. However, 3 of these 10 files throw an error, claiming:
TagLib: FileRef::tag() - Called without a valid file.
TagLib: FileRef::audioProperties() - Called without a valid file.
When opening the files in nautilus, the tags look just the same as for those files which taglib-ruby can read and they are all playable in rhythmbox as well. The code I'm using is the following:
  def read_metatags
    TagLib::FileRef.open(self.local_path) do |fileref|
      unless fileref.null?
        logger.info "Reading tags"
        tag = fileref.tag
        self.title = tag.title
        self.artist = tag.artist

        properties = fileref.audio_properties
        self.length = properties.length
      end
    end
    self.save!
  end

I want to use the basic API as I only need the artist and title tag but want to have the possibility of throwing various formats at the program.
I know it's probably hard to reproduce the problem without the sample files but the ones I used are all license-protected so I don't think it would be okay if I shared them here.

I'm too getting this error "NoMethodError Error private method `open' called for TagLib::MPEG:Module" when I run the code from console and in resque workers the same error occurs the file path  is correct, and the code is :
ruby
TagLib::MPEG.open(rename_file) do |fileref|
unless fileref.null?
cover_tag = file.id3v2_tag
cover_img = cover_tag.frame_list('APIC').first
unless cover_img.blank?
ext = cover_img.mime_type.rpartition('/')[2]
o = [('a'..'i'), ('A'..'Z')].map { |i| i.to_a }.flatten
rand_string = (1..18).map { o[rand(o.length)] }.join
cover_file_name = "#{cover_path}#{File.basename(rename_file).chomp('.mp3').gsub('1-----','')}-#{rand_string}.#{ext}"
File.open(cover_file_name, "wb") { |f| f.write cover_img.picture }
end
end
end

@coderawal could you try TagLib::MPEG::File.open instead of TagLib::MPEG.open?

thanks @jacobvosmaer now it's working.

authors: coderawal jacobvosmaer kahliii

repo: robinst/taglib-ruby


text:
Not null violation: 7 ERROR: column "migration_name" contains null values

It seems the newly introduced migration_name column or the phinxlog table is designed to be NOT NULL. But with PostgreSQL you can't add a NOT NULL column to a table because the newly added column would have to be filled with NULL on creation which contradicts the column specification.
phinx migrate --verbose
Phinx by Rob Morgan - https://phinx.org. version 0.5.2

using config file ./phinx.yml
using config parser yaml
using migration path /Users/tpetry/www/myapp/webapp/app/data/migrations
warning no environment specified, defaulting to: postgresql
using adapter pgsql
using database myapp
 -- addColumn('phinxlog', 'migration_name', 'string')

  [PDOException]
  SQLSTATE[23502]: Not null violation: 7 ERROR:  column "migration_name" contains null values

Exception trace:
 () at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:304
 PDO->exec() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:304
 Phinx\Db\Adapter\PdoAdapter->execute() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PostgresAdapter.php:375
 Phinx\Db\Adapter\PostgresAdapter->addColumn() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Table.php:625
 Phinx\Db\Table->update() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Table.php:662
 Phinx\Db\Table->save() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:189
 Phinx\Db\Adapter\PdoAdapter->setConnection() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PostgresAdapter.php:79
 Phinx\Db\Adapter\PostgresAdapter->connect() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:204
 Phinx\Db\Adapter\PdoAdapter->getConnection() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:312
 Phinx\Db\Adapter\PdoAdapter->query() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:330
 Phinx\Db\Adapter\PdoAdapter->fetchAll() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:375
 Phinx\Db\Adapter\PdoAdapter->getVersionLog() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Db/Adapter/PdoAdapter.php:364
 Phinx\Db\Adapter\PdoAdapter->getVersions() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Migration/Manager/Environment.php:230
 Phinx\Migration\Manager\Environment->getVersions() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Migration/Manager.php:248
 Phinx\Migration\Manager->migrate() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Console/Command/Migrate.php:113
 Phinx\Console\Command\Migrate->execute() at /Users/tpetry/www/myapp/webapp/vendor/symfony/console/Command/Command.php:256
 Symfony\Component\Console\Command\Command->run() at /Users/tpetry/www/myapp/webapp/vendor/symfony/console/Application.php:791
 Symfony\Component\Console\Application->doRunCommand() at /Users/tpetry/www/myapp/webapp/vendor/symfony/console/Application.php:186
 Symfony\Component\Console\Application->doRun() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/src/Phinx/Console/PhinxApplication.php:82
 Phinx\Console\PhinxApplication->doRun() at /Users/tpetry/www/myapp/webapp/vendor/symfony/console/Application.php:117
 Symfony\Component\Console\Application->run() at /Users/tpetry/www/myapp/webapp/vendor/robmorgan/phinx/bin/phinx:28

Hi @tpetry, could you have a look at the changes in #804, and see if they fix the problem on Postgres?

authors: coatesap tpetry

repo: robmorgan/phinx


text:
Add bundled feature

This feature allows compiling and static linking a vendored version of libmagic. This pattern is used by many other crates like rusqlite or yara-rs, and makes it much easier to use them since they don't require having the library precompiled and available. It also makes it much easier to cross-compile, as only a C compiler for the target is necessary.
The bundled version is FILE_5.45

Hej @roblabla thanks for your contribution!
We've had a similar feature in #4 but that contribution got retracted.
While your implementation is pretty straightforward, I did and do have a couple questions/remarks/requirements that might take me a while to work through.
From the top of my head

this changes the license of the published crate to (MIT OR Apache-2.0) AND LicenseRef-file / BSD
which is a reason why I'd rather have the bundled code in yet another separate magic-src crate (cf. https://github.com/alexcrichton/openssl-src-rs ), even if that is not a common pattern on crates.io
this uses a naive cc build instead of autotools, which might have unexplored drawbacks
the feature is called "bundled" in config and "vendor" in docs, this seems to be a mistake
there's no docs how this interacts with the other crate features
the CI build has not been updated to consider the feature, but fails already
i'd have to look into the details, but there's e.g. a warning about unreachable code in build.rs
it's unclear to me what this means for Windows platform support
e.g. the previous implementation and the vcpkg feature use special versions of the dirent, getopt and tre dependencies which are not bundled/vendored
i'm not entirely sure I want this as a default feature since Rust's SBOM story is quite weak with static C libs, but then again the "vcpkg" feature pretty much is a bundled/vendored static build already. i see how it's more convenient, but I think you'd still have to distribute the default magic database (which is a papercut that cargo isn't really fit to solve anyway)?

I'm not quite sure I follow regarding cross-compilcation; this is easier than building libmagic separately using its original autotools?
Fair word of warning; I'm afraid the last pull request didn't get much traction since I have an incomplete idea of how this feature should work and am hesistant to merge a partial solution.

Thanks for the quick review!

this changes the license of the published crate to (MIT OR Apache-2.0) AND LicenseRef-file / BSD
which is a reason why I'd rather have the bundled code in yet another separate magic-src crate (cf. https://github.com/alexcrichton/openssl-src-rs ), even if that is not a common pattern on crates.io

Sure, that's a rather straightforward fix. Yara-rs used to do that too. Should I just make a new crate in this repo, and make a cargo workspace? New, separate repo with the source?

this uses a naive cc build instead of autotools, which might have unexplored drawbacks

This choice mostly comes down to trying to reduce the necessary build-time dependencies, and my past experiences cross-compiling with autotools being painful so I tend to avoid it. Using cc comes with a couple of gotchas (for instance, I define the HAVE_UNISTD_H and others in cc without actually testing for its existence - in practice it's unlikely to matter on most platforms). I need to work through all the HAVE_ defines in file - I know I'm missing some, I was mostly going for the minimal amount here to get something as cross-platform as possible.
One of the main "downsides" with the way I currently build is that I don't enable any of the optional feature. This means no decompression for instance (as that requires depending on libz, libbz2, liblzma and libzstd). I might be able to wrangle it into working though.
I could certainly try using autotools again - I haven't used the crate in a while, it may have improved.

the feature is called "bundled" in config and "vendor" in docs, this seems to be a mistake

Ah yeah, I called it vendor originally, and moved to bundled to match what rusqlite calls it. I'll fix the docs.

there's no docs how this interacts with the other crate features
i'd have to look into the details, but there's e.g. a warning about unreachable code in build.rs

Yeah, currently if it's enabled it just disables everything else - hence why the warning about unreachable code. This is mostly placeholder though.

the CI build has not been updated to consider the feature, but fails already

Failure seems to be due to CI not fetching the submodule. It probably needs some adjustment, I'll look into it.

it's unclear to me what this means for Windows platform support e.g. the previous implementation and the vcpkg feature use special versions of the dirent, getopt and tre dependencies which are not bundled/vendored

Yeah, I think for now, documenting this feature as being unix-only would probably be a good idea. The vcpkg build of libmagic is heavily patched. We could reproduce that (either by vendoring a patched version, or taking the patches and applying them in the build script), but it feels like a larger maintenance burden - especially considering it requires a dependency on tre and whatnot.

i'm not entirely sure I want this as a default feature since Rust's SBOM story is quite weak with static C libs, but then again the "vcpkg" feature pretty much is a bundled/vendored static build already. i see how it's more convenient, but I think you'd still have to distribute the default magic database (which is a papercut that cargo isn't really fit to solve anyway)?

So, in my use-case, I don't actually care about the default magic database - I build a custom database at build-time (in a build.rs script) that I then include in the final binary. This is in fact why I'd rather want a static library instead of a dynamic one - I want to make sure the version of libmagic used is the same at compiletime and runtime.
As for whether the feature should be the default or not, I don't mind either way.

I'm not quite sure I follow regarding cross-compilcation; this is easier than building libmagic separately using its original autotools?

I'm working on a rather large project where we cross-compile from linux to linux-musl, macos and windows. To this end, I have a bespoke cross-compilation toolchain with lots of bells and whistles setup to make cc-rs & other build crates "just work", allowing us to build everything from source when we cargo build (including sqlite, boringssl, yara...). This makes it very easy to onboard new people on the project: They just setup the toolchain, clone the repo, and cargo build will build the whole planet and just work:tm:.
Enter libmagic, which does not offer a way to build it as part of cargo build. The only way to make this work (outside of adding the bundled feature as I do here) would be to ship the compiled library as part of the toolchain. This is not ideal for us for two reasons:

It needs to be done separately for each target in the toolchain.
It creates a "hidden" dependency not visible in our SBOM (currently toolchain only provides compiler, crt and libc)

Fair word of warning; I'm afraid the last pull request didn't get much traction since I have an incomplete idea of how this feature should work and am hesistant to merge a partial solution.

That's fair, and I totally understand not wanting to merge a PR without fully understanding its implication - you're the maintainer after all 😄. I personally don't really need this merged upstream - I can use a fork with this PR, so there's no rush. I do think that there would be value in working towards an upstreamable version of this PR, as it'd make libmagic more convenient to use by anyone that already has the cc-rs crate working for their target - instead of requiring some libmagic-specific setup.


text:
Point _set_contour() shouldn't assert None

It seems like this _set_contour() function shouldn't assert None in the first line:
https://github.com/robofab-developers/fontParts/blob/c09c388bacb2bfa70bbad2b3819552506f9e28ea/Lib/fontParts/base/point.py#L70-L74
Removing the first line of the function seems to make it work. However, which situations should someone be able to set a contour in this way? Where on the new contour would/should it add the point? It feels like this entire method should raise an AttributeError.
Thoughts?

I did some digging and this is needed. See the _setContourInPoint method of BaseContour. Are you running into a situation in which that assertion is being raised?

authors: andyclymer typesupply

repo: robofab-developers/fontParts


text:
--kube-context flag does not work

The --kube-context CLI flag does not do anything. Passing in different contexts simply uses the default context. Even passing in a bad context name uses the default. The preview execution that is printed out is clearly not what is actually running.
Example command that will use default context:
$ helmfile --kube-context BAD_CONTEXT_NAME sync
exec: helm upgrade --install test stable/datadog --kube-context BAD_CONTEXT
...

When run manually, helm is able to accept context and apply just like helmfile should:
helm upgrade --install test stable/datadog --kube-context staging --file test.yaml

As you can see helm errors out if passed in a bad context:
$ helm list --kube-context BAD_CONTEXT_NAME
Error: could not get kubernetes config for context 'BAD_CONTEXT_NAME': context "BAD_CONTEXT_NAME" does not exist

This is fixed in v0.6.

authors: AMeng roboll

repo: roboll/helmfile


text:
deps fails on missing globbed files

We have a root helmfile similar to
helmfiles:
- helm/account/helmfile.yaml
- helm/account/{{ .Environment.Name }}/services/*/helmfile.yaml
- helm/account/{{ .Environment.Name }}/teams/*/helmfile.yaml

In some environments some of the above may not exist.  This works fine with helmfile sync, diff, apply etc, but fails for helmfile deps.
Running helmfile from helm/account/prod
in ./helmfile.yaml: no file matching helm/account/prod/teams/*/helmfile.yaml found

Seems like a bug. I'll take a look asap. Thanks for reporting!

@sstarcher Sry I misunderstood this issue. Shouldn't we add missingFileHandler like environments, values and secrets but for helmfiles this time so that it aligns well with the existing behavior of Helmfile?

authors: mumoshu sstarcher


text:
NMPC Solving Fail (Different from #288)

Hi guys,
We're using the Academic version of HSL (with ma57) i've placed the folder in /external/ipopt/
(I do this before running the setup scripts)
I've ensured that npmc_controller.cpp lines 214 and 216 are
app_->Options()->SetStringValue("linear_solver", "ma57");
app_->Options()->SetNumericValue("ma57_pre_alloc", 1.5);

In setup_deps.sh i am using the --latest-release of IPopt.
I had no errors or issues while running the setup scripts, and building.
I also stand the quadruped before running the local planner.
Does anyone know how to resolve this, as it is a different circumstance than Issue #288

I'm currently running ma27, and the NMPC doesn't fail. I would suggest requesting version ma27 from iPOPT and rebuilding. If the error persists, please let me know.

Was this issue solved? If not, try using the devel branch, some IPOPT stuff was resolved there. If that still doesn't resolve it, let us know. It looks like something in the paths isn't lining up right - we may need to update our documentation with a clear statement of what the path to the solver files should be (for reference, quad-sdk/external/ipopt/coinhsl/ma27/ma27d.f should be a valid path, or likewise for ma57 if that is the solver you are using).

Closing this due to inactivity, also it seems likely that the root cause was incorrect HSL paths and clarity has been added to the installation instructions.

authors: andrewhstovell jcnorby ologandavid

repo: robomechanics/quad-sdk


text:
RL2 SignalCommandMap Extension

I wonder if the SignalCommandMap should be enhanced for v2 to include support for named parameters. Regardless, it will need to be re-built as a v2 extension. Here is how the EventCommandMap (currently) integrates with the CommandMap:
https://github.com/robotlegs/robotlegs-framework/tree/b492eb800eaab7f3039c8441061af9d865dd56af/src/org/robotlegs/v2/extensions/eventCommandMap
Creating a CommandMap based extension requires writing 4 files:
A trigger specific API
An implementation of that API
An implementation of the ICommandTrigger API
An extension file for installing the extension

I am gonna push this up to the top of my list. I will also add writing the process up as a tutorial to that list.
Thanks for the poke. :>

Awesome, no rush :)

I have a working implementation here but I am still trying to find the time to get the tests up and running.
https://github.com/pixels4nickels/SignalCommandMap

Going to close this issue here as Signal isn't officially supported yet (it will be once v1 is released, but not until then).
pixels4nickels' implementation looks good but is in need of a test suite.

authors: darscan joelhooks pixels4nickels

repo: robotlegs/robotlegs-framework


text:
Back in February

Heya. I haven't been able to work in this project lately, mostly due to the holidays and now vacation. I should be back to actively contributing in early February.
If you're comfortable with RMStore, I would greatly appreciate if you can respond to issues and help fellow RMStore users.

Welcome back, there are a few pull requests to help you. Also, please review contributors and please add one of them to have commit access here if you can trust them to keep the project moving.

Will do @fulldecent. Any suggestions?

@hpique Yes. I have been reviewing some of these PRs. I will leave a comment on the ones I have reviewed, tested, and can endorse.

Done. There are a lot of good, easy, one-click solutions waiting to happen here!

authors: fulldecent hpique

repo: robotmedia/RMStore


text:
feature request: skip empty translations

Hi!
Another request :)
It would be great if empty strings can be skipped when pulled (with e.g. a --skip-empty argument). For me, these are "untranslated", but because they are pulled as an empty string my app thinks its translated and displays that empty string.
Not sure if the underlying API package permits that.

Hi
I'm not sure if this is something I want to add as this is kind of a hack. Personally, I would use Loco tags or flags to denote untranslated assets. We can then maybe filter on tags when pulling.

I agree, filtering on tags / flags would be more beneficial.

repo: robrechtme/loco-cli


text:
adiçao do match para o envio de mais de um verbo HTTP em uma rota

Ao trabalhar com o CoffeCode/Router senti falta de poder ter uma rota que aceite mais de um verbo HTTP, então fiz uma pequena adição no seu código, com o método match agora agora se é passado em um array os verbos http que deseja aceitar, a rota ao usar o metodo match fica assim:
$router->match(['post','put'], '/', 'HomeController:index');
Espero poder ajudar mais pessoas com esta pequena alteração.
Parabéns pelo incrível trabalho que tem feito, sou muito fã do seu canal no YouTube.

Olá terriane, me coloque um exemplo de uso prático da necessidade de tal método por favor. Não vejo como uma boa telo :/

authors: robsonvleite terriani

repo: robsonvleite/router


text:
Env Var Problem with Webpack

In production webpack does not provide the declared env vars made available to it failing the cloudinary widget. In development it runs fine.

Coverage remained the same at 85.606% when pulling 87817c0844e76dd3fd0ea34733abe230b755c1cd on issue into 2b6d1a23be2a2d0faa42b55f2ae724479a0d9cd2 on beta.

Coverage increased (+1.4%) to 87.05% when pulling 94938e91c1af3630d1f8c26e6604ada26d863525 on issue into 2b6d1a23be2a2d0faa42b55f2ae724479a0d9cd2 on beta.

authors: coveralls rockchalkwushock


text:
Can't find TestRoutine in TestCase

This error appears when TestRoutine can't be recognized in TestCase
TestCase

TestRoutine (in subfolder)

Can't reproduce anymore.  I tried to change the name of a test routine in Windows Explorer and it was correctly updated in the IDE

repo: rockmelonqa/rockmelonqa-ide


text:
object detection: identifying a not-configured model?

config.yaml snippet:
object_detection:
  type: darknet
  interval: 1
  logging:
    level: DEBUG
  labels:
    - label: person
      confidence: 0.5
    - label: bicycle
      confidence: 0.6
    - label: car
      confidence: 0.6
    - label: truck
      confidence: 0.6
    - label: motorbike
      confidence: 0.6
    - label: bird
      confidence: 0.5
    - label: cat
      confidence: 0.5
    - label: dog
      confidence: 0.5

and in the logs I noticed this, but haven't been able to recreate:
[2020-09-27 23:34:52] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.517, 'rel_width': 0.057, 'rel_height': 0.164, 'rel_x1': 0.772, 'rel_y1': 0.632, 'rel_x2]
[2020-09-27 23:35:13] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.524, 'rel_width': 0.068, 'rel_height': 0.181, 'rel_x1': 0.781, 'rel_y1': 0.627, 'rel_x2]
[2020-09-27 23:35:51] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.53, 'rel_width': 0.139, 'rel_height': 0.267, 'rel_x1': 0.736, 'rel_y1': 0.589, 'rel_x2']
[2020-09-27 23:35:55] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.543, 'rel_width': 0.058, 'rel_height': 0.156, 'rel_x1': 0.769, 'rel_y1': 0.635, 'rel_x2]
[2020-09-27 23:36:05] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.536, 'rel_width': 0.134, 'rel_height': 0.257, 'rel_x1': 0.736, 'rel_y1': 0.589, 'rel_x2]
[2020-09-27 23:36:13] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.546, 'rel_width': 0.058, 'rel_height': 0.159, 'rel_x1': 0.767, 'rel_y1': 0.637, 'rel_x2]
[2020-09-27 23:36:17] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.623, 'rel_width': 0.058, 'rel_height': 0.147, 'rel_x1': 0.769, 'rel_y1': 0.644, 'rel_x2]
[2020-09-27 23:36:19] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.543, 'rel_width': 0.058, 'rel_height': 0.158, 'rel_x1': 0.769, 'rel_y1': 0.635, 'rel_x2]
[2020-09-27 23:36:31] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.574, 'rel_width': 0.058, 'rel_height': 0.156, 'rel_x1': 0.769, 'rel_y1': 0.637, 'rel_x2]
[2020-09-27 23:36:33] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.626, 'rel_width': 0.056, 'rel_height': 0.158, 'rel_x1': 0.769, 'rel_y1': 0.635, 'rel_x2]
[2020-09-27 23:36:35] [lib.nvr.cam02.object    ] [DEBUG   ] - Objects: [{'label': 'tie', 'confidence': 0.503, 'rel_width': 0.056, 'rel_height': 0.161, 'rel_x1': 0.769, 'rel_y1': 0.635, 'rel_x2]

I am definitely not interested in finding ties, I have no mention of tie anywhere in my setup, but I know it's one of the EdgeTPU modules in the image.
What's caused this? Is it a feature or a bug?

just got another one, this time skateboard:
[2020-09-28 15:09:39] [lib.nvr.cam05.object    ] [DEBUG   ] - Objects: [{'label': 'skateboard', 'confidence': 0.217, 'rel_width': 0.242, 'rel_height': 0.229, 'rel_x1': 0.51, 'rel_y1': 0.163, 'rel_x2': 0.752, 'rel_y2': 0.392}]

All objects that the detector sees will be printed by that debug statement.
The detected objects are then run through the filter of label, confidence and size.
Can probably clarify this with two statements, one listing all objects and one listing filtered objects

ahh, very cool. I didn't know it did that.  I don't know that anything needs to be clarified further than that.

I'll just add a note to the README

Hm, I wonder if it wouldn't be better to have a separate config entry for that. It is quite noisy.  Perhaps something like log_all: true under object_detection?

Will do!

authors: akohlsmith roflcoopter

repo: roflcoopter/viseron


text:
Programmable Voice SDK

Twilio has released a new Beta SDK for VOIP
https://www.twilio.com/docs/api/client/android
and published a message on the Client SDK pages:

Please note that the Twilio Client Android SDK is superseded by the newer Twilio Programmable Voice Android SDK, which uses GCM push notifications for signaling incoming calls.

I started making some experiment using their quickstart app: https://www.twilio.com/docs/api/voice-sdk/android/getting-started
With the new implementation I am able to receive calls even when the app is not in memory or killed. It used GCM and also it worked for me using FCM.
If somebody knows about a repo that already wrapped this feature in React-Native please share.

That's awesome. I was sending my own Apple Push Notifications from my Server to do the same kind of thing. I wonder if they'll update the iOS version?

I am experimenting with this module: https://github.com/hoxfon/react-native-twilio-programmable-voice
Please feel free to have a look and contribute. Some help for the iOS part is certainly very welcome.

@rogchap
I pushed the very first Android library version on npm (react-native-twilio-programmable-voice). So far it implements the basic functionalities and I haven't got any crash. I can make and receive calls, when the app is opened, in the background and completely closed.
I was wondering if you or somebody else would like to give a hand with the iOS implementation.

It looks like there is an iOS version https://www.twilio.com/docs/api/voice-sdk/ios

@sprice the job is to wrap the Twilio code in a react native module, with all the JavaScript bindings.
The Twilio lib is a good starting point for inspiration.
I am still looking for help if someone wants to contribute.

@fabriziomoscon sorry for not being clear. I was simply responding to @rogchap who asked "I wonder if they'll update the iOS version?" 😄

authors: fabriziomoscon rogchap sprice

repo: rogchap/react-native-twilio


text:
Suppress Stack Traces

Hi,
For several production web apps I have, we're cleaning up the logs.  Lograge has been helpful in that.  However, stack traces are still being dumped.  We have gems like Honeybadger to handle exception reporting, so the stack trace just clutters the logs especially since the error message is included in the lograge output.
After doing a little searching, I couldn't find an obvious way via rails configuration to turn off the stack trace logging.  Even removing the action_dispatch.logger doesn't work, because it fails over to stderror.  The best I could come up with was to monkey patch ActionDispatch::DebugExceptions to disable the stack traces.
Is there a better approach?  Thanks.

@sallustfire Sadly not at this juncture. This is something I'm looking into at the moment, but will require some rework to achieve. I'm going to try and document an approach that works as-is for now, so hopefully I'll have something up over the next few days.

I appreciate it.  I'm happy to provide a pull request if we can articulate a viable long term solution.

Any update on this or found a better solution?

authors: benlovell bhushan-ahire sallustfire

repo: roidrage/lograge


text:
"inFile" option?

It would be nice to be able to use the nice features of roku-deploy using a pre-packaged app, like:
roku-deploy -infile bin/app.zip -host 1.2.3.4 -password abc

Even using the internal JS API it isn't easy to achieve.

Related to (and will be addressed by ) #161

authors: TwitchBronBron elsassph

repo: rokucommunity/roku-deploy


text:
GitHub Issue #206: Bug in DataBuilder reversing frames

rollbar expects most recent call to be last, not first - this was lost somewhere in development of 1.0.0. This PR brings back the expected order of frames as requested in #206

Ready for review

LGTM

👍  We will need to note this in the changelog; for anyone upgrading from 1.x, this will cause their events to be fingerprinted differently by Rollbar.

Good point, it will restore the fingerprints from <= 0.18 but be different than >= 1.0.0 until this is released

authors: ArturMoczulski brianr rokob

repo: rollbar/rollbar-php


text:
Receiving sms messages

Hey dude!
How can I receive sms with your app?

In the only environment I'm using it (with a cell phone in France), it has been working since the beginning and it's still working now.
However it hasn't been built to fit every possible need just my personal ones which aren't very wide (just 2 routes).
Given the following sample minimal configuration:
gsm-modem:
  port-name: COM1
sms-routing:
  sms-routes:
  - prefix: foo
    endpoint-url: https://bar/sms

When a SMS is received, if its text starts with the prefix foo, then it will be "routed" to https://bar/sms otherwise it will be ignored.

authors: romainmoreau thmspl

repo: romainmoreau/gsm-modem


text:
gitter badge

Merge from dlthread to dev for gitter badge

I don't prefer merging from web interface as this always creates a new commit, but you could use this if you are uncomfortable with the command line.