Feature Request: Add toml file specifically for captive core

What problem does your feature solve?
The configuration space for the captive core append path file is not fully documented. Operators don't know what is possible to configure in captive core so they try to copy parts of the stellar-core.cfg file from their stand-alone stellar core instances into the captive core configuration. However, it's not clear which fields  can and can't be set, which forces operators to go through a trial and error process of trying different combinations of fields until they get their setup to work.
What would you like to see?
We should create a restricted toml file just for captive core which is a subset of stellar-core.cfg.
The restricted toml file should be documented with an example cfg file just like the one in the stellar core repo: https://github.com/stellar/stellar-core/blob/master/docs/stellar-core_example.cfg
We should strive to make sure that configuration is not duplicated between horizon command line flags and the captive core toml file.

Let's discuss this. What are the pros and cons?

One of the cons we should definitely keep in mind is that by pulling in a TOML parser, we're now exposing a potential attack vector to malicious user input. I'm not sure we should worry about that much, given that if you can control the config file, you can control everything else about Horizon anyway, but it's still worth keeping in mind, especially given our recent discussions about security.

If we have a separate toml file for captive core we should consider allowing LOG_FILE_PATH to be configured. If LOG_FILE_PATH is set we will store captive core logs in that location and remove captive core output from the horizon log stream. If LOG_FILE_PATH is not set then we can default to the current behavior of including captive core logs in the horizon log stream.
One point of duplication we need to figure out is how to deal with the configuration of history archive urls. History archive urls are part of horizon configuration and stellar core configuration. Ideally we should not have to configure both. But the difficulty is that stellar core's configuration is more expressive than horizon. It allows for specifying how core should obtain the history archives (e.g. curl -sf %s/{0} -o {1} or aws s3 cp s3://history.stellar.org/{0} {1})

After the discussion with ops, I think this has progressed into a far bigger, arguably meta-issue.
Should we push to make Horizon configured by toml files entirely, just like Stellar Core? Then, it will simply contain a subsection related to Captive Core configurations (while the rest will be a tomlification replacing Horizon's existing CLI / env params entirely). While this subsection may "look" just like Core's, its validity will be controlled by us entirely. This encourages our don't worry about Core's existence abstraction intended by Horizon 2.0 and Captive Core.
This transition will subsequently encompass all of the config-related issues, like #3437, #3438, #3441, and undoubtedly others that will pop up.
(Technically this breaking change would require releasing Horizon 3.0 which is a little odd, but that's the nature of semver.)

(Technically this breaking change would require releasing Horizon 3.0 which is a little odd, but that's the nature of semver.)

This can be done in a non-breaking way (however requires some extra work): if config file param is set (--config-file maybe?) all of the other flags are ignored, if it's not set we read the flags using existing code.
Pros, cons and random thoughts:

P: The same format (toml) is used for Stellar-Core and Horizon which are often used together.
P: toml allows setting more complicated structures than command line flag. One example is history archives which is currently a comma separated string in Horizon.
P: Avoids duplication in some cases like network passphrase (but sometimes impossible - read on).
C: One time requirement for rewriting Horizon configuration to use a new format.
C: This won't solve the usability issue: while it will be easier for users to create a new config (by copy&paste) they won't be able to use existing file without modifications.
Some changes in Stellar-Core are required if we want to avoid duplication completely. For example: Horizon asks for plain URLs when configuring history archives, Stellar-Core requires users to set a command (like curl) that will be used to download the files. Because of this users will have to set two archive values anyway. I opened https://github.com/stellar/stellar-core/issues/2942 hoping that we can parse the files in memory however it seems that Stellar-Core needs these files for bucket hash calculations after each ledger. I'm going to ask it's possible to add code that downloads the buckets instead of relying on external tool.

This can be done in a non-breaking way [...]

Good point. We can even consolidate the code to essentially make an in-memory TOML file from env/cli parameters, making it easier to drop the latter entirely in a future version and ensure we only have a single parsing / validation path. e.g.
User --> [CLI] ----+
User --> [ENV] ----|
                   |
User --> [TOML] <--+
            |
            v
         Horizon

This won't solve the usability issue: [...]

With proper parsing, we'll be able to advise users much better, e.g. these lines are ignored, this line is wrong, here's a Horizon-compatible toml, etc. which is still a big win over the current "Captive Core isn't running because of a bad config" state.

For example: Horizon asks for plain URLs when configuring history archives, Stellar-Core requires users to set a command [...]

Can we make it such that we essentially add an extra parameter to the Stellar-Core command in which we populate the URL, or would that be even more confusing? e.g. instead of the following:
HISTORY="curl -sf http://history.stellar.org/prd/core-testnet/core_testnet_001/{0} -o {1}"

We have
HISTORY_ARCHIVE_URL="http://history.stellar.org/prd/core-testnet/core_testnet_001"
HISTORY="curl -sf {0}/{1} -o {2}"

Unfortunately there are some assumptions built-in to the form of the HISTORY_ARCHIVE_URL in that case, so maybe this isn't a great approach. The cleanest approach is probably just keeping both around.


Should the add stall page just search polling booths, rather than address then polling booths?

AB#143

Closing and merging into https://github.com/keithamoss/demsausage/issues/1855


[PRCI - demo] ui enhancement - having automated request response in another color to make them stand out

On the demo, on PRCI, when a request is automatically processed, the responses appearing don't really stand out :

What do you think to put the automated request response in another color, in electric blue for example, and/or in bold, so they stand out to the user once the request has been processed ?
Like this sketches for example:

Idea: Have responses in a transparent grey box

This is with blindnet lightest grey, and second sketch is with some even lighter grey F5F5F5 :


Different answers when same question tested minutes apart

The question was:
मेरे सेप्टिक शॉक वाले  patient का ब्लड शुगर 180 से जयादा है।  क्या treatment देना चाहिए?
The quest was always asked on a new chat.
First time:

Second time:

Nth time:

It's understanding the question a bit differently everytime.
The chat was always set to hindi. there were no background noise and the questions were asked in same tone and tempo

It was due to google speech to text not working properly I have fixed OpenAI's whisper STT and is translating speech well.

@aparnacoronasafe could you confirm if the issue is resolved?


[spi_device] Revise Block Diagram

This commit updates the SPI_DEVICE HWIP block diagram.
The IP has been updated to support Flash mode, Passthrough mode, and TPM
mode. The block diagram hasn't been updated to represent the changes.

@GregAC @rswarbrick Looks like there's problem on CI FPGA. Could you please check?

Thanks! Let me merge the PR.


Git LFS 2.0.0 File Locking Mechanism (Work In Progress)

I've started work on the Git Plugin to add explicite Git LFS support with the new "lock" mechanism.
I am developing this in a branch on my fork of the UnrealEngine repository (git-plugin-add-git-lfs-lock-support branch)
Now available in this repository add-git-lfs2-file-lock-support (release "2.3-lfs2-lock-preview")

I currently have a "Proof Of Concept" branch more or less working with LFS locks :+1:

What do I need to test this?

Can you separate the changes into a plugin? It would be so helpful.

Hi @fire, thanks for you interest!
I believe it's still a bit too early to test: everything is on a branch on my fork, as stated above (https://github.com/SRombauts/UnrealEngine) so you need to rebuild the full Editor from source.
I've started the process of backporting all into this repository so that it will be easier for other to test, but it will take a few more hours/nights to get it in.

I was able to extract it as a plugin. What servers support the git-lfs locking?

I am testing it with Github. They are behind Git LFS and are probably the only one with a server implementation ready at this time.

Hi @fire, I discovered that the two last commits, about discovering Git LFS capabilities, and about Settings to enable/disable the Locking workflow was both broken: this was effectively disabling the "lock"/"unlock" commands entirely!
Also, I have a lot of TODOs and small in-progress improvement locally that are not ready to go public:

don't try to lock a new ("Added") asset
don't try to unlock a file that is not locked

At this stage, the whole thing assumes you have set up the repository correctly and have it working in command line, so that the plugin can just reuse the credentials.
Also everything is awfully slow (LFS is slow, and the Editor double some status commands) and awfully buggy

Ah, how did it go? Did you get stuck on something?

Hi @fire,
I got it to a point where I could make a checkin and push, but it needs far more works to be production ready. For now:

you need to complete the setup of the repository by command line (remote url and Github user credentials)
for now, I assume the whole Content/ directory is tracked, but this does not enable editing of Config/ and uproject files since the Lock command fails for them

In the meantime, I discovered more bugs/limitations of the current Git plugin, so I am working on a few merge requests to fix those ASAP.
I have also updated this plugin repository, and am going to switch it to the main dev as the "Git LFS" plugin so you could have both in Engine.
I will keep you inform, for now my main problem is trying to focus on one task at the time...

Can't wait!

I've spent some time polishing the UE4.16 release.
I've spent a greater amount of time updating this repo and shaping it into a standalone "Git (dev)" replacement plugin that you can put in your project's Plugins folder to replace the default in Engine "Git (beta version)"  plugin (so you can not have both at the same time)
@fire I am currently busy on another project, but please keep asking to push me :) !

@SRombauts any new advancements? Also GitLab by far has the best implementation of Git LFS v2.x File Locking capabilities as they actually offer a front-end website GUI solution as seen here: https://docs.gitlab.com/ee/user/project/file_lock.html
GitHub comes in probably at 2nd place in that regards and Bitbucket Cloud + Server offerings aren't even supported yet and they have open community tickets pending for requesting those features as seen here: https://jira.atlassian.com/plugins/servlet/issue/BSERV-9623

@SRombauts I don't know why this isn't being talked about more. Locking files is one of the main reasons UE4 devs tend to use Perforce

Well, in my experience, Git LFS 2.0.0 was a bit shaky, and verrrry slow compared to Perforce and Plastic SCM, so that got me a bit demotivated. I am also very busy on other projects, sorry about that :(

Just chiming in to say that I'm eagerly awaiting this feature, and happy to help test it!

I can't wait too! (Hoping this will help pushing the work  ❤ )

Hi @fire @BenjaminDSmithy @aztekyi @faemir @Totoro83, thanks for you support on this!
I really mean it, that is, I really need some motivation to get back on this! It's a bit of a daunting task since I let it in a not so good shape, and during this work I've discovered some bugs on other parts of the plugin. And now the code is diverging more and more on each release...
So hey, I should be back on the plugin, I have no other personal project going on currently, so I'll try to start by refreshing the code, and probably at least doing another general bugfix before Git LFS 2.

Really thanks for the work you're doing!

Hi all!
I have published yesterday a "Early-Access" preview-version of the Git LFS 2 plugin with some first level of support for File Lock.
Please note that:

I have found Git LFS 2 to be not totally reliable (under Windows at least). An early tester found that sometimes "read-only" flags are not in sync with "file lock" which can totally mess with the Editor assumptions on those!
This was reported testing OUSTIDE UE, so WITHOUT the plugin!
The plugin would probably have to handle this, but this could be non-trivial (think medium-term goal).
This pre-release have a known issue about File Locked by others not correctly handled!. This needs to be addressed ASAP, but I felt that I could still published the code as-is for early tests.

You have been warned enough ;) add-git-lfs2-file-lock-support (release "2.3-lfs2-lock-preview")
Cheers!

I found an issue about this on the Git LFS project issue tracker: "git lfs unlock" does not reset the readonly file system attribute. #2494
It is solved in Git LFS v2.3.0 released 7 days ago!
Is it possible that you used that previous Git LFS v2.2.1 release, the one integrated in latest "git for windows" (2.14.1) (like I did)?

Okay, so initial support of Git LFS 2 File Locks is release in v2.3 of the plugin :)
Let me know if it breaks/works for you.
Documentation should be improved on how to use this...

So if you want my opinion on the remaining works:

LFS locks on Windows command line needs to improve performance wise
I shall discover and eradicate a few minor bugs (like errors on logs and some quirks on some specific commands
I have to try to improve the robustness of the whole thing (like how to handle disconnection, failure modes...)

That's great! Thanks!
On Thu, Sep 21, 2017 at 9:48 AM, Sébastien Rombauts <
<EMAIL_ADDRESS>wrote:

Hi all!
I have published yesterday a "Early-Access" preview-version of the
Git LFS 2 plugin with some first level of support for File Lock.
Please note that:

I have found Git LFS 2 to be not totally reliable (under Windows
at least). An early tester found that sometimes "read-only" flags
are not in sync with "file lock" which can totally mess with the
Editor assumptions on those!
This was reported testing OUSTIDE UE, so WITHOUT the plugin!
The plugin would probably have to handle this, but this could be
non-trivial (think medium-term goal).
This pre-release have a known issue about File Locked by others
not correctly handled!. This needs to be addressed ASAP, but I felt
that I could still published the code as-is for early tests.

You have been warned enough ;) add-git-lfs2-file-lock-support (release
"2.3-lfs2-lock-preview")
https://github.com/SRombauts/UE4GitPlugin/tree/add-git-lfs2-file-lock-support
Cheers!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/SRombauts/UE4GitPlugin/issues/36#issuecomment-331161804,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AX__1AEa3aAYcn6v9__jvLEerZC79kU4ks5skmksgaJpZM4MW6Kl
.


start.bat

When I Double Click start.bat The Bot Does Not Go Online, Please Help

Any errors in the console?

For help setting up the bot, please visit the support server instead: https://discord.gg/vRuhG9R


word embedding weights?

https://github.com/WAMAWAMA/wama_modules/blob/main/demo/multi_label/Demo_CVPR2019_MultiLabel_ML_GCN.py#L129
hi, tks for your multi-labl codes, and could you share this weights cache=r'C:\git\.vector_cache' below?

# get word embedding
glove = vocab.GloVe(name="6B", dim=300, cache=r'C:\git\.vector_cache')

In fact, you can just not use this parameter, the weight will be downloaded automatically 👍


Exiting ship cockpit will sometimes kill palyer if the ship is still moving a bit

Latest versions don't allow for the "move body to camera" setting, so this is no longer a problem


problems with webpack-dev-server's HMR

I'm using this with HMR right now and noticed a couple of things.
In my console, I see things like:
18:4  error  'x' is not defined  no-undef

In the root of my project some files keep getting made like \033[22m\033[39m.
I'm guessing these are the terminal colors being sent through and WDS is goofing up? I can try to look into it more later. This is great otherwise, thanks!

Indeed it's colors send by the eslint stylish reporter.
Does your terminal support colors ?

Yep, my terminal supports colors and it shows up fine there.
But for some reason webpack-dev-server is also receiving the reporter warnings and spitting it out into the console and accidentally making files. I wonder if changing emitWarning to console.warn would prevent this? To be honest, I'm not sure where the bug is. This might be something in webpack-dev-server.

I am using dev-server & don't have this issue on iTerm 2 OS X Yosemite.

Cool, sounds like it's something on my end. I'll close for now. Thanks!

Reopening since I am now getting these weirdness in my browser console. We need to improve that if possible.

Server.prototype._sendStats = function(socket, stats, force) {
	if(!force && stats && stats.assets && stats.assets.every(function(asset) {
		return !asset.emitted;
	})) return;
	socket.emit("hash", stats.hash);
	if(stats.errors.length > 0)
		socket.emit("errors", stats.errors);
	else if(stats.warnings.length > 0)
		socket.emit("warnings", stats.warnings);
	else
		socket.emit("ok");
}

Webpack dev server simply sends warnings/errors over websocket "as is".
This means if we emit pre-formatted messages in the loader, we will get:
5:::{
  "name": "warnings",
  "args": [
    [
      "./src/app/Landing.js\n\n\u001b[4m/src/app/Test.js\u001b[24m\n  \u001b[90m67:11\u001b[39m  \u001b[33mwarning\u001b[39m  Block must not be padded by blank lines  \u001b[90mpadded-blocks\u001b[39m\n\n\u001b[33m\u001b[1m✖ 1 problem (0 errors, 1 warning)\n\u001b[22m\u001b[39m"
    ]
  ]
}

So maybe it is better not to format ESLint messages and keep them plain by default here: https://github.com/MoOx/eslint-loader/blob/master/index.js#L77-L79?

Actually,
    {
      formatter: require("eslint/lib/formatters/compact"),
    },

does the trick pretty well. Messages are still properly coloured. Just look a little bit less fancy.

Maybe we should make a PR to webpack dev server to remove terminal color ?

That could be a solution. At least get some discussion around it.

Just checked webpack-dev-server. This problem is already fixed in commit: https://github.com/webpack/webpack-dev-server/commit/6ea80ce82ef5020e112f9f7c69c37134329e19ca
And it is available in v1.8.0.

Nice. Good to know. Thanks!

I found that ansi escaping was not removed from warnings. Only from errors. So made a PR
https://github.com/webpack/webpack-dev-server/pull/154

Oh, cool ! Thanks for this :)


⚠ Bofrost.de has degraded performance

In 8e0ff42, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1374 ms

Resolved: Bofrost.de performance has improved in 0547a40 after 33 minutes.


v0.1: RF waveguide layout needs serious help

A few problems with the path from the ESP LNA pin to the antenna feed:

Strip line width is all wrong for this PCB thickness.  0.2mm gap and .5mm trace as used in v0.1 give ~70 ohms.  For OSH Park with dielectric constant of 4.6 and board thickness of 1.6mm, a gap of 0.2mm and 1.22mm gives an impedance of 49.98 ohms (see http://chemandy.com/calculators/coplanar-waveguide-with-ground-calculator.htm)

Via stitching around the path should be increased but should be careful not to intrude into the gap.

The 90 degree bend should be properly mitered, or preferably done with a smooth curve.

The guide ground plane should be continuous around both parts and the signal trace.  There are some spots where vias for other signals are interrupting the path.

The ground plane under the path should be uninterrupted.  In particular, the 3.3V distribution that jumps the waveguide on the bottom layer is not OK.

Thanks to Marten Wikman in the hackaday.io project log comments for suggesting some of these changes: https://hackaday.io/project/8678-rpi-wifi-hat/log/28976-your-move-portland

Fixed in v0.2.  1mm wide trace with 0.16mm gap used.


Correct header name for Stripe webhook signature verification

Summary
This PR fixes an issue with Stripe webhook signature verification in the processWebhookUrl method. The header name used to retrieve the Stripe signature was incorrect, causing signature verification failures.
Details

Updated the header name from HTTP_STRIPE_SIGNATURE to stripe-signature in the call to Stripe\Webhook::constructEvent.

Stripe\Exception\SignatureVerificationException: Unable to extract timestamp and signatures from header
in
extensions/igniter/payregister/vendor/stripe/stripe-php/lib/Exception/SignatureVerificationException.php:28

Thank you


Faster promisification

Hey, you should consider a faster way to promisify functions when in Node. The current approach requires a closure each time and it's pretty slow'ish.
Alternatively, you can provide a hook so that people can provide their own promisification if they're using promise libraries like bluebird that already do this fast.

you should consider a faster way to promisify functions when in Node. The current approach requires a closure each time and it's pretty slow'ish.

What do you recommend?

https://github.com/sonnyp/polygoat/pull/4
Looks plenty fast, I don't think it can get any faster, but if you have a tip please let me know.
IMHO If you really need to run your code hundreds of thousands of time per seconds you probably shouldn't use promise anyway, nor callback for that matter and use a queue (assuming async code) in fact if you need to run IO operations at that speed there's probably something wrong with your infrastructure.

It's slow and the benchmark is bonkers, sorry. You can check @spion'd benchmarks at the bluebird repo or at his repo about it - and check promisify.js at bluebird for an implementation idea.

On 15 Apr 2016, at 09:56, Sonny Piers<EMAIL_ADDRESS>wrote:
#4
Looks plenty fast, I don't think it can get any faster, but if you have a tip please let me know.
IMHO If you really need to run your code hundreds of thousands of time per seconds you probably shouldn't use promise anyway, nor callback for that matter and use a queue (assuming async code) in fact if you need to run IO operations at that speed there's probably something wrong with your infrastructure.
—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub

It's slow

again; based on what? relative to what? for what use case?

the benchmark is bonkers, sorry

Maybe, I don't have much experience there but still I doubt "promisifying" will ever be anyone's bottleneck as it's usually done at runtime. Anyway if you could explain how/why the benchmark is bonkers that would be very helpful.

You can check @spion'd benchmarks at the bluebird repo or at his repo about it

I had a quick look, I'm sure it's a very fine benchmark and is probably much better than my naive benchmark but it's quite complex and I don't want to spend my time on something I simply see no benefit for (see above).

and check promisify.js at bluebird for an implementation idea.

Okay I did, the code is interesting, it uses eval / code generation by default and fallbacks to a closure. But again, at that scale, I really don't care if bluebird could "promisify" a few hundreds more functions per seconds than polygoat.

again; based on what? relative to what? for what use case?

Relative to how bluebird and other libraries promisify. Based on running closure based promisification vs dynamic compilation based promisification. For the use case of every library call ever - sure it's not a bottleneck usually but it's incurred on every library function call - if you call the library hundreds of thousands of times (think fs) in the server it amounts to a noticeable amount.
The more expensive an abstraction is the more likely a user will look for shortcuts around it so it is our duty as library makers to make an effort to avoid performance penalties when easy.

Thanks for the suggestion but again, at that scale, I really don't care if bluebird could "promisify" a few hundreds more functions per seconds than polygoat. Plus I don't want polygoat to grows into a hundreds of locs library (mostly for load time in browsers), that's why it doesn't require/include Promise polyfill

Fair enough, sacrificing performance for file size is a reasonable thing to do IMO.

On a different subject, do you have thoughts on https://github.com/sonnyp/polygoat/pull/2 (ignore the github conversation, checkout the reddit conversation for background)

@benjamingr the benchmark was indeed pretty broken, I fixed it in https://github.com/sonnyp/polygoat/commit/819871170d854738b6715f28d47b409a68c1cb99
bluebird is now faster than polygoat on Node.js but polygoat remains faster in browsers
https://github.com/sonnyp/polygoat/tree/master/benchmark
Still plenty fast but I might work on the eval trick and load it on Node.js only so that the file size doesn't increase, Could be fun.


IOs Coinbase issue

i have one issue in ios sdk i have put same line as which is in coinbase ios sample demo
CoinbaseErrorDomain" - code: 2
client.getAccountsList { (Array
:[AnyObject]!, helper:CoinbasePagingHelper!, error:NSError!) -> Void in
}
Error Domain=CoinbaseErrorDomain Code=2 "The operation couldn’t be completed. (CoinbaseErrorDomain error 2.)" UserInfo=0x14ede210 {response={
}, statusCode=403}

Sorry for the delayed response here, hope you were able to resolve this.

Sorry for the delayed response here, hope you were able to resolve this.


Removing classic theme from Sphinx conf.

This was preventing readthedocs.org from using the latest theme.
See #1025 for some context.

LGTM

w00t:


Telegram-bot-polling error

Bot works fine for first few instances. And later this error is thrown, bot stops working.
error: [polling_error] {"code":"EFATAL","message":"EFATAL: Telegram Bot Token not provided!"}.....infinitely
tried executing :     bot.on("polling_error", (msg) => console.log(msg));
but no response

Same thing here. Also related issue: https://github.com/yagop/node-telegram-bot-api/issues/868
I don't think this is getting fixed anytime soon since this issue lacks attention for few years already.

Umm, interesting. But the question is: Why do you launch multiple instances of the bot using Polling? If you are going to create several instances it is best to use the webhook to receive updates. Because with the polling you can only have one instance running at a time, in case you have several raised at the same time is when the error jumps the error connection.
Because in the end each instance is making requests to the Tg servers at the same time and creates a competition between the requests. And that's when Telegram can respond to one or another request, while the second one that arrives throws the error message.
That is why in the case of wanting to have several instances better to use webhook and then you can manually distribute your updates among your different instances.
What do you think about it?

Re-generate the bot token in BotFather, it worked for me and I hope it helps you.


update folder to generate arm subscription to subscriptionManagement2 for node.js

Automation for azure-sdk-for-python

Automation for azure-sdk-for-ruby

Automation for azure-sdk-for-js

Automation for azure-sdk-for-go

Automation for azure-sdk-for-java

Automation for azure-sdk-for-node

Can one of the admins verify this patch?

@sergey-shandar - can you please merge this PR.


Dependency diagram (fig 7.7) confusing

Fig 7.7 would benefit from using some UML notation for how the dependencies are implemented. The current diagram, at first glace, seems to indicate that the Application layer would have a dependency on the Infrastructure layer. There is indeed a relationship between the 2 layer; however, this should be indicated as an inversion of control where the Infrastructure layer implements an interface and injects the implementation. UML provides a connector standard that most developer should know to understand the type of relationship.

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

ID: 95f3dcd7-3220-e9cf-3ca6-90b1282410ec
Version Independent ID: 5a30bea5-326b-ea72-59ae-dfef1e190e4a
Content: Designing a DDD-oriented microservice
Content Source: docs/architecture/microservices/microservice-ddd-cqrs-patterns/ddd-oriented-microservice.md
Product: dotnet-architecture
Technology: microservices
GitHub Login: @nishanil
Microsoft Alias: nanil

I was almost to create the same issue, below the diagram from the "red book"


Add option to allow pylint to break the build when it finds any warnings

This tries to behave exactly as the equivalent functionality from flake8.
The main reason for this is because https://github.com/AlexeySanko/pybuilder_pylint_extended is not compatible with the latest version of pylint.
It also makes more sense for the built-in plugin to be able to do this.

Coverage increased (+0.07%) to 74.776% when pulling 35826685db14ba1a101bf28fae86fc164af00397 on mariusfeteanu:pylint_break_build into 64219f573b0086cc214813629ce54099c7702450 on pybuilder:master.

I have raised an issue to show why this is needed: #629

LGTM

@mariusteteanu thanks for you contribution, much appreciated.


Make Spring Security responseSkew configurable

What version of UAA are you running?
{
    "app": {
        "version": "4.24.0"
    },
}

How are you deploying UAA?
I am deploying UAA locally only using Tomcat 9
What did you do?
Our ADFS identity server clock skewed for more than 60 seconds and UAA starting failing with the following error:
Response issue time is either too old or with date in the future, skew 60, time 2019-02
-28T13:35:49.633Z
at org.springframework.security.saml.websso.WebSSOProfileConsumerImpl.processAuthenticationResponse(WebSSOProfileConsumerImpl.java:126)

What did you expect to see? What goal are you trying to achieve with the UAA?
We would like to extend the clock skew tolerance to 300 seconds but we couldn't find a knob to do this in uaa.yml

Relevant:

https://github.com/spring-projects/spring-security-saml/issues/206
https://stackoverflow.com/questions/25647925/spring-security-saml-time-difference-between-sp-and-idp

Closing due to inactivity.


Add to VS Code store

Genuinely awesome work. Is there anything I can do to help you get this on the extensions store? Would love to start using it through there.

hey @didier! thank you so much for your interest!
sorry for the delay, but I have finally managed to upload the beta version to the marketplace.
feel free to start using it and let me know if you have any feedback!


Metal files added to "Copy Bundle Resources" rather to "Compile Sources" build phase.

The files with extension .metal is type of "Metal Shader Source" which needs compilation build phase. At the moment files just added to "Copy Bundle Resources" build phase.
Hope it is easy to fix issue .)
Thank you!

It needs to be added here https://github.com/yonaskolb/XcodeGen/blob/461de39f8e7c837a78f5617bc4fc20d4d84267b7/Sources/XcodeGenKit/SourceGenerator.swift#L191 can you submit a PR?

Ok. I am finishing converting one project with Shaders. Then will make a fix and PR.

PR is ready and it passes tests. Please review and merge.
Thanks!


oras push doesn't support directory traversal

When demoing oras, I like to follow a sequence of:

oras push 1 file
oras pull 1 file
oras push 2 files
oras pull 2 files

When I pull files, I typically move into a sub directory.
To avoid having to cd download, cd ../ between each push/pull, I was trying to use the following:
oras push demo42.azurecr.io/samples/text:v2 \
        ../layer1.txt \
        ../layer2.txt

However, I received the following error:
Error: ../layer1.txt: path traversal disallowed
Not sure this is the highest priority, but curious if we think we should support path traversal.

nevermind


Upgraded Monolog from v1.12 to v1.24

I've upgraded the monolog/monolog package from v1.12 to v1.24.
This change will hopefully mean developers will be able to make use of new Monolog features like Telegram logging. #29119 is the issue related to this change.
I've done a straight upgrade with Composer. Let me know if there are any other changes that are required to do the upgrade.

Thanks for the PR, but the current version constraint already allows composer to install the latest 1.x release.

The issue you link to refers to upgrading to the upcoming monolog v2 release.


🛠 Wrong results using the parameter yearDivide to 'normal'.

fix #190

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

Project coverage is 97.83%. Comparing base (214bab2) to head (6c80375).

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@           Coverage Diff           @@
##             main     #191   +/-   ##
=======================================
  Coverage   97.82%   97.83%
=======================================
  Files          79       79
  Lines        1380     1384    +4
  Branches      226      227    +1
=======================================
+ Hits         1350     1354    +4
  Misses         26       26
  Partials        4        4

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


fix: Returns an error when public key is empty

Signed-off-by: Andrii Soluk<EMAIL_ADDRESS>

Codecov Report

Merging #52 (a91fb60) into main (670ca0e) will decrease coverage by 0.07%.
The diff coverage is 40.00%.

@@            Coverage Diff             @@
##             main      #52      +/-   ##
==========================================
- Coverage   86.49%   86.42%   -0.08%
==========================================
  Files          13       13
  Lines        1999     2003       +4
==========================================
+ Hits         1729     1731       +2
- Misses        156      157       +1
- Partials      114      115       +1

Impacted Files
Coverage Δ

cmd/vct/startcmd/start.go
85.75% <0.00%> (-0.53%)
:arrow_down:

pkg/controller/command/command.go
84.61% <100.00%> (+0.07%)
:arrow_up:

Continue to review full report at Codecov.

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


Update README.md for Copyright 2015

We appreciate the contribution but updating the copyright year in an existing file isn't necessary.


fix all warnings

My GCC compiler:
gcc -v                                                                                diary -> master !
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 13.0.0 (clang-13<IP_ADDRESS>)
Target: arm64-apple-darwin21.1.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Thanks a lot :rocket: || 'a' || bug was haunting me all day long!


Refactor Interface, Contact, etc to use Flat ABI

Motivation
Currently, we allow both nested and flat ABI.  However, this is causing our code to be harder to maintain.  Going forward, we should support the Flat ABI and refactor the code path.
The following are types that can be simplified.

[ ] ParamType
[ ] JsonFragment
[ ] FunctionFragment

Usage example
No response
Possible implementations
No response

Will this require updating the current code templates we use when generating Typescript files via fuelchain?

I am refactoring the whole type's generation stuff [...]

FYI — here are the templates on the new branch/PR I started.

The new typegen should cover the majority of improvements and fixes.
New proposals can be made in the future, but I'll close this one since it isn't clear enough.

My understanding: The general suggestion here seems to reduce the generated code by using more type helpers.


Challenge validation has failed (apache reverse proxy)

Hi
I'm trying to get a certificate for one of my sites and getting nowhere.
Some background information: my network structure is as stated behind an (CentOS 7.5) apache reverse proxy but it is also from a dyndns redirection !!! My ISP is blocking the port 80. From the past I was redirecting everything to port 8080 and it was working good. Now, because everything is going https I wanted to get letsencrypt certificates but because of port 80 being blocked and not having access to the DNS records I was hoping for tls_alpn-01.
I have setup dehydrated stuffs in /etc/dehydrated, created the hook.sh script from your example, created the domains.txt file for a single site and the config file with the required _USER, _GROUP, IP_VERSION, CA as staging, CHALLENGETYPE=tls-alpn-01, CONFIG_D=/etc/dehydrated/config, CERTDIR/$BASEDIR/certs, ALPNCERTDIR=$BASEDIR/alpn-certs, WELLKNOWN=/var/www/html/dehydrated/  RENEW_DELAY=60, KEY_ALGO=rsa. The hook.sh file was also modified to reflect my configuration, certs pointing to my self-signed certificates and httpd replacing nginx.
as root I ran
./dehydrated --register --accept-terms -f config/config
and then
./dehydrated -c -f config/config
with the following results
./dehydrated --register --accept-terms -f config/config
INFO: Using main config file config/config

Generating account key...
Registering account key with ACME server...
Done!

./dehydrated -c -f config/config
INFO: Using main config file config/config

Creating chain cache directory config/chains
Processing www.cloud.sdbl.homelinux.net
Creating new directory config/certs/sdbl_homelinux_net ...
Signing domains...
Generating private key...
Generating signing request...
Requesting new certificate order from CA...
Received 1 authorizations URLs from the CA
Handling authorization for www.cloud.sdbl.homelinux.net
Creating new directory config/alpn-certs ...
Generating ALPN certificate and key for www.cloud.sdbl.homelinux.net...
1 pending challenge(s)
Deploying challenge tokens...
Responding to challenge for www.cloud.sdbl.homelinux.net authorization...
Cleaning challenge tokens...
Challenge validation has failed :(
ERROR: Challenge is invalid! (returned: invalid) (result: {
"type": "tls-alpn-01",
"status": "invalid",
"error": {
"type": "urn:ietf:params:acme:error:unauthorized",
"detail": "Cannot negotiate ALPN protocol "acme-tls/1" for tls-alpn-01 challenge",
"status": 403
},
"url": "https://acme-staging-v02.api.letsencrypt.org/acme/challenge/0ukP1YqdR8nHWg39bPi-FmX7XzToodg2CYBhyfqgObc/213663690",
"token": "EYSgysjiytJxAGKGGWZ_pHIsSjrRotDT08O7hmoamYw",
"validationRecord": [
{
"hostname": "www.cloud.sdbl.homelinux.net",
"port": "443",
"addressesResolved": [
"<IP_ADDRESS>"
],
"addressUsed": "<IP_ADDRESS>"
}
]
})

I have some questions
1- Where the tls-responder.py should be running in my current configuration ?
on the proxy server or on the cloud server
2- Where should be created the /var/www/html/dehydrated directory ?
on the proxy server or on the cloud server
3- Because of the dyndns redirection, am I using the proper url
cloud.sdbl.homelinux.net (IP is setup here) or sdblcloud.webhop.net
Anyway, just hoping you can help me some.
Sylvain

For this you'll need a "web"-server (it could actually be a standalone TLS server) with TLS-ALPN support.
You can think of TLS-ALPN like a new kind of network protocol "port" where you have multiple services running on a normal TCP port, identified by name. acme-tls-requests have to be redirected to the tls-responder, everything else (like h2 for http2 iirc) to your normal webserver.
I have no idea if this works with just Apache, but you could install nginx as a proxy server in front of your apache server, just for handling TLS-ALPN.
The html/dehydrated directory is completely ignored for TLS-ALPN verification, it just has to exist so the initial config checks will work. Could just as well be /tmp for a TLS-ALPN-only setup.
Since this is not really an issue I'm closing this ticket. Feel free to ask questions anyway, I'll still get the notifications.


Fix for Cygwin support #65

Fix for https://github.com/ceylon/ceylon-common/issues/65

Can one of the admins verify this patch? (see README)

Tested on Win10/cyg64 for correctness and on Ubuntu for innocuity.

Thanks @fralalonde !


Compare

What & why
Build the frontend side of the compare page and links. This is currently split into 4 commits

the compare page itself
the link from the actions box at the top of the page
the description of parts and the updated header in the Document Content section of the page
a link to the compare page from the document section of the metrics page

There were some small linting issues in the original commit that are fixed in the subsequent one, but it's otherwise good to be used independently. There are no tests for the compare page (commit 1), and its route needs to change.
Commits 2 and 3 have tests against them although some of the logic provided by the helper in commit 3 may not be needed, depending on how much the api provides. Commit 4 relies on the helper in commit 3.

Closing this PR as doesn't need to be merged.


ERRAI-1108: Interrupt navigation without enforcing a redirect

This valid for onHiding, when we want to cancel the hiding of a page.

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.

ok to test

Can one of the admins verify this PR? Comment with 'ok to test' to start the build.


Is Sword Fish acquirable in Survival?

If not, how would I go about adding it to the rare resources crate loot table, maybe 1 in 10000 chance?

This is my first try at making a datapack, but I made a zip with \data\fishingrework\loot_tables\blocks\rare_resource_crate.json with the following in an attempt at this:
{   "type": "minecraft:block",   "pools": [ 	{ 	  "rolls": 3, 	  "entries": [ 		{ 		  "type": "minecraft:item", 		  "weight": 1, 		  "name": "minecraft:emerald_block" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 1, 		  "name": "minecraft:lapis_block" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 2, 		  "name": "minecraft:gold_block" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 2, 		  "name": "minecraft:iron_block" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 4, 		  "name": "minecraft:diamond" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 2, 		  "name": "minecraft:blaze_rod" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 3, 		  "name": "minecraft:ender_pearl" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 6, 		  "name": "minecraft:emerald" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 4, 		  "name": "minecraft:experience_bottle" 		}, 		{ 		  "type": "minecraft:item", 		  "weight": 0.0075, 		  "name": "fishingrework:sword_fish" 		} 	  ], 	  "conditions": [ 		{ 		  "condition": "minecraft:survives_explosion" 		} 	  ] 	}   ] }

Hey! That is correct that the swordfish is currently unobtainable as I wasn't sure where to slot it into the crates balance wise.
As for inserting datapacks I believe the way you have done it is correct but I sadly don't have much experience with it personally.
I would highly recommend trying to set the weight of the Swordfish to 1 instead and bump all other items up by one as such low odds would likely make it never obtainable.


Add DATE_STRING environment variable for builds

This PR adds the DATE_STRING environment variable which will be used in some upcoming conda recipe changes.
Assuming the changes work as intended, we should remove the conditional block of code and remove VERSION_SUFFIX in favor of DATE_STRING after the 23.02 release.

for reference, the export statement is on its own line to account for this shellcheck rule about dynamically computed variables: https://www.shellcheck.net/wiki/SC2155


Excessive Log Size in rc1

Describe the bug
It is known that the log sizes are fairly big - in the range of 5 to 10 MB per day.

for the case where Apple Health is enabled and then Dynamic Features are enabled, the log is more than doubled in size

Attach a Log
Tap the Trio settings icon at the bottom of the screen, then tap 'Share logs' on the bottom of the list and attach it to this ticket.

The log attached below did not have Apple Health enabled until 05:18 am.
Apple Health was later disabled at 22:00
The file size was 21.6 MB before it was compressed.

To Reproduce
Steps to reproduce the behavior:

Run Trio
Enable Apple Health
Turn on Dynamic Features
Share logs

Expected behavior
These HealthKitManagerdebug statements were added as part of trouble shooting and do not need to be present in rc1
Configuration:

Trio dev branch, commit 08eba438 (tag: 0.2.0-rc1)
SE phone running Nightscout as CGM and rPi DASH as pump

Log:
log_prev.txt.zip

Closed because PR #372 was merged


Replace locks with a concurrent queue

Locking to pass messages between threads is a performance bottleneck. Instead, we should replace this mechanism with a FIFO queue such as the ConcurrentQue which does not require thread locking.
https://docs.microsoft.com/en-us/dotnet/api/system.collections.concurrent.concurrentqueue-1?view=netframework-4.7.1
https://github.com/dave-hillier/disruptor-unity3d
What are your thoughts?

For now locking is not bottleneck of library. And ConcurrentQueue doesn't work in Unity with old mono.

Whats wrong with the source code example? Are you saying this implementation does not work?
https://github.com/dave-hillier/disruptor-unity3d/blob/master/DisruptorUnity3d/Assets/ConcurrentQueue.cs

@NVentimiglia with source code all ok. I don't want use other libraries with LiteNetLib.
ConcurrentQueue not always can be faster than locks. Look at benchmarks.


bytes: IndexByte performs poorly on short lookups

What version of Go are you using (go version)?
1.9
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/sasha/go"
GORACE=""
GOROOT="/usr/lib/go-1.9"
GOTOOLDIR="/usr/lib/go-1.9/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build547759744=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?
Benchmarking bytes.IndexByte vs loop character lookup

package main

import (
	"bytes"
	"strings"
	"testing"
)

const position = 3
const repeat = 10000

var data = []byte(strings.Repeat("1", position) + "\t" + "dsahfksdfhkdsj")

func BenchmarkIndexByte(b *testing.B) {
	for n := 0; n < b.N; n++ {
		for i := 0; i < repeat; i++ {
			if pos := bytes.IndexByte(data, '\t'); pos != position {
				b.Fatalf("Wrong position %d, %d expected", pos, position)
			}
		}
	}
}

func BenchmarkLoop(b *testing.B) {
	for n := 0; n < b.N; n++ {
		for i := 0; i < repeat; i++ {
			pos := -1
			for j, c := range data {
				if c == '\t' {
					pos = j
					break
				}
			}
			if pos != position {
				b.Fatalf("Wrong position %d, %d expected", pos, position)
			}
		}
	}
}

What did you expect to see?
BenchmarkIndexByte should be faster or at least close to BenchmarkLoop for any delimiter position.
What did you see instead?
But it can be several times slower when the delimeter is close to the data start (parameter position):

0thBenchmarkIndexByte-4   	   50000	     24888 ns/op
BenchmarkLoop-4        	  200000	      7421 ns/op

2thBenchmarkIndexByte-4   	   50000	     27334 ns/op
BenchmarkLoop-4        	  100000	     13582 ns/op

This matters because we are using IndexByte for log parsing via code generator and a good chunk of data pieces we are looking for are short.
It would be great if bytes.IndexByte would be faster at shorter lookups.

\cc @martisch

Interesting.
bytes.IndexByte is written in assembly. And it executes AVX2 instructions if the data length is more than 32. Otherwise, it goes with SSE instructions.
CMPQ BX, $32
JA avx2

Can it be because of this that when the data length is small, a loop code generates faster assembly than the hand-written one ? Would be interesting to look into the assembly of the generated loop code and compare them.

I do not see how we can make a generic implementation of bytes.IndexByte that will be (near) optimal on any length and distribution of match position if these characteristics are not known at compile time.
A solution that is good on a variety of lengths at runtime is complex and therefore will not be inlined to not bloat the binaries and fill the caches. Thereby always having call overhead and overhead to decide which code path to use based e.g. on string length or supported instructions.
The range loop in the example avoids that since it is known by profiling the application that the problem is mostly composed of short strings and early matches. The solution of the inlined range loop is simple enough that I think it does not warrant to add an e.g. IndexByteShort to the package. However writing a fast IndexByte for long strings is comparatively more complex.
It could be that the current version can be tuned a bit for shorter strings. For that we need to benchmark what possible room for optimization there is between an indexByte using a range loop that is not inlined and that checks for AVX2 and string length. Also making sure the range loop is not just better aligned in one benchmark than the other.

bytes.IndexByte is not inlined on amd64 while the range loop is.

@martisch
vendor_id	: GenuineIntel
cpu family	: 6
model		: 158
model name	: Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz
stepping	: 9
microcode	: 0x3a
cpu MHz		: 799.941
cache size	: 6144 KB
physical id	: 0
siblings	: 4
core id		: 1
cpu cores	: 4
apicid		: 2
initial apicid	: 2
fpu		: yes
fpu_exception	: yes
cpuid level	: 22
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch epb intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt xsaveopt xsavec xgetbv1 dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp
bugs		:
bogomips	: 7008.18
clflush size	: 64
cache_alignment	: 64
address sizes	: 39 bits physical, 48 bits virtual
power management:

Some more info

position = 5

BenchmarkIndexByte-4   	   50000	     27310 ns/op
BenchmarkLoop-4        	  100000	     22110 ns/op

position = 6
BenchmarkIndexByte-4   	   50000	     28276 ns/op
BenchmarkLoop-4        	   50000	     36982 ns/op

I.e. with position 5 current implementation is fast enough and it is faster at the length of 6. I just thought if there would be a cheap way to check if the first 4 bytes has a character needed, then some sort of loop would find it, otherwise the generic algorithm would be used.
Check and "short" lookup could be inlined.

Inlining a short lookup is not cost free as the binary size would increase which makes for more icache pressure and it slows down for positions further away.
Also in the current state of the compiler (no mid stack inlining) it complicates the compiler and makes the bytes package function special since the optimization with intrinsics would not recognize when the code is copied from the bytes package to somewhere else.
I think that when it is known that the position is usually found early the pre check by range loop optimization is good and easy to make explicitly in the code when profiling determines it matters at that call site.
If there are performance improvements left to make small lookups a bit faster within the code or in the generated instructions inside the index function that would be great to find out.

When I removing the inlining the difference goes away:
func BenchmarkLoopNoInline(b *testing.B) {
	for n := 0; n < b.N; n++ {
		for i := 0; i < repeat; i++ {
			pos := indexByte(data, '\t')
			if pos != position {
				b.Fatalf("Wrong position %d, %d expected", pos, position)
			}
		}
	}
}

//go:noinline
func indexByte(data []byte, ch byte) int {
	pos := -1
	for j, c := range data {
		if c == ch {
			pos = j
			break
		}
	}
	return pos
}

So I think we're mostly measuring call overhead here.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

@daiweisong that is very rude

@daiweisong, that is not constructive at all. Please refer to the code of conduct for how to engage in a productive and friendly manner. Thank you.


Persistent mode, take 3

This is a resurrection of #1438 with some improvements. In particular, the persistent build server supports building arbitrary targets and invoking arbitrary tools. Some changes in options will still cause it to decline a request and exit, but this is somewhat conservative and could be relaxed in the future.
This is a draft because Windows support still needs these improvements applied, and it would be nice to write some tests for the IPC implementation.

@jhasse, my team was discussing the need for this again today. Are you interested in reviewing? I can get a cleaned up version ready if so.


Nan-style require() for including headers

Let's take a cue from Nan and have a include_dirs.js file that allows compliers to use the following syntax when including libs and headers:
'<!(node -e \'require("hpp-skel")\')'

This is super helpful when we run into multiple versions of header files when things are installed with npm.
cc @springmeyer @GretaCB

Added in #8


Improve persistence layer

The following issues "common" problems are identified from #131, #133 and #150:

management of clients, channels and users require strong consistency
JVM is unacceptable dependency in constrained environments
messages need not to be permanently stored
deployment requires "pre-start" actions (e.g. creation of keyspaces, startup time)

Re-evaluation of architectural design decision, lead us to the following decisions:

Apache Cassandra will be dropped from the core platform
CockroachDB will be used as primary storage
if necessary, constrained deployments will replace it with BoltDB
messages will not be persisted
writer service will emit stream of normalized messages
streamed messages can later be used by analytics, rules engine or any other consumer

CockroachDB

https://www.cockroachlabs.com/blog/run-cockroachdb-on-a-raspberry-pi/
https://github.com/cockroachdb/docs/issues/1132
https://stackoverflow.com/questions/34978809/can-cockroachdb-run-on-raspberry-pi

Cocnlusions:

Targets 64-bit processors, without any tests/support for 32-bit
Tweeks are needed to put it on RPi
Recompilation is needed
There are no binaries or .deb packages for RPi
No Docker images prepared

PostgreSQL

https://www.raspberrypi.org/forums/viewtopic.php?t=5964
https://bpwalters.com/blog/setting-up-postgresql-on-raspberry-pi/
https://hub.docker.com/r/rotschopf/rpi-postgres/
https://www.enterprisedb.com/docs/en/9.3/pginstguide/PostgreSQL_Installation_Guide-04.htm

Conclusion:

Easy to install, even on RPi
Stable support for 32-bit
Provided Docker images for RPi
Lower HW requirements

Overall observation: having in mind that we do not need scalability on the Manager persistence component, because a single PostgreSQL will be capable to handle millions of entities (users, device and channles) and the fact that PostgreSQL has easier instalation on gateways, I am leaning to Postgres. Not to mention product maturity and tooling.
@mijicd @janko-isidorovic one thing to consider: currently auth is embedded in Manager and every req is checked upon Manager storage. How will this impact geographically spread deployments? Would CockroachDB multi-datacenter capability help reduce latencies here (even if we do not need a need for extra storage, maybe pure facst that we can sync geographically remote locations would help). I know that Postgres can be also spread, especially for reads, but never the less.

@drasko As you know, I was in favor of PostgreSQL from the beginning: it's capabilities are more than enough for Mainflux. Therefore, I wouldn't spend much time any more, solving problems that we don't even have. From the perspective of implementation, there's no difference anyhow, let's go with PostgreSQL and migrate to CockroachDB only if we need.

@mijicd fully agreed. Let's proceed with PostgreSQL, we'll see later if there is a need for switch. In any case, since both DB use Postgres Go driver, it should be trivial in-place replacement.


show note details on tap

The new project overview page will show note icons on timeline and have different functionality for note interaction.


Extension issue

Issue Type: Bug
Extension Name: vsliveshare-audio
Extension Version: 0.1.91
OS Version: Windows_NT x64 10.0.19043
VS Code version: 1.57.1

:warning: We have written the needed data into your clipboard. Please paste! :warning:

Closing and marking as a duplicate of #3808. Please try running the command >Live Share: Repair audio installation. You can also disable the audio extension so you can continue using Live Share without it.


Analyze Microsoft.UI.Xaml.UIElement properties for accuracy (A thru B)

All property content files in UIElement beginning with:
AccessKey: https://learn.microsoft.com/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.uielement.accesskey
And ending with:
BringIntoViewRequestedEvent: https://learn.microsoft.com/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.uielement.bringintoviewrequestedevent
What to look for:

Statements/code that were appropriate for UWP/WinUI 2, but are no longer accurate for WinUI 3/Windows App SDK
APIs that need more explanation or samples. Content for some properties is intentionally brief, as examples are available in other topics
Unnecessary/invalid links to UWP docs
Unnecessary/invalid links to WinUI 2 docs
References to UWP or WinUI 2
Mentions of Windows 8/8.1, whether they may need to be removed or just updated to be relevant for Win 10/11
Mentions of Windows Phone
Windows 10 is specified but it feels like Windows 11 is also applicable. (The text should either just specify "Windows" or "Windows 10 build xxxx and later" instead)

Closing issue from MVP Summit activity.


updating team page

removing inactive team members
not a high priority PR, review when you have time!

Going to leave him on the site for now.


Decoding the JWT

How can I decode the JWT in my application?
So for I have tried the following
token = "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE1Mzg1ODczMTIsInN1YiI6Mn0.iZS0BO8Pd8paLDkEsIXgs58xNgN3iyamkn7RI57xufU"
JWT.decode(token, Rails.application.secrets.secret_key_base, { algorithm: 'HS256' })
But I get an error Signature verification raised
What have I done wrong?

Sorry, my mistake. The token was expired


Emails not displaying properly - Only top half!

Please search to check for an existing issue (including closed issues, for which the fix may not have yet been released) before opening a new issue: https://github.com/k9mail/k-9/issues?q=is%3Aissue
Expected behavior
Tell us what should happen
An email should open and display properly!
Actual behavior
Tell us what happens instead
I get the top half of an email "wobbling" then solid, but no bottom half of the email. Sometimes if you close the email then reopen a few times it does display, but mostly not.
Steps to reproduce

Open email, top half wobbles then solid, but no bottom half.

Environment
K-9 Mail version:
5.206
Android version:
6.0.1
Account type (IMAP, POP3, WebDAV/Exchange):
IMAP

Every email? Or just a specific one. If it's just one then the source of the email would be useful

No, it seems to be a number of different sources which aren't related (By business anyway, don't know about format).
It's weird, when you open the email, the portion displayed kind of flickers or wobbles, you can occasionally see some of the rest of the message body but then usually ends up with half of the message.

If the email is mainly text, then it opens fine.
I have just opened one fine which wouldn't open properly earlier. Closed it then it only showed half again.
I just tried to video it but you can't see the flickering.
The tablet works fine for every other app, this only started happening seemingly after one of the recent updates.