Plugin's config can't be reloaded.

Is there possibility to reload config of plugin without restart emqttd?
Load/Unload of the plugin is not applying new configuration file.

Hi, you could update the app.config directly.
The app.config is the config file that is converted from the emq.conf and the configs of your plugins. The app.config is then used by EMQ directly.
For example in my Mac there is a running emq, and following is the process info:
$ ps -ef | grep beam

501  4422  4420   0  8:41下午 ttys002    0:01.41 /Users/emqer/code/emq-relx/_rel/emqttd/erts-9.3/bin/beam.smp -W w -e 256000 -Q 65536 -P 256000 -A 32 -K true -zdbbl 8192 -- -root /Users/emqer/code/emq-relx/_rel/emqttd -progname Users/emqer/code/emq-relx/_rel/emqttd/bin/emqttd -- -home /Users/emqer -- -boot /Users/emqer/code/emq-relx/_rel/emqttd/releases/2.3.5/emqttd -mode embedded -boot_var ERTS_LIB_DIR /Users/emqer/code/emq-relx/_rel/emqttd/erts-9.3/../lib -mnesia dir<EMAIL_ADDRESS>-config /Users/emqer/code/emq-relx/_rel/emqttd/data/configs/app.2<IP_ADDRESS>.41.16.config -kernel net_ticktime 60 -smp auto -setcookie emqsecretcookie -proto_dist inet_tcp -name<EMAIL_ADDRESS>-vm_args /Users/emqer/code/emq-relx/_rel/emqttd/data/configs/vm.2<IP_ADDRESS>.41.16.args -- console

You would notice the -config /Users/emqer/code/emq-relx/_rel/emqttd/data/configs/app.2<IP_ADDRESS>.41.16.config argument of the command line, which shows which config file it uses. Let's check the content of this file, jump the emq_auth_http section:
$ cat /Users/emqer/code/emq-relx/_rel/emqttd/data/configs/app.2<IP_ADDRESS>.41.16.config

...
{emq_auth_http,
     [{auth_req,
          [{url,"http://<IP_ADDRESS>:8080/mqtt/auth"},
           {method,post},
           {params,[{"clientid","%c"},{"username","%u"},{"password","%P"}]}]},
      {super_req,
          [{url,"http://<IP_ADDRESS>:8080/mqtt/superuser"},
           {method,post},
           {params,[{"clientid","%c"},{"username","%u"}]}]},
      {acl_req,
          [{url,"http://<IP_ADDRESS>:8080/mqtt/acl"},
           {method,get},
           {params,
               [{"access","%A"},
                {"username","%u"},
                {"clientid","%c"},
                {"ipaddr","%a"},
                {"topic","%t"}]}]}]}
...

Now you can update this section and reload your emq-auth-http plugin again. In this method it is not necessary to restart you entire emq.
Reload the configs at the runtime is still possible, but this feature is not planned in the coming versions.

The plugin configuration has been modified in emqx-3.1-beta.1, and the reload plugin takes effect.
$ ./bin/emqx_ctl plugins reload emqx_auth_http


Change alternate style for .jsx / .tsx filetypes

Changed based on following solution to have comments in jsx / tsx: https://github.com/scrooloose/nerdcommenter/issues/280#issuecomment-395566184
I would prefer this to be the default option. Just thought I'd leave this here :)

I'm quite willing to accept a stand in ad-hoc filetype if we need to, but given there is a response from the primary vim maintainer on this issue I think I'll hold off a few mare days at least in case we actually get a bonified standard filetype added upstream.

@alerque seems we got javascriptreact and typescriptreact accepted https://github.com/janlazo/neovim/commit/f667a0e02ac5781a7b7e640b5dc9a7edcf2f4a0b 🎉.
It might still be a good idea to also keep javascript.jsx and typescript.tsx until other filetype-specific plugins adapt to the change. I'll update the PR if you want me to.

That's awesome @impulse thanks for seeing that process through.
If we had the hack for the dot*sx variations released I would say wait to pull it out until at least the next major release cycle on Vim/Neovim, but since we dot't have it it place yet and many React folks will already have their configs tweaked anyway, I think I'd like to just add the final filetype values to this plugin. I don't see any need to perpetuate what is going to be a dead filetype.
Can you rework this using javascriptreact and typescriptreact? It might not hurt to add a note in the docs / readme about why we chose that for React support.
As for any other plugins that use the dot*sx filetypes lets encourage them to at least add a mapping to the now official filetype and start porting people that have adopted the old hack over.

Gotcha, updated for the official vim filetypes then.
I am not a native speaker but a possible explanation for the docs could be:
React: Commenting within your jsx or tsx markup requires comments to be wrapped in curly braces.
Thus vim's official javascriptreact and typescriptreact filetypes will use a different alternative set of delimiters.


windows: on_update_resources stuck because controller channel is full

Known design flaw in my code, I'll look into it.

#2960 will fix this

Fixed on main since #2960 was merged.


Filter for speaker

Hey,
being a newbie to DataFrames.jl and JuliaCon.jl, is there a simpler way to show all talks of a speaker than
julia> filter(row -> any(contains.(row.speaker, "Julia")), JuliaCon.get_conference_schedule())
4×7 DataFrame
 Row │ start                      duration    title                              speaker                ⋯
     │ ZonedDat…                  Compound…   String                             Array…                 ⋯
─────┼───────────────────────────────────────────────────────────────────────────────────────────────────
   1 │ 2021-07-20T14:00:00+00:00  3 hours     GPU programming in Julia           ["Tim Besard", "Julian ⋯
   2 │ 2021-07-29T17:15:00+00:00  45 minutes  GPU programming in Julia BoF       ["Tim Besard", "Julian
   3 │ 2021-07-30T13:00:00+00:00  30 minutes  Easy, Featureful Parallelism wit…  ["Julian P Samaroo"]
   4 │ 2021-07-30T13:40:00+00:00  10 minutes  BPFnative.jl: eBPF programming i…  ["Julian P Samaroo"]
                                                                                4 columns omitted

Thanks,
Felix

Looks reasonable to me. There is no dedicated JuliaCon "feature" for this.

Is it a feature we should include?
If yes, I can create a PR

Why not, sounds good to me. Maybe as JuliaCon.talks_by(speaker)? Would be great though if you could align the print format with what we have for JuliaCon.now() or JuliaCon.today().

OK, I'll see how tricky that is :)

In https://github.com/JuliaCon/JuliaCon.jl/commit/292353507fd1afe8ddd5197b3923b981d2b4c14d I've added the following:
julia> JuliaCon.talksby("Carsten Bauer")

Wednesday 26 July 2023, 17:40 in 32-082
	Pinning Julia Threads to CPU-Cores with ThreadPinning.jl (Lightning Talk)
	├─ Carsten Bauer
	├─ https://pretalx.com/juliacon2023/talk/MBS3YY/
	└─ Julia Base and Tooling

Thursday 27 July 2023, 16:30 in 32-G449 (Kiva)
	Julia for High-Performance Computing (Minisymposium)
	├─ Carsten Bauer, Michael Schlottke-Lakemper, Johannes Blaschke et al.
	├─ https://pretalx.com/juliacon2023/talk/PC8PZ8/
	└─ HPC

Friday 28 July 2023, 21:00 in 32-144
	Julia in HPC (Unknown)
	├─ Carsten Bauer, Valentin Churavy, William F Godoy
	├─ https://pretalx.com/juliacon2023/talk/NKVYHZ/
	└─ HPC

(Shown times are in the following time zone: MET)

Great!


loadSchema is called 2 times for the same refferenced schema

UPDATED:
What version of Ajv are you using? Does the issue happen if you use the latest version?
Version 6.10.2
Ajv options object
{
loadSchema: loadExternalSchema
}
function loadExternalSchema (uri) {
	return jQuery.ajax(uri)
	     .then(function (res) {
                        ...
			return res;
	    });
}

JSON Schema
"allOf": [
	{ "$ref": "http://adaptivecards.io/schemas/adaptive-card.json#/definitions/AdaptiveCard" }
]

When trying to create Ajv instance, loadSchema function is being called 2 times for adaptive cards' schema.  I cannot afford to make 2 ajax calls for the same refferenced schema. How can I avoid that?

Please post a simple code sample that shows the issue, ideally to runkit.com (IO call can be mocked in the same way as the tests do it).

@epoberezkin
I found hard times when trying to isolate it in JSFiddle. In the JSFIddle, however I have used
Promise.resolve({...})

instead of
return jQuery.ajax(...)

inside the "loadExternalSchema" function. In the end I discovered that the problem is coming from jQuery. If I use
return Promise.resolve(jQuery.ajax(...)) then there is only 1 request made.

I consider this as resolved, hence you can close the issue.

It looks like some race condition - it would be good to replicate it anywhere and fix...
Wrapping it in promise changes timing, so the race condition doesn't occur, but it still means there is some bug/logical error somewhere that makes it happen.
If you could share any size code sample reproducing it - it would be great.


Kafkatest client [WIP]

And various fixes for problems found implementing the kafkatest client.
Currently only includes the VerifiableProducer, the consumer part will be added later to this PR.
The premature push is to allow review of core client changes, rather than the VerifiableProducer (so ignore that part for now).

Aside for it's use in KafkaException, where do you need to associate a custom string with an ErrorCode?

Re error strings: search rdkafka.h for errstr  to see the APIs that currently provide richer errors.
https://github.com/edenhill/librdkafka/blob/master/src/rdkafka.h
Plus the error_cb.
https://github.com/edenhill/librdkafka/blob/master/src/rdkafka.h#L1142

Ok, so we potentially need a custom reason string in the error callback and in places that will map to exceptions.
I see why you like having the Error class in this PR - it can be used as the basis of KafkaException and in the OnError event. Both are important and need Code+CustomString together, so it seems natural that the thing we call Error should be that. Still, I'm not convinced we've nailed this quite yet.
My primary concern is avoiding an extra 8 bytes in every delivery report, where this seems easily avoidable. One solution is to change Message to include ErrorCode (not Error), but that's less convenient to the user and it's in a place that I think will come into play often.
Alternatively, the error event delegate could provide an ErrorCode and a Reason (not encapsulated in something else) and KafkaException can remain as is. When I implemented OnError, I was anticipating probably having to change it to this, because I thought there might be custom reason strings there (see my todo).
Error (as I have it) is effectively ErrorCode ++ some zero cost syntactic sugar that allows easy access to the associated human readable text. This pattern is actually slightly a-typical - I don't know where else I've seen something similar (though I think it works quite well). That's probably the primary reason I I'm not completely locked to it. Having ErrorCode in Message + static method on Error may make me happy.

I hear you and I agree that we want to keep the size/object creation cost down for the fast path (which exceptions are not, but Message is).
But we need to make this decision based on real numbers, so we'll need performance benchmarks for the following Message error alternatives:

Message.ErrorCode
Message.Error
Message.Nullable

My preference would be: 2, 3, 1

I think i've finally put my finger on the core thing thats irking me here:
We have the concept of an error code and we have a method which can be used to get a message associated with that error code. There is a 1:1 mapping between these two.
Additionally, sometimes, a different message can be passed along with an error code. This is a different kind of thing.
Having an Error class where the message is either the 1:1 mapping, or some other arbitrary string is not clear modeling of ideas.

it's potentially confusing in fact.

Having the capability to hold an arbitrary thing in a place (Message) where no such arbitrary thing is ever going to be put does not gel well with me.
[any efficiency gains are side benefits to getting the modeling correct]

I'm not really buying into models and principals, at the end of the day there are two people we need to help out as best as we can: the application developer and its end-user. The better information we can provide for both of them, the more succesful they will be, and consequently us.
A error serves two purposes:

let the developer handle the error programmatically (error code)
inform the end-user what's up (error string)

I don't see the problem of composing those two things in the same construct, they're two sides of the same coin, two facets of the same thing.
If the error string is sometimes richer than a simple static err2str mapping then I'd say that is great for he end-user, it'll help them sort out what's wrong.
So, is putting an error string in the Message.Error field wasteful?
I'd say no, because most Message handling code will eventually look like this:
 if (!msg.Error)
    return handle_the_msg(msg);
 switch (msg.Error.Code)
 {
     case SomethingIKnowToHandle:
        dostuff();
        break;
     case SomethingElseIthinkIknowtoHandle:
       dootherstuff();
        break;
     default:
       log_to_enduser("Couldn't handle errored message at {msg.TopicPartition] offset {msg.Offset}: {msg.Error});
       break;
}

Thus, a developer will never care what the error string for an error is, because it is never programmatically used, all she wants is proper error propagation to a human.
Here are a couple of examples of rich Message errors:
https://github.com/edenhill/librdkafka/blob/master/src/rdkafka_broker.c#L3773
Compare:
"Unsupported codec" to "Unsupported compression codec 0x%x" - even though this is mildly helpful it at least gives a technically savvy person a chance to know what codec isn't supported.
https://github.com/edenhill/librdkafka/blob/master/src/rdkafka_broker.c#L4172
Compare:
"Message too large" to "Message at offset .. too large"
https://github.com/edenhill/librdkafka/blob/dcfc3ed789d450195189502f7a5ec48b2dd643b7/src/rdkafka_cgrp.c#L941
Compare:
"Illegal generation" to "Failed to Join group: Illegal generation"
https://github.com/edenhill/librdkafka/blob/bbee686594d009a078758cba7070dbb3964f771c/src/rdkafka_partition.c#L1900
Compare:
"Not coordinator for group" vs "Failed to fetch offsets from brokers: Not coordinator for group"

Maybe we could convert some of these errors into TopicPartitionOffsetError's perhaps and have its own onConsumerError for them

Yeah - the end user should be able to get the better error message if there is one - of course don't want to limit that. Also, maybe those custom errors are close enough to being the same as the 1:1 mapping that the argument in my previous comment isn't that strong. Still, in Message, they are 1:1 and it's still dominating my thinking.
A negative on the Error class as I have it is it's just a wrapper of ErrorCode and this may not 100% future proof for something with the name Error. Extending it at all breaks the concept.
I just realized something - you can put extension methods on Enums:
https://msdn.microsoft.com/en-us/library/bb383974.aspx
That means we could put an ErrorCode in Message, and also define an extension method which calls  err2str.

That's currently doing it for me - keep the Error class as you have it but put ErrorCodes in Message (which will have a convenient method on them to get the err2str string via an extension method).

Actually I wanted to re-open the discussion on whether we want to break out the OnError event into consume and other errors again. We decided they should be joined before, but I feel like I don't have a good opinion on that currently. Just wanted to ask the question again.

@mhowlett I can't seem to reply to the above thread on Message.Error, but to follow up:
There are two big concerns with decoupling the rich error from the Message:

the rich consumer error will most likely need to use a TopicPartitionOffsetError to provide context. Do we want to add that to the Error type (as a Nullable)? Add a OnConsumerError? or just keep the Message.Error as today since there is a Message.TopicPartitionOffsetdo we want that as an optional on the OnError?
sequenciality: separating in-stream error messages from OnMessage means that ordering is lost. E.g., you can get the delegate for a later message before the On*Error. I don't have a specific case where this is bad but I'm quite sure there will be problems in some use-cases doing this.

Firstly, currently no context is provided with consume errors - this needs to be rectified, yes (I hadn't yet got to thinking this through thoroughly).
Regarding sequentiality: events for consumer errors and messages are fired in order (ordering is not lost). It's possibly confusing that consumed messages are spread over two event handlers - and probably definitely confusing that one of these events can also be fired as a result of something other than a consumed message with error. For that reason I'm now against the idea of consumer errors being exposed via OnError along with other errors. Either we have OnConsumerError or they should go to OnMessage.
If we have OnConsumeError, we could simply provide a Message to the event rather than invent a new type - it contains everything we need, and it maps to what's happening under the covers.
A benefit of having an OnConsumeError is we're effectively helping people write their message handling logic. I'm guessing it's probably going to result in slightly cleaner implementations. The downside is it's possibly more confusing to new users - it sort of assumes working knowledge of closures / comprehension that everything happens on the same thread / realizing ordering is guaranteed between the events. I don't have a strong opinion here, but currently I'd err slightly on the side of OnConsumeError.
rd_kafka_message_t doesn't have a rich error message. rd_kafka_topic_partition_t also doesn't have a rich error message (unless i'm missing something?). I still can't see a good reason to have something richer than ErrorCode in Message or TopicPartitionOffsetError. An extension method on ErrorCode that calls through to err2str still seems to me like it'll do everything we need and be an abstraction that is unlikely to break or cause problems in the future.
I think we probably do want an abstraction for a rich error (and it can be called Error), but this is applicable to OnError and KafkaException.

rd_kafka_message_t doesn't have a rich error message.

Actually it does: payload doubles as error string in consumer mode when err is non-zero, see here:
https://github.com/edenhill/librdkafka/blob/master/src/rdkafka.h#L832
I posted a couple of examples where the errors will be richer than a simple error string, see earlier in this thread, please see https://github.com/confluentinc/confluent-kafka-dotnet/pull/38#issuecomment-277339909 again

Ok, I hadn't understood that - this changes everything.

Given this, I think Message should have Error as you define it, as you suggest.
What about rd_kafka_topic_partition_t? there is no rich error message there right? in that case I probably still think we should only have ErrorCode in that.

Correct, topic_partition_t has just the error code (it is mapped very closely to the underlying Kafka protocol which does the Topic,Partition,Error tuple frequently).
I agree that ErrorCode is technically sufficient on TopicPartition, but I'm wondering if that spills implementation details out into the public API and making it harder to use? Some types have ErrorCode, other have Error, ..
I'd rather see Error used consistently everywhere, and from the user's perspective they want both the error code and error string as described above.
Since errors are part of the slow-path I would suggest that we make Message.Error a Nullable, or whatever it is called, e.g., not allocated at all if there is no error.

Yep, I think it makes sense to make Error a class (meaning it's heap allocated). It can then have a value of null without wrapping it in Nullable. In the normal case of no error, this gets set to null - so cost per message in the normal case is size of a reference + there is no heap allocation except in case of error. I like it.
I'm currently not sure about Error vs ErrorCode in TopicPartitionOffsetError. Erring on the side of your thinking is probably right.

I'm going to take the liberty of merging this even though not completely LGTM yet as i want test these changes on windows and rebase + fix conflicts on other PRs.
List of things remaining to fix up:

CommitAsync cancellation
Superfluous OnOffsetsCommitted in AdvancedConsumer example
Various linting related things
GetMetadata method signature
TimeSpan Flush variants

We can do the above in later PRs.


CSCFAIRMETA-244: Allow editing/fixing deprecated datasets in Qvain Light

Show message in top of editor for deprecated datasets.
Below the message, show button that shows modal for fixing the dataset.
Dataset fixing modal uses Metax RPC for fixing deprecated datasets.
Remove metadata editing buttons from dataset files/directories that have been removed.
Fix: Bug from not taking into account that removed files/folders don't have details.
Refactor: Use reusable response error handler function to make displaying errors more reliable.

Fixed linting errors.


Hi Sir,

I get failures when I use your project to recompile.
My segger version is 6.30.
Have you run into the same problem? Thank you

Really thank you for your reply and solved for now.


⚠ File access has degraded performance

In f134a90, File access (https://fyle.uk/file/fish) experienced degraded performance:

HTTP code: 200
Response time: 4246 ms

Resolved: File access performance has improved in 389fe19.


libp2p blocking fails at syncing

⚠ Support requests in an issue-format will be closed immediately. For support, go to Swarm's Discord.
Context

I'm testing out GSOC functionality which uses fdp-play for environment (5 nodes network).
Related logs
"time"="2024-09-20 14:29:32.265097" "level"="debug" "logger"="node/libp2p" "msg"="blocklist: could not blocklist peer" "peer_id"="Qmexzx5TQexfw1zeNsr3zPX8wPEqTfAVSAzxZN29urfEdD" "error"="cannot blocklist peer when network not available"
"time"="2024-09-20 14:29:32.265113" "level"="error" "logger"="node/libp2p" "msg"="unable to blocklist peer" "peer_id"="Qmexzx5TQexfw1zeNsr3zPX8wPEqTfAVSAzxZN29urfEdD"
"time"="2024-09-20 14:29:32.265122" "level"="debug" "logger"="node/libp2p" "msg"="handle protocol failed" "protocol"="pushsync" "version"="1.3.0" "stream"="pushsync" "peer"="
676790fcae312292ffc17b7f7c84d5b9acc51ef0ea3f27d0ff3bada3362abc5d" "error"="unexpected request while in light mode"
"time"="2024-09-20 14:29:32.265239" "level"="debug" "logger"="node/libp2p" "msg"="blocklist: could not blocklist peer" "peer_id"="QmdRzETjLwPReW134dbG9hfCure8RELWTESyfQpeG3iCm7" "error"="cannot blocklist peer when network not available"

also at pull sync
"time"="2024-09-20 14:54:48.866819" "level"="debug" "logger"="node/libp2p" "msg"="blocklist: could not blocklist peer" "peer_id"="QmdRzETjLwPReW134dbG9hfCure8RELWTESyfQpeG3iCm7" "error"="cannot blocklist peer when network not available"
"time"="2024-09-20 14:54:48.866854" "level"="error" "logger"="node/libp2p" "msg"="unable to blocklist peer" "peer_id"="QmdRzETjLwPReW134dbG9hfCure8RELWTESyfQpeG3iCm7"
"time"="2024-09-20 14:54:48.866876" "level"="debug" "logger"="node/libp2p" "msg"="handle protocol failed" "protocol"="pullsync" "version"="1.4.0" "stream"="cursors" "peer"="48013b5c5142e482759f08ef60057b4bbb7cb2e77790b44e3f06b235493347d4" "error"="unexpected request while in light mode"

Summary

Even though swarm-cli status gives back Mode: full - as expected based on the Bee configuration as well -, libp2p assumes it as a light node.
It tries to blocklist peers but it cannot and refers to some network availability issue.
Eventually, the chunks push seems successful since the API request returns with 201.
Expected behavior

Bee does blocklist when it wants to.
Actual behavior

It fails blocklisting.
Steps to reproduce

Run FDP Play and push chunks.
Possible solution

The linked PR fixes the blocklist issue but the "unexpected request while in light mode" error is expected.
The queen node is bootnode mode.
bee printconfig from the docker container returns
# cause the node to always accept incoming connections
bootnode-mode: "true"

When in bootnode mode (or light mode), bee will replace the p2p stream handlers with an always erroring handler. (error above)
https://github.com/ethersphere/bee/blob/0e42d83eecfbeaa764ee8004ea402b78b8293147/pkg/node/node.go#L974-L984
You can also see this from the logs
"level"="info" "logger"="node" "msg"="starting in light mode"


Merge StashCache/HDFS test params

This adds upgrade tests for HDFS tests and removes dev tests for StashCache

I kicked off a VMU test run with these params


"Consuming" functions

Calling them Consume is probably not a good idea since that kind of implies it could only be done once. Instead, Do might be a better name.
Since the signature(s) doesn't require type parameter, this could even be done as (a) member function(s). For symmetry, it'll probably best to at least have free versions, as well.
I.e.
func Do(R[T], func(T)) error
func DoE(R[T], func(T) error) error

Kind of corresponds to fmap / bind without a result value... We might also want to do the same for Zip...
Then we could do stuff like
f := result.Wrap(os.Open("foo"))
defer result.DoE(f, func(f *os.File) error { f.Close() })

or use it to consume results at the end of a computation like in example_test.go:
out := result.ZipE(of, cnt, writeCountsSorted)
if _, err := out.Unwrap(); err != nil {
	log.Fatalf("%v", err)
}
fmt.Printf("%s", buf.String())

vs.
if err := result.ZipConsume(of, cnt, writeCountsSorted_); err != nil {
	log.Fatalf("%v", err)
}

Calling them Consume is probably not a good idea since that kind of implies it could only be done once. Instead, Do might be a better name.

The functions do however produce a return value that is no longer an R[T] so in that sense, they get consumed...

For now, the free versions should be enough.


Ctrl C in integrated terminal

It is a common practice to escape the command in any terminal by Ctrl + C. I know there are a few threads discussing this issue already. However, I found that the solution provided by parkovski (https://github.com/Microsoft/vscode/issues/9347) can fix this problem, simply replace winpty-agent.exe. It would be great if the vscode can include this fix officially.

Please don't create duplicate issues, there is even a recent update on the issue you linked from.


[BEAM-7747] Close the file handle owned by fastavro.write.Writer in _FastAvroSink.close().

Currently, _FastAvroSink.close() calls flush() method on FastAvro writer, which does not close the file handle: https://github.com/fastavro/fastavro/blob/53ed64d95d4f82875d1238b1f76d4d87547e40e1/fastavro/_write.pyx#L548. On Windows platform, the temporary output file created by the sink cannot be accessed until it is closed.

Run Python 2 PostCommit

Run Python 2 PostCommit

Run Python 3.5 PostCommit

Run Python 2 PostCommit

We need to re-run postsubmits after https://github.com/apache/beam/pull/9122 is merged.

Run Python 2 PostCommit

Run Python 3.5 PostCommit

Run Python 2 PostCommit


Node.js YouTube Channel Name

Just getting things started here.
First thing, I'd like to improve is if we can have a channel name for Node.js
Right now it is:
https://www.youtube.com/channel/UCQPYJluYC_sn_Qz_XE-YbTQ

We can move to nodejs channel name.
https://www.youtube.com/channel/Nodejs

@bnb can you share how I can help with this? I'd need to get in touch with whoever manages the YouTube channel or get the admin control so I can add a Channel name.
Looking forward!

we currently have http://youtube.com/nodejs-foundation as an YouTube alias for the channel, but we should likely change that since that won't be a real thing anymore. I spent some time yesterday looking for how to change this but couldn't find a way, though it should be possible.

Keep in mind that if we change it we may break a bunch of canonical urls
On Fri, Mar 29, 2019, 9:55 AM Tierney Cyren<EMAIL_ADDRESS>wrote:

we currently have http://youtube.com/nodejs-foundation as an YouTube
alias for the channel, but we should likely change that since that won't be
a real thing anymore. I spent some time yesterday looking for how to change
this but couldn't find a way, though it should be possible.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/outreach/issues/5#issuecomment-478006403, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV8kagd0yQqz87oj2xy4Mh7IzpkGpks5vbhtrgaJpZM4cQuu0
.

Seems to have been fixed. So, I'll just close this one.


Controller Area Network (CAN) Take 3

Usage Example
stm32-fwupdate
Prototype Implementations

pcan-basic on top of an existing software API
stm32fxx-hal (diff) as part of a HAL crate
candev implementing the traits for linux SocketCAN

TODOs for seperate PRs

Postpone merge FilteredReceiver and associated traits ref (open a new PR without them)
Investigate support for UAVCAN requirements

RX and TX timestamps
Transmission deadline

Common interface to set bit timings ref

Previous Discussion

[WIP] CAN Interface take 2 #77
CAN/CAN-FD API? #21
added a HAL for CAN interfaces #53

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @thejpster (or someone else) soon.
If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.
Please see the contribution instructions for more information.

Hey! I am just dropping by I am taking up Rust and I was thinking that I would do CAN layer for embedded-hal since I have quite some encounter with CAN on embedded, but I see I come a bit late.
But now looking at it I was thinking wouldn't it make sense to have some generic timing structure akin to what is in Linux kernel:
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/can/netlink.h#L31
namely structs can_bittiming and can_bittiming_const
The idea is that struct as can_bittiming is generic description of timing settings of a CAN hardware and can_bittiming_const defines the capability of given driver.
While I would not add implementation to calculate struct can_bittiming in rust-hal I think it makes sense to have trait that allows you to set generic timing and get the timing capabilities from CAN hardware.
If this is not done then setting timing will be a a bit bypass of HAL layer because the values are specific for each CAN IP core..
I saw that timing was discussed before, but is a bit different way of doing it.. its not implementing anything directly, only defining the interface common to both CAN driver and an application siting on top of embedded-hal this way the drivers can provide concise way to show timing capabilities while application layer can use those to set the timing.

I added traits for receive filter configuration. There is quite some variation between CAN controllers:

Not all filters have a mask
A shared mask for multiple filters (MPC2515)
Some controllers only support standard 11bit identifiers (STM32 bxCAN is configurable)
Some do not include the RTR bit in the filter (Microchip MCP2515, Peak PCAN-Basic)
Some have the RTR bit but no mask for it (Bosch C_CAN, Infineon MultiCAN)

I tried to cover all those configurations with an interface that exposes capabilities similar to the approach that @josko7452 described for timing. filter_groups() returns an iterator that describes the controllers filter capabilities.
@josko7452  Regarding the bit timings I’m not quite sure if they are in scope of embedded_hal. I’m borrowing this ASCII graphic from @pftbest:
    (1)                 (2)               (3)               (4)            (5)
+--------+         +----------+  +-------------------+  +--------+  +---------------+
|  Some  |   CAN   |   CAN    |  |       HAL         |  |  HAL   |  | Device Dirver |
| Device |<=======>| Hardware |<-|  implementation   |<-| Traits |<-|      for      |
|        |   BUS   | (in MCU) |  | (hardware driver) |  |        |  | "Some Device" |
+--------+         +----------+  +-------------------+  +--------+  +---------------+
                                           ^                                ^
                                           |                                |
                                           |                        +---------------+
                                           |                        |      User     |
                                           +------------------------|    Program    |
                                                                    |               |
                                                                    +---------------+
                                                                           (6)

Usually the system integrator configures the bit timings. I would consider bit timing configuration to be part of the init procedure in (6).
In contrast the HAL only provides traits for the device drivers (4), (5). So even if a generic device driver can query the timing capabilities how would it use that information? The only use case I can come up with: Baud-rate adjustments during runtime (similar to #79). Given that the CAN bus is usually used for reliable applications software based baud-rate adjustment looks rather fragile to me.

@josko7452 Regarding the bit timings I’m not quite sure if they are in scope of embedded_hal. I’m borrowing this ASCII graphic from @pftbest:

Yes I have seen that ACII graphics. My point is that I don't know whose scope that would be otherwise.
The problem is that as you probably know CAN timing parameters are given by CAN standards (like this one) and therefore can be calculated generically disregarding the specific implementation of a given CAN IP core.
To me if you are an init procedure in (6) you would only like to pass something generic to the driver which all drivers understand rather than having to deal at (6) which register sets what..
That's the point of the driver to abstract the register accesses or am I wrong? And this is exactly what struct can_bittiming describes. Instead of dealing with registers these are values as specified in the BOSH document so they are common to all CAN hardware.
struct can_bittiming { 	__u32 bitrate;		/* Bit-rate in bits/second */ 	__u32 sample_point;	/* Sample point in one-tenth of a percent */ 	__u32 tq;		/* Time quanta (TQ) in nanoseconds */ 	__u32 prop_seg;		/* Propagation segment in TQs */ 	__u32 phase_seg1;	/* Phase buffer segment 1 in TQs */ 	__u32 phase_seg2;	/* Phase buffer segment 2 in TQs */ 	__u32 sjw;		/* Synchronisation jump width in TQs */ 	__u32 brp;		/* Bit-rate prescaler */ };
The driver can take this and translate it to IP core specific registers that set what this describes.
This is usually very thin layer of translation just subtracting 1 or adding 1 or summing some of these.
I am not saying there is need to include this calculation in embedded-hal this can be done elsewhere (even application layer, or pre-calculated constants), but what is needed is a concise interface to set the timing.
Also by these examples I am not saying we should copy what is in the Linux kernel.
But on the other hand there were several takes on CAN HW abstraction there so why to reinvent the wheel.
Just for completness this is how these structs are used:
https://elixir.bootlin.com/linux/latest/source/drivers/net/can/dev.c#L118 (this is the generic calculation of timing heuristic)
And this is how it's used in a driver:
https://elixir.bootlin.com/linux/latest/source/drivers/net/can/ti_hecc.c#L175
and
https://elixir.bootlin.com/linux/latest/source/drivers/net/can/ti_hecc.c#L265
As you can see it doesn't add a lot of burden to the driver. What it does is that instead of having
implementation specific method to set bit timings we would end up with a generic one.
And then when you would port your application from one CAN HW to another you wouldn't need to replace your init function in (6) for the CAN HW, because it would still apply (be it constants or a function that calculates struct can_bittiming on the fly.
If there is another place where such a generic interface can be defined for all CAN drivers then I welcome the suggestions.

Rebased to resolve the conflict in Cargo.toml.
Any comments on this?
Looking at this again with some distance I would consider dropping/postponing the second commit with filter traits to get a basic interface going.

Thank you for the comments and suggestions!

I had to unwrap() when creating the CanFrame because the identifier may be too large to fit into the frame u32 > 29bit for EFF and u32 > 11bit for SFF. So I assume it's probably a good idea to make both new_extended and new_standard return a Result.

Makes sense looking at your socketcan implementation. I did not put a Result because I could not come up with a recovery scenario. When an application wants to create a frame with an invalid identifier something must be going wrong already. Anyway, I’m not feeling strongly about this.

Unable to implement with_rtr without modification, I assume this is not really critical.

socketcan should be able to support this. The rust wrapper should be extended with a method to set that bit.

The Ok return type documentation for Transmitter::transmit was  a little unclear to me. I assume the returned frame would be one with lower priority already in the buffer right?

You understood that correctly: The returned frame is the one with the lowest priority of all pending messages. As a non-native speaker I’m glad to take suggestions for better a description.

Wondering what's up with this PR?  Looking forward to having this available...

Hey @timokroeger,
You might be asked to rename several trait methods with the try_ prefix for fallible methods to prevent name collisions.
I noticed this while trying to submit a PR in linux-embedded-hal... complicates things a little.
Thoughts?

@thejpster  I'm guessing a) you got lots on your plate or b) you're out on vacation and very intoxicated (hope it's b)...  looking forward to getting your input.
Seems to me like adding CAN support would be a pretty big deal, and Timo's implementation is very solid.

I'm on holidays. Give me another week to write a summary about the state of this pull request und outstanding changes/ideas.
The try_ prefix is certainly something we should consider.
AFAIK thejpster has hibernated his embedded-hal activities. It's just the automatic reviewer list that is out of date.

Gotcha.  Enjoy your off-time and stay safe.

Added candev to the issue description and included a list of open items.
New requirements
Protocol libraries like UAVCAN are the intended consumers of the CAN traits.
Luckily UAVCAN has a list of requirements for the CAN interface.
We are are missing two of them:

Transmission deadline
RX and TX timestamps

I’m not sure if it possible to add TX deadlines in nice generic way (SocketCAN for example cannot implement it).
RX timestamps, in contrast, can IMO easily be added with a fn timestamp() -> Option<Timestamp> method on the Frame trait.
For TX a common approach is to make use of loopback frames.
Combine Receiver and Transmitter traits
To make the loopback approach work we need to merge the  Receiver and Transmitter traits.
This comes with additional benefits of simpler drivers as @reneherrero noted.
impl<Can, F, E> Driver<Can>
where
    F: Frame,
    E: core::fmt::Debug,
    Can: Receiver<Frame = F, Error = E> + Transmitter<Frame = F, Error = E>,

vs.
impl<Can> Driver<Can>
where
    Can: embedded_hal::can::Can,
    Can::Error: core::fmt::Debug,

I will prototype those ideas with PCAN and stm32f1xx-hal to see how well they work.
What do you think?

I think adding fn timestamp() -> Option<Timestamp> makes sense to the Frame trait.  I just updated the socketcan-fork. Seems to work fine. I think it might be good to have an easy way for extracting the id from the enum. E.g. an Into<u32> for Id.

Changes

Removed the filter traits (I will open a seperate pull request for them)
Added try_ prefixes
Added default blocking implementation

@marcelbuesing
I also prototyped some timestamping. I think the best solution is to go with embedded-time in the long run. Gonna open another PR soon to show the progress here.
I’m hesitant to add the Into<u32> / From<Id> impls. In systems which use both standard and extended identifiers they convert into the same number even though the are distinct. Having the user explicitly check the type prevents bugs in the case of mixed IDs.

Please have a good look at the blocking traits! I’m not overly confident, because I’m not fully familiar with the pattern yet.
Is it a bad thing for both traits to have the exact same function names?
Example blocking trait implementations and usages:

PCAN-Basic
stm32f1xx-hal

Please have a good look at the blocking traits! I’m not overly confident, because I’m not fully familiar with the pattern yet.
Is it a bad thing for both traits to have the exact same function names?
Example blocking trait implementations and usages:
* [PCAN-Basic](https://github.com/timokroeger/pcan-basic-rs/commit/0f25fa7d9c7447590daa7802af103fee58b19a67)

* [stm32f1xx-hal](https://github.com/timokroeger/stm32f1xx-hal/commit/7249d2e6034323bd83849e3625d2236337eb53d8)

Well it seem mostly analogous to the serial implementation, although serial seems to add a b to the default blocking implementation fns. I assume this might become relevant once there are non blocking default implementations.
Regarding the timestamp, not sure what the policy is regarding dependencies. Maybe this could be put behind a feature flag making the dependency to embedded-time optional.

I’m hesitant to add the Into / From impls. In systems which use both standard and extended identifiers they convert into the same number even though the are distinct. Having the user explicitly check the type prevents bugs in the case of mixed IDs.

Yes I assume you are right, it might be a little inconvenient but it probably makes more sense this way.
Btw. not really relevant but since I mostly worked with a Socketcan so far, I'd consider naming the fns try_read and try_write.

I'm attempting to use the fork for an ISOTP implementation but I'm stuck with Error not enforcing being std::fmt::Debug. Any ideas ;)?
use thiserror::Error as ThisError;

#[derive(ThisError, Debug)]
pub enum Error<TCan> where TCan: Can, <TCan as Can>::Error: std::fmt::Debug {
     // ...
    #[error("CAN error")]
    Can(#[from] TCan::Error),
}

#[derive(ThisError, Debug)]
   |          ^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T> std::convert::From<T> for T;
   = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)

@marcelbuesing
Looks like the error described in https://github.com/dtolnay/thiserror/issues/85.
Probably removing #[from] fixes it.

What do you think about starting with a seperate crate for can traits for now? That way it could already be used by other crates.

Great idea! The traits now live at: https://github.com/timokroeger/embedded-can and there is a v0.1 release on crates.io

Just want to point out that @timokroeger 's crate has 39,887 downloads.  I think that's a pretty clear indicator that CAN support should be included here.

Here an update about the changes that have happened embedded-hal:

This should be in a new can module with blocking/nb
We decided against including default implementations (#289)
We removed all try_ prefixes.
You can propose error variants for this over at #296

It is great to see these traits have so many users and 2 implementations. I would welcome these traits on embedded-hal.
Given the field experience:

What are the open design questions?
Do you foresee any breaking changes?

Appreciate you looking into this @eldruin Timo's implementation has matured over time.  0.3.0 is quite a bit simpler than what's here: I like it, much easier to consume.
@timokroeger Why did you switch the 'Id' trait to an actual implementation?  The one piece I'm really not crazy about are the constructors.  If the value is out of range, shouldn't that be an error?  Take 4? :)

Thank you bringing the PR to my attention again.
The comment section on this PR has become rather big. I created a new take 4 PR with the changes suggested by @eldruin.
@reneherrero
I found that all implementations of an Id trait would look almost the same and with a concrete implementation we do not need another associate trait for the Can interface.
I still have to catch up #296 on the error handling. If we have concrete error types I agree that it might make sense for the Id constructors to return a Result


Gets an error when ffmpeg -re i my RTSP string

I have a camera that stream RTSP via the string rtsp://<IP_ADDRESS>/stream2 (want to use stream two) I have configure the second stream on the camera to be 640x480 12ips and when I playback it on my PC via VLC I get video without any problem.
I run homebrigde on my Raspberry Pi 3 and its works fine:) But when I run ffmpeg -re i rtsp://<IP_ADDRESS>/stream2 I get this responce:

Would be very thankful if someone could guide me in the correct direction what can be wrong:)

A few things… first, “-re” requires you to have an output, in this case you don’t have that so it throw out the first error. Second instead of “i”, it’s actually “-i” ...
Best Wishes,
Tian Zhang

On Mar 18, 2017, at 1:12 AM, Klangen82<EMAIL_ADDRESS>wrote:
I have a camera that stream RTSP via the string rtsp://<IP_ADDRESS>/stream2 (want to use stream two) I have configure the second stream on the camera to be 640x480 12ips and when I playback it on my PC via VLC I get video without any problem.
I run homebrigde on my Raspberry Pi 3 and its works fine:) But when I run ffmpeg -re i rtsp://<IP_ADDRESS>/stream2 I get this responce:
https://cloud.githubusercontent.com/assets/25564168/24070305/e83ec726-0bba-11e7-9d56-ea7a1761bb00.png
Would be very thankful if someone could guide me in the correct direction what can be wrong:)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub https://github.com/KhaosT/homebridge-camera-ffmpeg/issues/66, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpU4KS9KceZbEjp0LV5-dJ2b6OGebaSks5rm5IIgaJpZM4MhVJQ.

Thanks! seams to work, agree?

Now I should be able to use this as config:

Please put 30 as maxFPS even if camera can’t support that otherwise HomeKit will not be happy. other than that it looks good.
Best Wishes,
Tian Zhang

On Mar 18, 2017, at 1:22 AM, Klangen82<EMAIL_ADDRESS>wrote:
Thanks! seams to work, agree?
https://cloud.githubusercontent.com/assets/25564168/24070348/083025e2-0bbc-11e7-840e-9ef55e535742.png
Now I should be able to use this as config:
https://cloud.githubusercontent.com/assets/25564168/24070361/3e540e68-0bbc-11e7-8438-edfea3e66adc.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/KhaosT/homebridge-camera-ffmpeg/issues/66#issuecomment-287525231, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpU4BrbeEstLMkAhIVKZosL2dh9v8zPks5rm5QpgaJpZM4MhVJQ.


No mods are loading

I’ve successfully installed the app on my Steam Deck using dotaxis’s script. The game also launches successfully with the FFNx screen showing at the beginning. But no mods are loaded whatsoever. If I have a music or sound mod enabled, no sound plays whatsoever.

Same issue on Windows 10.

I'm sorry but we do not cover Steam Deck issues over there as it's unrelated to 7th Itself. Feel free to use the Discord server to ask for help and support. Cheers!

It also doesn't work on my Windows desktop or laptop??

It also doesn't work on my Windows desktop or laptop??

You're not the only user using this product :) Feel free to ask for support, it might be something specific to you and your own setup of Windows.


Update to Swift 5.9 release

[x] install new Xcode version on builders

[x] Xcode-15.0.0 (mb6)
[x] Xcode-14.3.1 (mb5)

[x] Update spi-images https://gitlab.com/finestructure/spi-images/-/merge_requests/12
[x] make sure SPIManifest SwiftVersion.latestRelease is pointing to the desired Swift version (for doc builds) https://github.com/SwiftPackageIndex/SPIManifest/pull/33/files
[x] update builder https://gitlab.com/finestructure/swiftpackageindex-builder/-/merge_requests/221

[x] SwiftVersion.xcodeVersion
SwiftVersion.dockerImage doesn't need changing, this is done via spi-images

[x] update server (no changes required)

[x] SwiftVersion.xcodeVersion

[ ] remove old Xcode version from builders
[ ] update base image in package list https://github.com/SwiftPackageIndex/PackageList/pull/5238
[ ] update base image in validator https://github.com/SwiftPackageIndex/PackageList-Validator/pull/50

@daveverwer NB, I'm bumping the builder's Xcode versions to Xcode-15.0.0 and Xcode-14.3.1. We were still on 14.3.0.

We're now building with 5.9 release. Keeping this issue open until the cleanup tasks are complete.


add nf-core-project

Project with 3 workflows from nf-core

Can you add a README in the project root that describes what these workflows are and provides appropriate link out to the NF-Core and the repos for each of the pipelines?

Done


no response from server .

Its taking a too much time to response back and given timeout error.
{
"error" : "internal",
"error_code" : 71,
"error_message" : "Internal error.",
"error_what" : "no response from server"
}

Closing this stale issue. Feel free to reopen if you can provide more details.


ICH and DCH shouldn't be affected by vertical margins

Environment
Windows build number: Version 10.0.18362.239

Steps to reproduce
Open a WSL conhost shell, and execute the following command:
printf "\e[3;4r\e[5@\e[r\n"

This sets the vertical scroll margins to lines 3 to 4, inserts 5 characters at the start of the first line (using the ICH escape sequence), and then resets the margins again.
Now open a new WSL conhost shell, and execute the following command:
printf "\e[3;4r\e[5P\e[r\n"

This sets the vertical scroll margins to lines 3 to 4, deletes 5 characters from the start of the first line (using the DCH escape sequence), and then resets the margins again.
Expected behavior
In the first case I'd expect to see the first line indented by 5 characters. In the second case I'd expect to see 5 characters deleted from the first line.
This is how those commands look in XTerm:

Actual behavior
Both commands are ignored, because they're executed above the top of the scroll margins.
Now I can't say for sure that this is the wrong behaviour. The VT510 documentation says that both ICH and DCH have "no effect outside the scrolling margins", but it's possible they were referring only to the horizontal margins in that particular context. If you look at the DEC STD 070 manual, the wording is a lot clearer: "If the Active Position is outside the left or right margins, this control is ignored."
However, just to confuse things some more, the DEC STD 070 manual also provides a kind of pseudo code algorithm for each command, and the algorithm for ICH seems to suggest that it is limited by both the horizontal and vertical margins, while DCH is only affected by the horizontal margins. I suspect that might just be a bug in the ICH algorithm, but who knows.
Bottom line: the documentation isn't particularly clear about this, but I do know that we don't currently match XTerm's behaviour.

@DHowett-MSFT I'm definitely happy for you to assign these bugs to me. Just bear in mind that I might be a bit slow in getting things done, because I don't always have that much time to work on this stuff.
Regarding this particular bug, there is one easy way to fix it, which is to add a check in the ScrollRegion function which would ignore the margins when the scrolling direction was horizontal. However, while looking into the implications of that change, I came to the conclusion that the margin checking should really be removed from the ScrollRegion function altogether, and then left up to the calling code (which can pass in margins, if required, via the existing clip rect).
It's not only the ICH and DCH commands that shouldn't have margins applied. There is also the CSI 3 J sequence (erase scrollback), as well as the public ScrollConsoleScreenBuffer API, which almost certainly shouldn't be affected by the DECSTBM margins. And then there is the AdjustCursorPosition function, which has to temporarily change the margins to achieve the results it needs. In fact requiring no margins, or custom margins, is possibly more common than actually wanting the default DECSTBM margins.
I can raise additional issues to document the problems mentioned above in more detail, but I think it would be easiest to fix them all at the same time. What it comes down to is some refactoring of the ScrollRegion function, as well as updates to most of the places it's called from, but I think the end result may well be a little simpler than what we have now.
Which brings me to the next complication. These changes are quite closely tied to the fixes in PR #2505, so I wouldn't be able to submit a PR for this until that one is merged. Not that that stops me from working on the solution - so there's no urgency - I just wanted you to be aware of the dependency.


Update Android dependencies to latest

Does this force us to build our apps with the latest NDK version v27 when building our apps?


-ms-touch-action

Hi. note you need to set CSS property -ms-touch-action to none in order to be able to draw a signature on a Microsoft Surface Pro.

Thank @benjacksonx ... This helped me a lot

closing as stale


fix: Argo DB init conflict when deploy workflow-controller with multiple replicas #11177

Fixes #11177
Motivation
Fix Argo DB init conflict when deploy workflow-controller with multiple replicas.
Modifications
Move the DB init logic to after the leader election completed.
Verification
After the code modification, tested the workflow-controller deployment in my environment with
multiple replicas (1, 5 and 10), all work ok.
10 for example:
workflow-controller-85bfb69457-4tcbz   1/1     Running   0          5s
workflow-controller-85bfb69457-dwvll   1/1     Running   0          6s
workflow-controller-85bfb69457-fvcvj   1/1     Running   0          5s
workflow-controller-85bfb69457-fzkv9   1/1     Running   0          5s
workflow-controller-85bfb69457-khs2v   1/1     Running   0          5s
workflow-controller-85bfb69457-mjwhs   1/1     Running   0          5s
workflow-controller-85bfb69457-npxb7   1/1     Running   0          5s
workflow-controller-85bfb69457-qq7zc   1/1     Running   0          5s
workflow-controller-85bfb69457-rmgc4   1/1     Running   0          5s
workflow-controller-85bfb69457-snrn9   1/1     Running   0          5s

@terrytangyuan Wrapped the DB init logic into a func, and called after the leader election.
PTAL thanks.


Trying to reconcile direct and poliastro Horizons queries

As mentioned in #1581, I'm attempting to reproduce the "flyby anomaly", and poliastro seems to generate a close enough trajectory, with classical elements and ground track closely matching the original JPL report (Antreasian & Guinn, 1998).
However, I am stuck at a rather large discrepancy between what I get directly from Horizons and using from_horizons in poliastro. Here's my poliastro query:
from astropy import units as u
from astropy.time import Time
from poliastro.util import norm, time_range
from poliastro.frames import Planes
from poliastro.ephem import Ephem
from poliastro.bodies import Sun, Earth
from poliastro.twobody.orbit import Orbit
from poliastro.twobody.sampling import EpochsArray
from poliastro.spheroid_location import SpheroidLocation
from astropy.coordinates import solar_system_ephemeris
import numpy as np

dss25 = SpheroidLocation(243.124600*u.deg, 35.3375595*u.deg, 0.9623240*u.m, Earth)
dss34 = SpheroidLocation(148.981964*u.deg, -35.398479*u.deg, 0.6920208*u.m, Earth)

solar_system_ephemeris.set("de440")
goldstone_end = Time("1998-01-23 06:14:55.6", scale="tdb")
canberra_start = Time("1998-01-23 09:53:55.6", scale="tdb")
start_epoch = Time("1998-01-23 06:00:00", scale="tdb")
flyby_epochs = start_epoch + (np.arange(0, 60*1, 1) << u.minute)

def describe_orbit(orbit):
    print()
    print("::ORBIT::")
    print("Plane:", orbit.plane)
    print("Inclination:", orbit.inc << u.deg)
    print("Eccentricity:", orbit.ecc)
    print("Semilatus rectum:",orbit.p)
    print("Semimajor axix:",orbit.a)
    print("Periapse radius:", orbit.r_p, ", altitude:", orbit.r_p-orbit.attractor.R)

def check_trajectory(ephem, epoch, station):
    if epoch < ephem.epochs[0] or epoch > ephem.epochs[-1]:
        return
    print()
    print("AT ", epoch)
    station_r = station.cartesian_cords
    rv = ephem.rv(epoch)
    r = rv[0]
    d = r - station_r
    d_mag = norm(d)
    v = rv[1].dot(d)/d_mag
    rv_1s = ephem.rv(epoch + (1 << u.s))
    r_1s = rv_1s[0]
    d_1s = r_1s - station_r
    d_1s_mag = norm(d_1s)
    dr = d_1s_mag - d_mag
    v_1s = rv_1s[1].dot(d)/d_mag
    dv = v_1s - v
    print(d_mag, dr.to_value(u.m) * (u.m/u.s), dv.to_value(u.m/u.s) * (u.m/(u.s*u.s)))

near_start_ephem = Ephem.from_horizons("NEAR", start_epoch, plane=Planes.EARTH_EQUATOR)
earth_ephem = Ephem.from_horizons("399", flyby_epochs, plane=Planes.EARTH_EQUATOR)
near_start_rv = [near_start_ephem.rv(start_epoch)[i] - earth_ephem.rv(start_epoch)[i] for i in [0,1]]

near_orbit = Orbit.from_vectors(Earth, near_start_rv[0], near_start_rv[1], start_epoch)
describe_orbit(near_orbit) # this output closely fits the A&G paper

near_ephem = near_orbit.to_ephem(EpochsArray(flyby_epochs))
# these don't fit!
check_trajectory(near_ephem, start_epoch, dss25)
check_trajectory(near_ephem, goldstone_end, dss25)

The output is
:ORBIT::
Plane: Planes.EARTH_EQUATOR
Inclination:<PHONE_NUMBER>7378455 deg
Eccentricity: 1.8141233069627105
Semilatus rectum: 19451.27824487443 km
Semimajor axix: -8490.139678389176 km
Periapse radius: 6912.020591545519 km , altitude:<PHONE_NUMBER>455192 km

AT  1998-01-23 06:00:00.000
47036.89254821595 km -7953.926048459834 m / s -0.19905762925453985 m / s2

AT  1998-01-23 06:14:55.600
39839.85414104353 km -8127.134302689228 m / s -0.27973750867360536 m / s2

Direct query to Horizons returns 37962802.20899999 m for the Goldstone range at 06:00, and 31059025.976 m at 06:15, almost 10,000 km less than my poliastro code. The range rates are also too large by nearly 1 km/s, and the radial acceleration (towards Goldstone) is almost an order larger. I suspect this has to do with coordinate frames and how I'm transforming above, would greatly appreciate any pointers.
My query file for the Goldstone track is at URL

For completeness, I run the direct query near_los.q with the python query script query.py thusly:
query.py near_los.q | extract.py > result.txt

The second script extract.py converts the light time and the range, range rate columns from minutes to seconds and from AU, AU/d to m, m/s units, respectively.

There is also a problem of consistency: the near_start_rv given by Horizons has a smaller range value (44510 km), meaning the to_ephem call is returning a different initial state from the one with which the orbit object had been constructed. This shows up more clearly with cleaner code
near_start_ephem = Ephem.from_horizons("NEAR", start_epoch, attractor=Earth, plane=Planes.EARTH_EQUATOR)
near_start_rv = near_start_ephem.rv(start_epoch)
print(start_epoch, norm(near_start_rv[0]) << u.km, norm(near_start_rv[1]) << (u.km/u.s))

eliminating earth_ephem in my example code above. (This also reduces the range at 06:00 to 46971.75 km, which is still almost 10,000 km off the direct query.)
How can the ephemeris generated for an orbit so disagree (~2,500 km out of ~40,000 km, or over 5%) with the initial dynamical state that defined that orbit?
(This is with 0.17.0.)

Verified that astroquery.jplhorizons is returning correct values:
obj = Horizons(id='NEAR', location='257@399', epochs=start_epoch.jd).vectors(refplane="earth")
print(obj["range"] << u.km, obj["range_rate"] << (u.m/u.s))

yields
[32002.5109804] km [-7682.85566592] m / s

consistent with my direct query results. The problem is
near_start_ephem = Ephem.from_horizons("NEAR", start_epoch, attractor=Earth, plane=Planes.EARTH_EQUATOR)
near_start_rv = near_start_ephem.rv(start_epoch)
r = near_start_rv[0]
print("Range from DSS25: ", dss25.distance(r[0], r[1], r[2]) << u.km)

prints
Range from DSS25:  40224.992182556955 km

which is way off. The orbital elements (inclination, eccentricity, perigee altitude) are very close despite being derived from this start state in the from_vectors step, however. The longitude and latitude for DSS25 are taken from Horizons output, and cross-checked with DSN Handbook 301F.  Please help.

The from_horizons values correspond to Horizons data 17 min 53.268 sec earlier for both range and range rate. That explains why the orbital elements fit. This time difference is still a mystery.

The from_horizons values correspond to Horizons data 17 min 53.268 sec earlier for both range and range rate. That explains why the orbital elements fit. This time difference is still an issue.

Verified that astroquery.jplhorizons yields the correct values:
[32002.5109804] km [-7682.85566592] m / s

with
obj = Horizons(id='NEAR', location='257@399', epochs=start_epoch.jd).vectors(refplane="earth")
print(obj["range"] << u.km, obj["range_rate"] << (u.m/u.s))

but
near_start_ephem = Ephem.from_horizons("NEAR", start_epoch, attractor=Earth, plane=Planes.EARTH_EQUATOR)
near_start_rv = near_start_ephem.rv(start_epoch)
r = near_start_rv[0]
print("Range from DSS25: ", dss25.distance(r[0], r[1], r[2]) << u.km)

produces
Range from DSS25:  40224.992182556955 km

which is way off- and corresponds to 17 min 53.268 sec earlier in the flyby. The 257@ site prefix makes the Horizons query topocentric, otherwise the reference frame used is inertial, and poliastro appears to keep it that way. All of my modeling of the anomaly to reproduce its residuals concerns range-related signal effects and calls for ECEF, however.

The start_epoch in preceding comment was 06:14:00, the approximate start of the radar tracking in that flyby. Turns out I do not need ECEF. The get_gcrs_posvel method of astropy EarthLocation allows computing topocentric range and range rate in GCRS. The values turn out consistent with Horizons, remarkably, to 1 m  and 0.1 mm/s.


fix(edge-identity-view): reduce max page size to 100

Thanks for submitting a PR! Please check the boxes below:

[x] I have run pre-commit to check linting
[x] I have filled in the "Changes" section below?
[x] I have filled in the "How did you test this code" section below?
[x] I have used a Conventional Commit title for this Pull Request

Changes
Reduce max page size to improve latency
refer: https://github.com/Flagsmith/infrastructure/issues/16
How did you test this code?

Covered by unit tests

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (3732e67) 95.63% compared to head (0dd666b) 95.63%.
Report is 4 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main    #2937   +/-   ##
=======================================
  Coverage   95.63%   95.63%
=======================================
  Files        1012     1012
  Lines       29137    29142    +5
=======================================
+ Hits        27866    27871    +5
  Misses       1271     1271

Files
Coverage Δ

api/app/pagination.py
92.59% <100.00%> (+0.59%)
:arrow_up:

api/environments/dynamodb/dynamodb_wrapper.py
96.03% <100.00%> (+0.03%)
:arrow_up:

...s/dynamodb/tests/test_dynamodb_identity_wrapper.py
98.22% <100.00%> (+0.01%)
:arrow_up:

.../edge_api/identities/test_edge_identity_viewset.py
100.00% <100.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

I have sent notifications out that this will be released on Tuesday 21st November.


Add garbage collector

I considered considered two different approaches on where to put the garbage collection logic:

Centralize it in garbage_collector.rs.
Co-locate collection logic with tablestore.rs and manifest_store.rs.

I started with (1), but found that I was faced with two options that I didn't like:

Make garbage_collector.rs understand the folder structure, file structure, and WAL/compactor implementation details.
Add a reader/deletion methods to tablestore.rs and manifest_store.rs to expose object information like size, last updated, file location, etc.

I didn't like either of these approaches. Putting the internal implementation details of the WAL/manifest protocol in garbage_collector.rs felt wrong. I tried adding abstraction and methods to keep the protocol/structure encapsulated, but it got pretty messy (tried adding ManifestObjectMetdata, SstObjectMetadata, and had to give GC the DB state).
So, I went with (2) in this PR. I still don't really like that the compactor SR collection is in the table store. I also am not a fan of the duplicate code. Would love thoughts on how to clean this up.
Changes:

Add GC config the the DB. The config allows users to set how frequently the GC runs and the min_age. The GC will only delete files older than the min_age. Users may also configure the WAL, compacted, and manifest settings separately.
Added a GarbageCollector and GarbageCollectorOrchestrator. The GC just starts and stops the orchestrator. The orchestrator sets up the clocks for the WAL/compacted/manifest GC poll settings and calls the collect methods when the ticks occur.
The GarbageCollector and GarbageCollectorOrchestrator are implemented similarly to Compactor (vs flush.rs and mem_table_flush.rs. I did this because I'd like to support running the GC as a separate process in the future; this is something the Compactor design supports.
The manifest GC currently deletes all manifests that are older than min_age. Once snapshots are added (#54), we'll need to update the logic to exclude all active manifests (the current manifest and all snapshotted manifests). Since new snapshots may only reference the current manifest or a snapshot in the current manifest, deleting manifests older than min_age should be safe.
The WAL SST collection logic deletes all SSTs up to, but not including, last_compacted_wal_sst_id that are older than min_age.
The compacted SST collection logic deletes all SSTs that are not referenced by the current manifest's l0 and compacted SST/SR lists (and that are older than min_age).

I still need to add tests, but I wanted to get this out so people could sanity check what I've got.

RE the design, my main gripe is that TableStore now has awareness of CoreDbState - where before it just saw SSTs that it has to write and read.

Yes, this is what annoyed me, too.

I also don't see the problem with the garbage collector seeing CoreDbState objects. As a top-level process that's operating at the same "level" as the db/compactor it feels reasonable to have it be aware of the semantics of the fields inside CoreDbState.

I agree with this part, but what I didn't like was that I was left with two options:

The compactor knows the intricate details of the file layouts for SSTs and manifests on object storage.
We have to add a bunch of abstraction methods like list and delete (which you mention below), and it got pretty nasty.

Other than that I'm slightly more partial to having generic list and delete style interfaces where list returns some list of metadata objects that describe SSTs - but I can also see how that can get confusing

Yes, exactly. I added a ManifestObjectMetdata and an SstObjectMetadata struct, then had list and delete methods for each. On their own, it's OK-ish but not great.. Then when you try to merge get_wal_sst_list with it, it got a bit ugly. That's where I threw in the towel.
But given your intuition is the same as mine around the right structure, I'll give it another shot to see if I can get better abstractions.

@rodesai @flaneur2020 @vigneshc @paulgb I think this is ready for another review. Addressed some comments and moved the logic into the GC.
I had to introduce ManifestFileMetadata and SstFileMetadata to expose last modify time for SSTs and manifests from TableStore and ManifestStore, respectively.
I also made all the GC stuff async and centralized the block_on to just be in the GarbageCollector::new spawned thread. Seems pretty clean for now. If we want to fully remove the block_on calls, that should be a separate PR.
Still some tests to write, but I feel pretty good about this approach.

There was some interesting discussion on discord about the current GC implementation. The gist of it is that min_age in this PR currently uses the last modify time for the files in object storage. Some compacted SSTs could be quite long lived, though (say, more than a day). Once the compactor finally decides to compact out an old sorted run, the SSTs will be deleted the next time the GC's poll_interval ticks for the compacted SSTs (defaults to 5 minutes). The effect is that SSTs in old sorted runs will be deleted 5 minutes after they're removed from the manifest.
This won't harm anything, but is a bit counterintuitive (and could impact range queries in the short term, since we're planning to implement range queries without snapshots until snapshots are done).
I've documented an alternative approach for GC'ing compacted SSTs here:
https://github.com/slatedb/slatedb/issues/204
I don't think this is a blocker, just something we can improve upon.


Fix double escaping in convenience API

Fixes https://github.com/aesiniath/http-streams/issues/118

I'll get this merged and released this weekend.


The error message for quote diagnostic rules is unclear

:tada: This issue has been resolved in version 3.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


No example file

Hi, If we dont use Biomes O'Plenty then no example.json file is created. So could you please have an example file included in the config folder?

Seconding this request!

if you use /profile 100 all, JER will produce a config file with all ore gen within 100 chunks in all dimensions

Didn't work for me :(

if you have tickprofiler installed you'll have to edit TickProfiler.cfg config file and change command name because its same as JER Resource.
It should produce a file in the JustEnoughResources config folder

In the most recent version I have changed the name of the command to /jer_profile to prevent this command name conflict


sugradh.com

https://sugradh.com/ a small ETF investing related site.

Nice website - unfortunately it hits 1.13 MB on initial load :disappointed:


Removed "firstref_server_7"

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. We will now review your pull request.
Thanks,
Microsoft Pull Request Bot


'grid-column', 'grid-media' combination should be more DRY

How can I get .item to inherit the correct width/gutter for 1 column on all of my established breakpoints (each with a custom grid) without having to repeat grid-media and grid-column(1) for each? It seems like this repetition should be unnecessary.
Custom grid settings and .item code below:
$neat-grid: (
  columns: 12,
  gutter: 2%
);

$grid-m: (
  columns: 12,
  gutter: 4%
  media: 760px
);

$grid-l: (
  columns: 12,
  gutter: 40px,
  media: 1000px
);

.item {
  @include grid-column(1);

  @include grid-media($grid-m) {
    @include grid-column(1);
  }

  @include grid-media($grid-l) {
    @include grid-column(1);
  }
}

I think the example code you have pasted above is perfectly acceptable. You are defining 3 different sizes at 3 different breakpoints. These issues would only come in to play for projects with lots of different gutter sizes across screen sizes.
A way this could be handled is with a mixin containing a loop that iterates through all of the media queries you wanted.
This is psudo-code but given your example it would probably look something like:
@mixin my-custom-grid-column($columns) {
  @include grid-column($columns);
  $media-grids: $grid-m, $grid-l;
  @each $grid in $media-grids {
    @include grid-media($grid) {
      @include grid-column($columns);
    }
  }
}

// and then…

.item {
  @include my-custom-grid-column(1);
}

Speaking generally, shorter is not always better as a solution like the one outlined above can actually make it more difficult for others reading the code to easily grasp what is going on.
Overall, this is the sort of thing that should probably be implemented manually on a per project basis, since the specific needs would be likely from project to project.


Ignore addrv2 and sendaddrv2 messages

Motivation
Some zcashd developers are working on adding support for Tor V3 Onion Services. This involves a network protocol upgrade, and some new network message types: addrv2 and sendaddrv2.
Currently, Zebra disconnects from peers that send unrecognised message types (#2107).
Until we fix that bug, we want to ignore these new messages instead.
Specifications
https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
Current Implementation
Zebra returns an error and disconnects from the peer if the message type is unrecognised:
https://github.com/ZcashFoundation/zebra/blob/76591ceeede5d917ad6db54ae4fce12d67cddd2d/zebra-network/src/protocol/external/codec.rs#L435
Related Work
Eventually, we might want to add V3 onion service support in Zebra, which involves parsing and storing these addresses in our address book.

Ideally we'll:
0.  Implement sendaddrv2 responses to version (on a feature branch)

Use the dev-version of zcashd to test a zebrad
Implement sendaddrv2 message discarding in zebrad
Merge discarding zebrad
Merge sendaddrv2 zcashd

Given the small change required of zebrad it seems likely that this order can be achieved.
As I am writing this, I think I am realizing that we should land sendaddrv2 handling nodes, before we launch nodes that actually broadcast them.

As I am writing this, I think I am realizing that we should land sendaddrv2 handling nodes, before we launch nodes that actually broadcast them.

You might not need to do anything special for zcashd.
I think it already ignores unknown message types and continues talking to the peer.
(This is standard Bitcoin behaviour, but it's not really documented anywhere for Zcash.)
Zebra doesn't, for a bunch of different reasons:

we want to close connections from non-Zcash port scanners (we'll fix this in #2107)
it's easier to test a new network protocol stack if you get errors when you get it wrong
it's hard to find out how the Zcash network protocol should work

So, for forwards compatibility zebrad will have to either keep "message parity" with zcashd, or register messages from the future (e.g. sendheaders and sendaddrv2) and treat them differently from others.
So if I understand correctly this implies at least 3 categories of message:

valid-and-supported
valid-and-unsupported
invalid

It seems unlikely that zcashd and zebrad will always support identical message sets..   or...  at least it seems plausible that there will be skew.   The current situation is a perfect example of how such a skew can come about.

So, for forwards compatibility zebrad will have to either keep "message parity" with zcashd, or register messages from the future (e.g. sendheaders and sendaddrv2) and treat them differently from others.

Or Zebra could ignore unknown messages, once we have done the required security analysis (#2107).

See https://forum.zcashcommunity.com/t/what-to-build/39594/12?u=daira about how Zcash has handled signalling of peer protocol changes differently from Bitcoin, and why.

I will follow @daira 's recommendation to use the peer-to-peer protocol version value (170015) as the signal indicating node support for addrv2 formatted messages.   This leverages zcash's node-lifespan design to keep the possible feature configurations that peers must communicate small (only the current feature set needs to be handled).
As such no sendaddrv2 message needs to be supported.

If I understand this constraint, it implies that well-behaved nodes will continue to send v1 addr messages to peers that have not negotiated a sufficient version number with the node.
I think that may mean that zebrad nodes running lower peer protocol versions should simply ignore addrv2 as invalid (like port scanner traffic).

If I understand correctly no correctly functioning peer-node should send a addrv2 to a peer with an insufficient peer-protocol version.     Is that correct?   Does that imply we can close this issue?

Yes, this issue is outdated and doesn't match the draft ZIP 155.
But Zebra will need to parse and use the IPv4 and IPv6 addresses in the new addrv2 message before mainnet NU5 activation.


Quote postgres connection string

Now it doesn't crash on e.g. passwords with special signs

Good idea, thank you.


[CORE-10715] Document IPForwarding Felix configuration param.

Product Version(s):

OS v3.29.0
Enterprise v3.20.0-2.0, v3.19.3
Issue:

https://github.com/projectcalico/calico/pull/9313
https://github.com/projectcalico/calico/pull/9320
https://github.com/tigera/calico-private/pull/8100
https://github.com/tigera/calico-private/pull/8101
https://github.com/tigera/calico-private/pull/8102
Link to docs preview:

SME review:

[ ] An SME has approved this change.

DOCS review:

[ ] A member of the docs team has approved this change.

Additional information:

Merge checklist:

[ ] Deploy preview inspected wherever changes were made
[ ] Build completed successfully
[ ] Test have passed

LGTM, thanks! One last thing: If this goes in CE 3.19 +, does it also belong in OSS 3.27+? Currently it's included in 3.29 only.


The tutorial on anchors is not easy to understand

I know anchors are a dictionary, and each key and value of anchors is a string. But I don't know what a dictionary entry means? Especially when anchors interact with rect, I can't understand it anymore. What does a negative width rect mean?
Can you modify the anchors tutorial to make it easier to understand?

I could certainly add more visual examples of different anchoring scenarios.
On a related topic, I will also try to extend the getting started tutorial a bit further to add some 'next steps' with the 'hello world' button like adding a theming file.

I could certainly add more visual examples of different anchoring scenarios.
On a related topic, I will also try to extend the getting started tutorial a bit further to add some 'next steps' with the 'hello world' button like adding a theming file.

I actually prefer to add a logical description. Tell me the principle of anchor points and how anchor point values are calculated.


Need RecyclerView

Hi, it would be nice if this sample includes databinding with RecyclerView.
Thanks

https://github.com/liangjingkanji/BRV    Perfect RecyclerView of Databinding


Finalise content of disease tooltip

This currently contains nothing. What should it display?

Asked on slack for input. No changes at this time.


Default vhost screws up Google Search

How can I disable the default host. I would like all domains, which do not have a vhost or have a non-working SSL configuration (e.g. when letsencrypt does not work due to rate limits) to end up going nowhere = 503, 404 or 444.
Currently I end up with the default domain, which lately resulted in totally screwing up my Google index.

This is entirely controlled by the nginx.tmpl fed to nginx-proxy/docker-gen, so unfortunately we have zero control over it from this container.
I did not use the nginx-proxy default domain feature a lot, I'm going to do some tests and see if the le companion has an effect on it.

I think, this is the relevant bug in nginx-proxy: https://github.com/jwilder/nginx-proxy/issues/105

@fabiansiegel yep, I think this comment confirms that this is an issue with nginx.tmpl : https://github.com/jwilder/nginx-proxy/issues/105#issuecomment-369428711
Closing.


Circular dependence of util.setup and Paths

To generate a config file, you need to run setup from util.py.
util.py calls Paths() on L9, which in turn requires a config file, otherwise it raises a FileNotFoundError (L69)
This circular dependence currently prevents a config file from being written.

There's a quick fix for this in there now (the setup script has this_repo = True, in the call to Paths, which prevents it looking for the config file), but we should probably come up with a better solution at some point, but I think this will work for now.

Decided this workaround is probably fine for now. Closing.


Update definitions

This just updates the data/list.txt file.

Thanks. Merged and released 3.0.3.


feat: Provide a plugin's graph

Prerequisites

[X] I have written a descriptive issue title
[X] I have searched existing issues to ensure the feature has not already been requested

🚀 Feature Proposal
Have the opportunity of visualize the plugins of a fastify application in a form of a graph to understand relationships and dependencies between plugins.
Motivation
From: https://github.com/fastify/help/issues/1018

Is there any way to specify which onClose (or preClose) hooks from each plugin should be executed before the others? I have some plugins that rely on other main plugins in order to execute correctly their onClose hooks.
E.G.: Some plugins need the database plugin in order to perform some cleaning operations on the database before closing the server. If the database plugin gets torn down before the plugin, the database client results disconnected.

Transferred from: https://github.com/fastify/fastify/issues/5375
Example
const fastify = require('fastify');
const dbPlugin = require('./my-db-plugin');
const otherPlugin = require('./my-other-plugin');

// my-db-plugin.js
async function plugin(instance, opts) {
	fastify.decorate('database', mydbdriver);

	fastify.addHook('onClose', async (app) => {
		console.log('second');
		// Let's say that my-other-plugin requires
		// the database plugin to execute some cleanup work, whatever this could be
		await app.database.close();
	});
}

module.exports = fp(plugin, { name: ['database']});

// my-other-plugin.js
async function plugin(instance, opts) {
	fastify.addHook('onClose', async (app) => {
		console.log('first');
		// Let's say that my-other-plugin requires
		// the database plugin to execute some cleanup work, whatever this could be
		await app.database.cleanup();
	});
}

module.exports = fp(plugin, { name: 'other', dependencies: ['database']});

// index.js
// ... all the bootup process
await fastify.ready();

console.log(fastify.overview());

/** Just an illustrative example
{
  "plugins": {
    "my-other-plugin": {
      "depends": {
        "my-db-plugin": {
          "depends": {}
        }
      }
    }
  }
}
*/

We could improve the actual layout by adding some references for sure. The data should be there!


Image inline Admin for new post not registering

I recently added pinax-blog (and pinax-images) to my project, but there is no InlineAdmin for the images to be added to the posts as stated in the documentation.
Because of that there is no way to add pictures to a post, adding them manually in the post set does not give you the numbers you need to reference.
Steps to reproduce:

Start a new django project
Add pinax-blog and pinax-images to the installed_apps
That's it, no form to upload images while creating a post

@doktormerlin Hello, are you still working through this issue or resolved? Maybe I'm misunderstanding your question, but I'm able to create a new blog post in admin, create a blog post image set, then go back into the blog post markdown and add the image markdown for an image from the post image set. When I view the site, it works. Are you trying to do something different than this?

I see, it looks like there is a PR for this. https://github.com/pinax/pinax-blog/pull/123

Closed by #123


Connection to nodes before install wallet

Please add Node connectivity screen to install process after Seed phrase and Password, but before Creating wallet https://zpl.io/2p3drME
If user select Mobile node and wallet creation will take some time please show comment as here https://zpl.io/2p3drME

Node screens are here: https://zpl.io/be348qW and https://zpl.io/a3Evknd (Please pay attention on button name, it's different then on settings screen)
Flow:

This task continues #465

when creating a wallet with a mobile node, there is no text on the sync screen

when creating a wallet with a random node, the wallet should open quickly without a sync screen. at the moment, the sync screen is there
there must be an address template

the elements are shifted when the keyboard appears.
https://user-images.githubusercontent.com/45556620/120499623-e357f500-c3c8-11eb-8960-9414fe5e24c7.mp4

checked


Dao idls pda getters

Changes

ADD DAO idl's, pda getters and constants
FIX addressed PR comments

Checklist

[ ] UAT
[ ] Passes final QA checks

@Cain310 Changes have been made, implementation on DAO app is done here: https://github.com/staratlasmeta/star-atlas-tech/pull/1590 please review. Is there anything else we need to do for this initial version?

@Cain310 can we merge this?


CoreFoundation modularization fixes

The tests do not yet run on Darwin, but it does pass tests for other platforms.
This patch also updates the contents of the CF Unicode data tables, bringing them up to date.
The majority of this patch is probably unreviewable. However I think the Package.swift and other configuration diffs can be reviewed.
Note: This patch does away with the name "SwiftFoundation" on macOS. It's just "Foundation" everywhere now. That means we need to avoid bringing in the system Foundation when we run executables that use this library, including the tests.

I've retitled this PR to reflect what it became in the end - fixes for CoreFoundation's modularization.


How do I correctly link to my storybook?

I'm having a hard time figuring out how to link components to Storybook.
This is my connected-components config:

Below is my Button story
import React from 'react';
import { action } from '@storybook/addon-actions';
import { withA11y } from '@storybook/addon-a11y';

import Button from '../components/Button.js';

export default {
  title: 'Button',
  component: Button,
  decorators: [withA11y],
};

export const DefaultButton = () => (
  <Button onClick={action('clicked', { depth: 1 })}>Hello Button</Button>
);

DefaultButton.story = {
  name: 'default',
  parameters: {
    options: { selectedPanel: 'storybook/actions/panel' },
  },
};

The 'Open in Storybook' link opens the following URL:
http://localhost:9009/?path=/story/button--default
But the right URL for this story is:
http://localhost:9009/?path=/story/button--default-button
What is the correct way to link to my story?

Bump.
Looks like button "Open in Storybook" defaults to the first story.
Though if array of stories provided, menu icon to the left of the button appears with the stories list.

Hi Jurrian,
There are a couple of question I'd like to ask about your setup.
Button story you shared has only one story.
export default {
  title: 'Button', // -----> Story kind
  component: Button,
  decorators: [withA11y],
};
...
...
DefaultButton.story = {
  name: 'default', // ------------> Story name
  parameters: {
    options: { selectedPanel: 'storybook/actions/panel' },
  },
};

Checkout my comments on the code sample. Kind parameter is OK but you override story name as default, so the storyId of that story is actually button--default. It would be button--default-button if not the name was not overriden (SB converts variable name to kebab-case by default).  Do you manipulate that story name in any other place on your repository (maybe in .storybook/config.js)? Even if you manipulate it the link is was automatically generated based on Storybook output, so Storybook tells our plugin that there is a storyId as button--default. Considering the your sample story, looks like we have the correct URL.
Another thing, I see that you also have manually defined some story names in the configuration file. Those values manually generate links without connecting to Storybook itself, just by using their URL format. Do those stories exist on a separate file? Can you see any of the links in Zeplin like Alexey has shown above? If you see them, are they correct?

Hi Yuqu,
Thanks for the fast response! I actually didn't know that by defining the story name it overwrites storyId. It is in no way my goal to manipulate the story's name.
I've made some small changes in the meantime and it seems that Zeplin redirects to the right URL,  but Storybook gives me this weird error. When I reload the page it doesn't... I'm so confused.

I've made a copy of the repo and made it public, so if you like you can see for yourself. 😅
https://github.com/jurrianlammerts/connected-zeplin-components

What do you see on the address bar when you have a problem on refresh?
I gave it a try but could not reproduce it. Reloading the page is working for me but I could say after you open your story successfully, the URL we generated has no effect on Storybook.
I remember I was experiencing something like that during the development of the plugin. Opening same link in a fresh browser was always working when that happens, so I was thinking the problem had been related to something on local storage/cookie etc. on Storybook side.

I have the same issue as @jurrianlammerts , but I can also expand on my scenario a bit more since its not identical:
In my components.json I have specified the config as such (trailing slash intentional, even tried adding it twice.. more on that later):
"plugins": [
    {
      "name": "@zeplin/cli-connect-storybook-plugin",
      "config": {
        "url": "https://dev-next.trr.se/component-library/"
      }
    },

The plugin seems to do a decent job at picking up available stories. There are a couple of stories, first two look like this (and the plugin seems to always default to the first one):
storiesOf('Components/Button', module)
  .addDecorator(withInfo)
  .addParameters({ info: 'Button component - Primary' })
  .add('Primary - Default', () => (
    <Button onClick={action('clicked')} primary testSelector="primaryselector">
      Primary
    </Button>
  ))
  .add('Primary - Large', () => (
    <Button
      primary
      large
      onClick={action('clicked')}
      testSelector="primaryselector"
    >
      Primary
    </Button>
  ))

Now to the part where things act up..

The link that the plugin produces looks like this:
https://dev-next.trr.se/component-library?selectedKind=Components%2FButton&selectedStory=Primary%20-%20Default
However, when I manually navigate there (no Zeplin interaction), I end up on this link: https://dev-next.trr.se/component-library/?path=/story/components-button--primary-default
This is mostly fine and just two different ways leading to the same result, BUT the link produced by the plugin doesn't resolve correctly!

If I however append a trailing slash to the configured url (this is where the trailing slash config comes in), the browser (i.e. Storybook) translates https://dev-next.trr.se/component-library**/**?selectedKind=Components%2FButton&selectedStory=Primary%20-%20Default to https://dev-next.trr.se/component-library/?path=/story/components-button--primary-default (writing this I realize this may be the work of a platform team within my organization stripping trailing slashes. Please do let me know if this does not sound like something your plugin would do and I will remove this part from the issue!)
...and at this point I am in the same situation as @jurrianlammerts - on the first load this image is presented:

However, a refresh solves the issue, and any subsequent visits to any component do not share the same problem. I'll move on to browse the Storybook repo for any such issues too.

Hey @jurrianlammerts,
We've got many reports of "No Preview" for the links generated by the plugin. We were using old format hyperlinks for compability between Storybook versions. The plugin now generates new format hyperlinks if the storybook instance is v5+.
I've tried it out with your sample repository, it works fine. You don't even need to type in all kind and stories, it will automatically find Button stories. Using the following setup,
  "components": [
    {
      "path": "src/components/Button.js",
      "zeplinNames": [
        "button/default/primary",
        "button/default/secondary",
        "button/default/success",
        "button/default/outline",
        "button/default/disabled"
      ]
    }
  ]

generated these links on Zeplin:

http://localhost:9009/?path=/story/button--primary
http://localhost:9009/?path=/story/button--secondary
http://localhost:9009/?path=/story/button--outline
http://localhost:9009/?path=/story/button--succes
http://localhost:9009/?path=/story/button--disabled


Loading Aliengo/Solo/Atlas robot not working

Hi,
When I try lo load the symmetries for the robot aliengo as follows:
robot, G = load_symmetric_system(robot_name='aliengo')
I get the following error (which does not happen only for mini_cheetah but it does for the others robots as well like atlas, solo and others):

By digging deeper I think it is an issue with the config file associated with aliengo and also some other robots. For example, the config file for aliengo is:
defaults:
  - base_robot

name: a1

hip_height: 0.4

group_label: C2
# QJ: Joint Space symmetries____________________________________
permutation_Q_js: [[3, 4, 5, 0, 1, 2, 9, 10, 11, 6, 7, 8]]
# Reflections are determined by joint frame predefined orientation.
reflection_Q_js: [[-1, 1, 1, -1, 1, 1, -1, 1, 1, -1, 1, 1]]

Except for the name being wrong, and it missing the - self in the defaults attribute compared to the config file of mini_cheetah, it is missing the information regarding TqQ_js.

Hi @itaouil,
Latest commit fixes this issue. By default if rep_TqQ is not defined in the robot configuration file, it will be assumed that rep_TqQ is equal to rep_Q.
This configuration is expressed in base_robot.yaml :
https://github.com/Danfoa/MorphoSymm/blob/05914b45cde43f5e1ddd76b6907f5912b355a825/morpho_symm/cfg/robot/base_robot.yaml#L8-L11


[BUG] Multiple progressbars get printed when using v1.1.11, the same code does not have this issues when using v1.1.9

Just changing the version from v1.1.9 to v1.1.11 broke dbin, so I don't think this is an issue with our code. I'm not sure what's going wrong with the library either, I think newlines are being printed. The multiple duplicate progressbars only appear once the progressbar has reached 100%, once it has reached 100%, its duplicates appear.

In v1.1.11, multipb.go had a change at line 169, which restore the dirtyFlag to initial state so that MultiPB can reset itself.

For the old release, reusing mpb   progressbar.MultiPB is harmless. But i'm not sure what effects will be taken in new version.

I guess that's why the matter appears in your case.

Because you're reusing mpb   progressbar.MultiPB.
The safe usage is using progressbar.New() and Close() it on demand.
In my design, multibar2's downloadGroups shall be:
func downloadGroups() {
	mpb := progressbar.New()

	for _, group := range [][]string{
		{"1.14.1", "1.15.1"},
		{"1.16.1", "1.17.1", "1.18.1"},
	} {
		doEachGroupWithTasks(mpb, group)
	}

	mpb.Close() // cleanup

	mpb = progressbar.New()

	for _, group := range [][]string{
		{"1.20.1", "1.21.1"},
		{"1.22.1"},
	} {
		doEachGroupWithTasks(mpb, group)
	}

	mpb.Close() // cleanup
}

But, i also understand the situation in your project. So i'm reviewing to reorganize the original thoughts.

i hope 9408a83 can solve it. please try, thanks so much.

i hope 9408a83 can solve it. please try, thanks so much.

it's work!!!

really a good news for me. then i`m releasing the patched version.

the patched version v1.1.12 sent.
thx for ur patience.

Thanks for the fixes @hedzr


Boh

An error occured while trying to launch: ApplicationChat

Application 'ApplicationChat' init() failed: TypeError: Cannot read property 'appendChild' of undefined

TypeError: Cannot read property 'appendChild' of undefined
    at notification.wm.createNotificationIcon.onCreated (http://osjsv2.0o.no/packages/extras/Chat/combined.js:6411:22)
    at new NotificationAreaItem (http://osjsv2.0o.no/packages/default/CoreWM/combined.js:1615:20)
    at PanelItemNotificationArea.createNotification (http://osjsv2.0o.no/packages/default/CoreWM/combined.js:1668:20)
    at CoreWM.createNotificationIcon (http://osjsv2.0o.no/packages/default/CoreWM/combined.js:2898:24)
    at ApplicationChat.init (http://osjsv2.0o.no/packages/extras/Chat/combined.js:6405:30)
    at _callback (http://osjsv2.0o.no/osjs.js:1782:11)
    at http://osjsv2.0o.no/osjs.js:1826:11

Thanks for letting me know :)
This was actually fixed in a previous commit, but it seems I have forgotten to update the demo site! I will run an update this weekend as I am planning to deploy some other stuff as well

Ref: https://github.com/andersevenrud/OS.js-v2-extras/commit/1ff28ae8ee82541b241ab39f28622ef7ced7bc0c

This issue should be fixed now.  I just applied an update :)


setup for documentation

The docs can be made by running the following commands after updating the source code(and docstrings) -
1.In ./docs/, run sphinx-apidoc -o <output folder> <module path>. In our case "." and ".." respectively.
2.This creates *.rst files for each of the source code files, with modules.rst containing the files in hierarchy of directory structure and imports/dependencies.
3.Include modules in the ./docs/index.rst
4 run make html in ./docs
5. html docs can be found in _build/html/index.html.

Running sphinx-apidoc returns:
sphinx-apidoc: command not found


feat: Migrating to bun

Hi there, there was some git issue with the previous PR, hence raising this new PR.
I've incorporated the requested changes, but im stuck with the dockerFile updates (Please help me out)

Okay, will look into this and get back

I've added changes, the project works as intended with the start script. There is work needed in the dev and dev:start script for them being able to show logs as before.
Also, is the test script in use?

@ditsuke This was the way console looked with fastify CLI

Now it looks like this:

I know this can be perfected with fastify's logger customization, but I'm unable to act upon that.

Hi, I was on a break since November, I will get back to you soon with the requested changes!