[11.x] Add first/last directives to data_get helper

This PR adds special directives ^ (fetch first element) and $ (fetch last element) into data_get helper. These symbols were chosen as they mimic regexp anchors with similar meaning.
Reasoning
It is not unusual to use 0 to access first element; but there's no easy way to access last. Why do we even need that?
Here is the example:
<?php

$flight = [
    'segments' => [
        ['from' => 'LHR', 'departure' => '9:00', 'to' => 'IST', 'arrival' => '15:00'],
        ['from' => 'IST', 'departure' => '16:00', 'to' => 'PKX', 'arrival' => '20:00'],
    ],
];

// Departure airport of first flight segment - arrival airport of last flight segment
echo 'Route: '.data_get($flight, 'segments.^.from').' - '.data_get($flight, 'segments.$.to');
// Route: LHR - PKX

// Departure time of first flight segment - arrival time of last flight segment
echo 'Timespan: '.data_get($flight, 'segments.^.departure').' - '.data_get($flight, 'segments.$.arrival');
// Timespan: 9:00 - 20:00

Backwards compatibility
This feature breaks BC as when someone have arrays with ^/$ keys, they now need to be escaped during fetching:
<?php

$array = [
    'symbols' => [
        '$' => ['description' => 'dollar'],
        '*' => ['description' => 'asterisk'],
        '^' => ['description' => 'caret'],
    ],
];

echo data_get($array, 'symbols.\^.description');
// "caret"

// We can now also escape asterisk the same way: `\*`.
echo data_get($array, 'symbols.\*.description');
// "asterisk"

Implementation details
^/$ directives implemented using array_key_first/array_key_last functions respectively. So in most cases with numeric keys ^ is the same as 0. Anyway, I think we need to keep ^ directive for completeness.

@stevebauman this way it quickly becomes not-that-elegant when you have huge DTO with nested objects and arrays of objects, and you have no access to it as DTOs are declared in third-party package and is final...
Given example is very simplified, in real use case I have something like itineraries.^.flights.^.segments.^.locationBegin.code and worse.

I don't approve of this new feature, which adds to the cost of understanding. Complex functionality is recommended using collections.

this way it quickly becomes not-that-elegant when you have huge DTO with nested objects and arrays of objects, and you have no access to it as DTOs are declared in third-party package and is final...

Another use-case against final I see.

@huangdijia More collections means more memory usage. Also, you'll need to write separate traversal logic for every nested array/DTO structure.
But, I see your concerns. As alternative, we can get rid of ^ and use -1 instead of $. In many languages -1 means "last array element" (but not in PHP).
And lastly, * is even more complex functionality IMO.

As alternative, we can get rid of ^ and use -1 instead of $. In many languages -1 means "last array element" (but not in PHP).

-1 is a valid key in arrays though.
Since data_get allows you to pass in the key as an array it might be possible to add a class or enum to handle first/last elements. Maybe not as pretty as the initial suggestion but at least it won't cause any backward compatibility issues.
<?php

$flight = [
    'segments' => [
        ['from' => 'LHR', 'departure' => '9:00', 'to' => 'IST', 'arrival' => '15:00'],
        ['from' => 'IST', 'departure' => '16:00', 'to' => 'PKX', 'arrival' => '20:00'],
    ],
];

// Departure airport of first flight segment - arrival airport of last flight segment
echo 'Route: ' . data_get($flight, ['segments', Data::First, 'from']) . ' - ' . data_get($flight, ['segments', Data::Last, 'to']);
// Route: LHR - PKX

// Departure time of first flight segment - arrival time of last flight segment
echo 'Timespan: ' . data_get($flight, ['segments', Data::First, 'departure']) . ' - ' . data_get($flight, ['segments', Data::Last ,'arrival']);
// Timespan: 9:00 - 20:00

Updated this PR to use {first} and {last} as special keys.

Noice 👏

As this uses array_key_first / array_key_last so ArrayAccess objects or other objects will not work with {first} / {last} as I understand. Only "real" arrays.


VIM mode like sublime

Issue Type: Feature Request
Please add a VIM mode like sublime! I've tried many extentions and they don't behave like what im used to with sublime.
VS Code version: Code 1.52.1 (ea3859d4ba2f3e577a159bc91e3074c5d85c0523, 2020-12-16T16:34:46.910Z)
OS version: Windows_NT x64 10.0.19041

I vote against it. Your only argument is that it doesn't behave like in sublime without even explaining what it means. I personally don't want a vim mode which behaves like in sublime. I want a vim-mode which behaves like vim. For this there are already two great extensions.

https://github.com/VSCodeVim/Vim

which even implements many plugins. There is also

https://github.com/asvetliakov/vscode-neovim

which can't get closer to an authentic vim-mode because its using actual neovim under the hood.
Why not trying to make this two extensions better if you don't like something. The ground work is already done there. If you want a better vim-experience in vscode its much easier to implement it in this extensions then to implement a completely new vim-mode inside vscode.
Also who says that the build-in vim-mode would be better then those two extensions and that it would fulfill your sublime-requirements.
IMHO the issues which you currently have with this two extensions (which you never explained) should be addressed in this two extensions instead of wasting the devs time and trying to reinvent the wheel again.
If a vim-mode should ever be implemented in vscode there should be better very good reasons because its going to take a lot of time and resources from the devs.

@astier have you used the plug-ins yourself? Are you sure the existing shortcomings can be fixed without any help from the underlying platform?

I agree with @astier in that this is a poorly defined request and that the referenced plugins look promising. It may be worth instead discussing about support for modal editing within VSCode; or extending the existing keybinding features to better support modal editing workflows. Both plugins need to emulate vim to get the modal editing experience, which seems like it's less than ideal.

@domenukk Even if that's the case, then VSCode should instead focus on fixing the shortcomings of extensions instead of bloating the core platform with features only a tiny % of the userbase will use. The whole point of extensions is to accommodate niche use cases and workflows.

Agree with @RPGillespie6 regarding focusing on extensions. If anything I would prefer something like "Extensions Loadouts" so I could create groups of activated extensions for specific tasks or projects rather than having to load every extensions every time I open VSCode. This would be better than "Add More Vim".

@domenukk I used both of them. Currently I am using vscode-neovim. And while they surely are not perfect I don't see how it would help to implement them in core-vscode. The first goto-solution as I already said should be to try to fix the extensions. Only if this is not possible it should be considered to implement it in vscode.
Even if there are features which currently can not be implemented in extensions because of some shortcomings in vscode then first thing we should discuss is if this shortcomings in vscode can be fixed such that the extensions can implement the features which are needed.
So far nobody who voted for this issue gave any reason why a vim-mode should be implemented in vscode and why the issues/features cant be fixed/implemented in the extensions.

If the vim mode being suggested here was based on the behavior of vim rather than the behavior of Sublime's vim mode, I think this feature request would make a lot more sense.  Perhaps re-wording the feature request would be rational.  If there's flaws in the existing vim mode extensions that can't be resolved without help from the platform, those should probably be their own feature requests as an alternative to this one.

To give some context on why the existing vim extensions are perceived as lacking by many, there are performance issues that are (as far as I understand it) due to vim extensions sharing the extension host with all other extensions. Here is the related issue:
https://github.com/microsoft/vscode/issues/75627
The corresponding VSCodeVim issue is in the top 5 most upvoted issues of that extension:
https://github.com/VSCodeVim/Vim/issues/2021
While a native vim mode might not be the solution, the number of upvotes here hints that there is a real and widely perceived problem with the current state of modal editing in VSCode.

@dschuessler This is a good start. Fixing #75627 would go a long way and maybe even benefit other extensions too.

Since the original feature request is not very descriptive but the issue is getting a lot of attention, I will summarize some problems I observe with the two existing Vim extensions and to what extent I understand these problems to be problems of VSCode rather than of particular extensions.
TL;DR: Vim extensions are sluggish because the architecture of VSCode's extension host allows them to be interrupted by other extensions at any time. This possibly also explains some of the unreliable behavior of Vim extensions.
On the shortcomings of Vim extensions: Editing operations with Vim extensions are slow. On high workloads, I have witnessed typing lag up to two seconds. Also, I find them to be pretty unreliable. They often show surprising behavior that is hard to reproduce, mostly unsolicited edits and cursor movements.
On the role of VSCode concerning performance issues: @DanTup pointed out that the type command used by Vim extensions can be interrupted by other extensions. Extensions using this command are therefore vulnerable to performance issues in principle. Their performance will never be sufficient to guarantee a smooth operation because every other extension can slow them to a crawl at any time. This does not only concern Vim extensions but also the rust-analyzer extension for example. These problems are not hypothetical but a constant issue. Developers of Vim extensions acknowledge that the architecture of the extension host is at least partially responsible for this. (See this, this and this) According to @alexdima the VSCode team recognizes the problem but considers it too costly to fix at this time.
On the role of VSCode concerning reliability issues: @alexdima wrote here (emphasis mine):

By default the type command is implemented by us on the renderer. The Vim extension effectively overwrites it and at some later point (async from the point of view of the renderer) issues edits back to the renderer process. We have no idea that those edits have as root cause a certain keypress or that a long time has passed...

My understanding is this: When the renderer is not capable to determine the source of an edit, it follows that it is not capable to distinguish between edits of different extensions. It follows further that the renderer can not and does not put edits in a specific order. Since other extensions also issue edits (e.g. Prettier, Markdown All in One) this might explain unreliable behavior like this as a race condition. This is just one of many papercut problems I witnessed while using Vim extensions, most of which I am not able to reproduce due to their flaky, race-condition-like nature.
Why this should be fixed: I think the upvotes of this issue show two things:

There is a very large interest in a Vim mode for VSCode.
Vim extensions are currently unable to provide an acceptable user experience for Vim users. (Why else would someone upvote this issue despite the possibility to use a Vim extension?)

Given the current extension host architecture, it does not look like an acceptable Vim mode is possible. This effectively treats Vim users as second-class citizens. If they choose to use VSCode they have to deal with typing latencies and other performance problems that would likely be considered unacceptable for the native editing experience of any other editor. The situation also wears out extension developers who have to fight an uphill battle against performance problems.
How this could probably be fixed: Various proposals have been voiced in the discussions surrounding this issue:

Running each extension in a separate thread. @alexdima has written down some thoughts on how to achieve this here. Despite the refactoring effort, the main downside seems to be the performance implication of running n extension hosts.
Running some extensions in a separate thread. Very performance-sensitive extensions (e.g. those using the type command) could run in a high priority thread while extensions that do not rely on very low latency use the main extension host. @alexdima argued that this would be just a "bandaid" not addressing the root cause of bad extension performance. I think this argument presupposes a false dilemma. One can both acknowledge the low latency needs of some extensions and address the bad performance of others at the same time.
Implementing a Vim mode into VSCode itself. This is the proposal made by OP. Since it would be a non-generic solution it could be tailored to the needs of Vim users without any compromises. However, it goes against the spirit of addressing niche needs in extensions, is quite probably the most expensive option to develop and does not address the needs of other extensions that use the type command. (What about rust-analyzer? Dance? etc.)

I might be wrong but I understand the popularity of this issue less as a verbatim call to implement a Vim mode in VSCode directly but rather as a general expression of discontent with modal editing in VSCode. I wrote this down as groundwork for potential future discussion.
Disclaimer: I have neither worked on VSCode nor on any extension. My knowledge of the causes of this issue stems entirely from posts of other developers, whom I might have misunderstood or misrepresented. Feel free to correct me, I will happily edit this post.

Instead of implementing a specific multi modal system like VIM, which would require too much effort, it seems to me that it makes much more sense to focus on general issues that make those systems hard to implement properly with extensions.
Personally, I find the particular VIM system kinda outdated because of the verb-movement order, while movement-verb order can give real-time visual feedback before "committing" entire phrases. Also VIM is extremely opinionated, making it almost impossible to coexist with existent shortcuts/features at the same time.. which could make such additional mode a continues burden to maintain.

I know me criticizing VIM will not be popular in this thread, but my point was that I believe VIM is not inline with modern editor's features like multi-cursors/selection, common and custom shortcuts, etc.. and forcing it breaks existent editor's features at some extent, and that was for me the major pitfall of these VIM extension that I tried. Then I tried an extension that implements kakoune, which although I don't use any more, was for me the prove other systems are much more compatible/suitable with modern editors. How much of VIM should be integrated to somehow play nice with existent and future features of the editor? I suspect it is not a trivial question. Even if you hit a nice balance now, likelihood of realizing a VIM feature is becoming a pain to maintain with new features, is not small at all.

IMHO: Instead of implementing VIM mode, perhaps a better alternative would be supporting something like this:
https://marketplace.visualstudio.com/items?itemName=johtela.vscode-modaledit natively.
Implementing a general/ configurable modal editing framework, at least allows users to better configure how the functionality is handled for their taste, be it VIM, Emacs, or Kakoune keybindings.

Just use VIM if you want it so badly? I don't see a reason why it should be integrated into vscode?

Found this issue because both of the VIM extensions can be so buggy that I have to flat out disable them. Would LOVE VIM to be integrated into VSCode!

@dingolfsson I don't think you actually mean integrate. If you want to integrate vim into vscode you would have to use https://github.com/asvetliakov/vscode-neovim because as its descriptions says its a VSCode Neovim Integration but you said its buggy. What you actually mean is you want vim to be rewritten from scratch and implemented in vscode.
Also did you reported this bugs in the respective plugins? Because maybe it would be easier to just fix this bugs instead of rewriting vim in vscode. What makes you think a vim-rewrite would have less bugs than the current plugins.

@astier have you used the plug-ins yourself? Are you sure the existing shortcomings can be fixed without any help from the underlying platform?

If the current VSCode is lacking of APIs, it's definitely OK to add more. But this is far from enough to be a reason why VSCode should be bundled with a VIM-rewrite.

The latest Insiders Build, contains a new experimental setting that allows to execute the vim extension in a dedicated extension host process. It is supposed to alleviate the latency problems of Vim extensions.
Configure the following in your settings.json and then reload the window or restart:
"extensions.experimental.affinity": {
	"vscodevim.vim": 1,
	"asvetliakov.vscode-neovim": 1
},

See the announcement here: https://github.com/microsoft/vscode/issues/65876#issuecomment-1078827200

In the spirit of the announcement above, rather than implementing yet another extension, perhaps revisit some of the feature requests? Here is a feature request by the author of vscode-neovim. Implementing this would remove the need for many workarounds and fix bugs that are the result of this.

Jetbrains's IdeaVim is better. I often open JB’s IDE instead of vscode, although the IDE is very large and slow. There may be few people who need vim. Now VSCodevim has an annoying bug in the IME, and has not been fixed. For me, I need mode editing may not be consistent with VIM.
I always look at VSCode for some time, and experience. This time the Code-Server looks great, but VSCodeVim's IME BUG has not been fixed yet. It is a pity.

Try this: https://www.youtube.com/watch?v=-txKSRn0qeA
It work great for me!

In the spirit of the announcement above, rather than implementing yet another extension, perhaps revisit some of the feature requests? Here is a feature request by the author of vscode-neovim. Implementing this would remove the need for many workarounds and fix bugs that are the result of this.

I totally second this. Can someone please reopen that issue "kind of counting" the upvotes on this issue "give me vim power" to the vim-extension's finding of a shortcoming in the platform, which would allow adding "vim power" as opt-in with a clean platform form the people that want it?
Can this issue be used as a "collection / check list" of specific issues that are necessary to be added, instead of an overall "add a mode to the platform itself"?

I don't utilize VIM myself, for the most part in view of terminal and difficult to-leave issues. In the event that it is ever a console easy route, imagine a scenario where I press it coincidentally. How might I at any point exit out of it? So this will create issues to individuals who don't utilize VIM. Leave an abhorrence on the off chance that you have something similar (on the actual issue, not this remark).

You don't even explain what sublime looks like. As for me, vscode-neovim is an excellent plugin, and it fullfills most abilities of neovim. Plugins like hop.nvim, nvim-surround  and vimtex are perfectly supported. A builtin vim is certainly more efficient, but that would make vscode another gui front of vim,  and I don't think that's impossible.


Added EBML ID generator utility function

This should make expanding schemata easier.

Sorry, I didn't see this review request until now.
One question: we're not supporting Python2 anymore, right?

@CrepeGoat

One question: we're not supporting Python2 anymore, right?

Not actively, and not here. The Python 2 compatible version has been split off into a separate repo: https://github.com/MideTechnology/ebmlite-python2. We might update it if a critical bug is found and we need to do a new build of Lab 2.1.x, but I don't think we're going to port new features. That version of ebmlite is legacy.

So, the unit tests are failing on travis because there's an f-string in one of the new unit tests.  Do we want to keep supporting 3.5 with new versions?
Related, we might want to add 3.9 to the normal tests, since it's now officially released.

So, the unit tests are failing on travis because there's an f-string in one of the new unit tests. Do we want to keep supporting 3.5 with new versions?

Oops. I'd like to maintain compatibility with somewhat older Python 3. Fixed in commit c627b9b80447b1ce19fd27f3e8bc2f3ac3824fc9.

Related, we might want to add 3.9 to the normal tests, since it's now officially released.

Probably a good idea.

Codecov Report

Merging #56 (7f3d5d3) into development (da24ec6) will decrease coverage by 0.10%.
The diff coverage is 54.83%.

@@               Coverage Diff               @@
##           development      #56      +/-   ##
===============================================
- Coverage        62.85%   62.75%   -0.11%
===============================================
  Files                8        8
  Lines             1217     1227      +10
===============================================
+ Hits               765      770       +5
- Misses             452      457       +5

Impacted Files
Coverage Δ

ebmlite/util.py
62.89% <54.83%> (-1.51%)
:arrow_down:

ebmlite/core.py
76.54% <0.00%> (-0.44%)
:arrow_down:

ebmlite/threaded_file.py
0.00% <0.00%> (ø)

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 da24ec6...7f3d5d3. Read the comment docs.

Do we want to keep supporting [Python] 3.5...?

@StokesMIDE @CFlaniganMide just for the record, it hit end-of-life 6 months ago -> ¯\_(ツ)_/¯ I don't think we have any obligation to support it
https://endoflife.date/python

Do we want to keep supporting [Python] 3.5...?

@StokesMIDE @CFlaniganMide just for the record, it hit end-of-life 6 months ago -> ¯_(ツ)_/¯ I don't think we have any obligation to support it
https://endoflife.date/python

I agree that we don't have any obligation to support it, and if something happened that made it really difficult then I might advocate dropping support.  As it stands, I don't see a reason not to support it.


feedback: Project-Specific Chat Option

Version
1.2.1
Areas for Improvement

[ ] UI/UX
[ ] Onboarding
[ ] Docs
[X] Chat
[ ] Commands
[ ] Context
[ ] Response Quality
[ ] Other

What needs to be improved? Please describe how this affects the user experience.
Currently, it seems that the chats are global. When I open any project, I see all the chats, even from other projects.
Describe the solution you'd like to see
It would be useful for the chats to be specific to the open project or at least to have an option to determine whether a new chat should be considered global or project-specific.
Describe any alternatives that could be considered
No response
Additional context
No response

Yes! This should be obvious. At first I thought this is how it worked. I mean, it is aaaaaallll about context. The whole point of Cody is (should be) to really always be in the context of the current project, no matter what, no distractions, no side-quests, no hallucinations, no other "ideas".


Update host-config.md

Feature or Problem

Update document for host configuration
Related Issues

https://github.com/wasmCloud/wasmCloud/commit/3fb60eeca9e122f245b60885bdf13082c3697f04
Release Information

next
Consumer Impact

Testing

Unit Test(s)

Acceptance or Integration

Manual Verification

Thank you, @peter-jerry-ye! Nice find.
@brooksmtownsend is this something we could generate from the host binary/clap?

@lachieh absolutely, same thing that @ericgregory did for wash 😄

Added an issue! wasmCloud/wasmcloud.com#597


Setup/DBconnection

impl DB connection
made rough frontend to check backend

additionally changed openapi-generator-cli version latest -> v7.5.0


incompatible with gulp

there is a gulp extension, called gulp-jspm. It uses this module. due to gulp multithreading nature, process.exit event is called for each gulp task, not for node.js process termination.
Example gulp config from spring: gulpfile.zip
actual scenario (3 concurrent threads):
[1] jspm-main started
TempFile1 is created, temp.filesToDelete=[TempFile1], temp listener initialized
[2] jspm-maps started
TempFile2 is created, temp.filesToDelete=[TempFile1, TempFile2]
[3] jspm-admin started
TempFile3 is created, temp.filesToDelete=[TempFile1, TempFile2, TempFile3]
[2] jspm-maps processing
[2] jspm-maps finished
process.exit event called, cleanupFilesSync deleting ALL 3 TEMP FILES! TempFile1, TempFile2, TempFile3 instead of just TempFile2
[3] jspm-admin processing
ERROR: file TempFile3 not found
[1] jspm-main processing
ERROR: file TempFile1 not found
In short, temp module (with it's state filesToDelete) is global to all 3 gulp tasks which leads to conflicts.
Yes, there is a workaround: DO NOT execute jspm gulp tasks in parallel. But it's a gulp main feature. You would just use grunt or pure npm otherwise.
I suggest a fix. Just change temp module functions to:
function deleteFileOnExit(filePath) {
  if (!tracking) return false;
  var onExit = function() {
    rimrafSync(filePath);
  };
  process.addListener('exit', onExit);
}

function deleteDirOnExit(dirPath) {
  if (!tracking) return false;
  var onExit = function() {
    rimrafSync(dirPath);
  };
  process.addListener('exit', onExit);
}

It would work for all environments, standalone, grunt, gulp, you name it.
replace current functionality completely or just add new functions like track2/open2 with suggested functionality

I think I just struck this.

@OverDrone would you be able to create a PR?


Looking to include PortableGL in LVGL - roadmap for v1.0?

I'm looking to include PortableGL as a widget in the embedded graphics/UI library LVGL. I'm not a maintainer there; will just make a pull request once I get it properly implemented. My initial proof-of-concept tests are looking pretty promising and I really appreciate how easy it's been using PortableGL for this.
I noticed that the version number being used for PGL is 0.96. Are there any additional features you are looking to implement in order to call it 1.0? If it's embedded in a toolkit such at LVGL, it might be nice to use a "feature complete" version as it will likely get updated less frequently than your source tree. Thanks again for your efforts on this project; it's been a lot of fun to play with.

Thanks for the compliment, always nice to hear about people using or even thinking about using PortableGL.
Yeah, I haven't been super diligent or strict with my numbering scheme.  My initial goals for 1.0 included the things in the TODO list of the README:
Render to texture
More texture formats (specifically 1, 2, and 3 channel images)
More exhaustive regression tests, ongoing
Logo
etc.
I don't think there's anything there that is really critical or that you need to be used in LVGL.  The bigger issue for most LVGL applications is probably memory use.  32 bit RGBA color buffer + a float z buffer adds up even for tiny screens.  However it's written in such a way that it wouldn't be too much effort to convert it to use a smaller pixel format.
As far as waiting for a "feature complete" PGL, I don't think there's any need.  If I continue at the rate I'm going or even a little faster in the new year, I still probably won't be creating new official releases faster than LVGL's release schedule.  Best case scenario I reach 1.0 sometime next summer.

Excellent, thanks. I'll keep picking away at it as I have time. As for memory use, no, I don't expect many will end up using PGL in the embedded space. However, I'm using it in an environment where memory isn't a concern, so it will be pretty handy.


fix: update docker k8s hooks

trying to deploy with helm i received the error below.
i looked for qgt-0.2.15 in the docker hub and i didn't see it there
i did see qgt-0.2.12, and when i made this change the deployment worked

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


[WIP] [Idea] Assoc macro

This demonstrates the idea of an assoc macro which removes the need to specify  | Ecto.Association.NotLoaded.t() on every single "association" field.

This should not be merged.
I edited an existing test because this project is very new to me.
A new test should be written.
Moreover, the assoc function lacks docs.

This is not necessary. See https://github.com/elixir-typed-structor/typed_structor/issues/14#issuecomment-2261808440


Numbers

Hey,
what is the quickest way to show numbers on the display?
Thanks

no clue. it is a graphical display, so you have to render them yourself, probably images from SD-Card.


Clean up script dependency resolution

It's necessary to arrange to init classpath. We check and add an additional path in a strange way.


Mainnet state mismatch

Describe the bug

It appeared on 17.10.2022 on the test machine run after commit ef9f9a4. It's a potential regression.
To Reproduce
Steps to reproduce the behavior:

checkout commit ef9f9a4
Run forest on mainnet for some time
Hopefully see the error

Log output

Log Output
2022-10-17T17:25:24.456Z INFO  forest::daemon > Starting Forest daemon, version 0.4.1+git.ef9f9a4
2022-10-17T17:25:24.456Z INFO  forest_libp2p::service > Recovered libp2p keypair from "/opt/forest/libp2p/keypair"
2022-10-17T17:25:24.456Z INFO  forest::daemon         > PeerId: 12D3KooWQwtGB2d5Z5SbiLXD8KKWWoSZax9jWJa2LtXgg2xKeEm9
2022-10-17T17:25:24.457Z WARN  forest::daemon         > Warning: Keystore encryption disabled!
2022-10-17T17:25:24.457Z INFO  forest::daemon         > Prometheus server started at <IP_ADDRESS>:6116
2022-10-17T17:25:24.457Z INFO  forest::daemon         > Admin token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJBbGxvdyI6WyJyZWFkIiwid3JpdGUiLCJzaWduIiwiYWRtaW4iXX0.BM22GMXwD6Se98Q-g6Vj1iFKB72RD5X8qlmWc_6urf8
2022-10-17T17:25:25.360Z INFO  forest_genesis         > Initialized genesis: BlockHeader: Cid(bafy2bzacecnamqgqmifpluoeldx7zzglxcljo6oja4vrmtj7432rphldpdmm2)
2022-10-17T17:25:25.360Z INFO  forest::daemon         > Using network :: testnetnet
2022-10-17T17:25:25.363Z INFO  forest_chain_sync::chain_muxer > Evaluating network head...
2022-10-17T17:25:25.363Z INFO  forest::daemon                 > JSON-RPC endpoint started at <IP_ADDRESS>:1234
2022-10-17T17:25:25.363Z INFO  forest_rpc                     > Ready for RPC connections
2022-10-17T17:25:26.686Z INFO  forest_chain_sync::chain_muxer > Local node is behind the network, starting BOOTSTRAP from LOCAL_HEAD = 2256489 -> NETWORK_HEAD = 2257370
2022-10-17T17:25:27.561Z INFO  forest_chain_sync::tipset_syncer > Validating tipset: EPOCH = 2256489
2022-10-17T17:25:27.695Z INFO  forest_chain_sync::tipset_syncer > Validating tipset: EPOCH = 2256490
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
Downloading headers 0 / 881 [-----------------------------------] 0.00 % 0.00/s
Downloading headers 622 / 881 [==================>-------] 70.60 % 1240.76/s 0s
Downloading headers 881 / 881 [============================] 100.00 % 1106.59/s
Downloading headers 881 / 881 [============================] 100.00 % 1106.55/s Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Failed to print state-diff: Cid does not exist in blockstore
Failed to print state-diff: Cid does not exist in blockstore
Failed to print state-diff: Cid does not exist in blockstore
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
Failed to print state-diff: Cid does not exist in blockstore
Failed to print state-diff: Cid does not exist in blockstore
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
StateDiff:
Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
Failed to print state-diff: Cid does not exist in blockstore
Failed to print state-diff: Cid does not exist in blockstore
Failed to print state-diff: Cid does not exist in blockstore
Could not resolve actor states: failed to find state tree bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
Using default resolution:
Failed to print state-diff: Cid does not exist in blockstore
2022-10-17T17:26:09.279Z WARN  forest_chain_sync::tipset_syncer > Validating block [CID = bafy2bzacecgtzq7gzsyqfmcia2enuxwzzjpfbmcmj3274swsjbaxeszbu3ufy] in EPOCH = 2256490 failed: Validation error: Validation error: Parent state root did not match computed state: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72 (header), bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum (computed)
2022-10-17T17:26:09.279Z ERROR forest_chain_sync::tipset_syncer > Sync messages check state failed for tipset range
2022-10-17T17:26:09.279Z ERROR forest_chain_sync::chain_muxer   > Bootstrapping failed, re-evaluating the network head to retry the bootstrap. Error = TipsetRangeSyncer(Validation("Validation error: Parent state root did not match computed state: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72 (header), bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum (computed)"))
2022-10-17T17:26:09.279Z INFO  forest_chain_sync::chain_muxer   > Evaluating network head...
2022-10-17T17:26:15.923Z INFO  forest_chain_sync::chain_muxer   > Local node is behind the network, starting BOOTSTRAP from LOCAL_HEAD = 2256489 -> NETWORK_HEAD = 2257372
2022-10-17T17:26:15.929Z ERROR forest_chain_sync::chain_muxer   > Bootstrapping failed, re-evaluating the network head to retry the bootstrap. Error = TipsetRangeSyncer(TipsetRangeWithBadBlock(Cid(bafy2bzacecgtzq7gzsyqfmcia2enuxwzzjpfbmcmj3274swsjbaxeszbu3ufy), "Validation error: Validation error: Parent state root did not match computed state: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72 (header), bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum (computed)"))
2022-10-17T17:26:15.929Z INFO  forest_chain_sync::chain_muxer   > Evaluating network head...
2022-10-17T17:26:33.053Z INFO  forest_chain_sync::chain_muxer   > Local node is behind the network, starting BOOTSTRAP from LOCAL_HEAD = 2256489 -> NETWORK_HEAD = 2257373

Expected behaviour

No state mismatches
Screenshots

Environment (please complete the following information):

OS: Fedora 36
Rust version(e.g. `rustc --version)  https://github.com/ChainSafe/forest/blob/main/rust-toolchain.toml
Branch/commit ef9f9a4 (main)

Other information and links

I tried syncing with Forest from October 3rd and it still failed at epoch 2256490. The problem must have been around for a while. We just didn't hit it before now.

It happened again around epoch 2293820
forest-mainnet_2022-10-31T20 21 25_forest.txt

I've uploaded in our DO spaces two snasphots just a few epochs after the two state mismatches:

minimal_finality_stateroots_2257200_2022-10-17_16-00-00.car
minimal_finality_stateroots_2294400_2022-10-30_14-00-00.car

Managed to see a prettier diff for the most recent one.

I'm having some difficulties to reproduce same root hash than in the log file with those snapshots. After loading it, I'm using for verification:
$ ./target/release/forest --target-peer-count 50 --encrypt-keystore false --import-snapshot ../../Snapshots/minimal_finality_stateroots_2257200_2022-10-17_16-00-00.car --skip-load --height 2256489 --halt-after-import
 2022-11-07T10:15:13.557Z INFO  forest::daemon > Starting Forest daemon, version 0.4.1+git.ef9f9a44
 2022-11-07T10:15:13.558Z INFO  forest_libp2p::service > Recovered libp2p keypair from "/Users/guillaume/Library/Application Support/com.ChainSafe.Forest/libp2p/keypair"
 2022-11-07T10:15:13.558Z INFO  forest::daemon         > PeerId: 12D3KooWJVSvSTvEPFVTQ2wnqxM4FqtNKRo9yCqJUUeLnje7ep5T
 2022-11-07T10:15:13.558Z WARN  forest::daemon         > Warning: Keystore encryption disabled!
 2022-11-07T10:15:13.558Z INFO  forest::daemon         > Prometheus server started at <IP_ADDRESS>:6116
 2022-11-07T10:15:13.559Z INFO  forest::daemon         > Admin token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJBbGxvdyI6WyJyZWFkIiwid3JpdGUiLCJzaWduIiwiYWRtaW4iXX0.o9UZcbp9ezMKCUT4HDbLG0LlFjHQwda5bmW7Ce_43RA
 2022-11-07T10:15:13.761Z INFO  forest_genesis         > Initialized genesis: BlockHeader: Cid(bafy2bzacecnamqgqmifpluoeldx7zzglxcljo6oja4vrmtj7432rphldpdmm2)
 2022-11-07T10:15:13.762Z INFO  forest::daemon         > Using network :: testnetnet
 2022-11-07T10:15:13.763Z INFO  forest_genesis         > Importing chain from snapshot at: ../../Snapshots/minimal_finality_stateroots_2257200_2022-10-17_16-00-00.car
 2022-11-07T10:15:13.764Z INFO  forest_genesis         > Reading file...
 2022-11-07T10:15:13.764Z INFO  forest_chain_sync::chain_muxer > Evaluating network head...
 2022-11-07T10:15:13.764Z INFO  forest::daemon                 > JSON-RPC endpoint started at <IP_ADDRESS>:1234
Importing snapshot 1 B / 86.35 GB [>---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 0.00 % 4.40 KB/s 343242m  2022-11-07T10:15:13.764Z INFO  forest_rpc                     > Ready for RPC connections
Importing snapshot 86.35 GB / 86.35 GB [=============================================================================================================================================================================================] 100.00 % 311.52 TB/s  2022-11-07T10:15:13.764Z INFO  forest_genesis                 > Validating imported chain from height: 2256489
 2022-11-07T10:15:15.135Z INFO  forest_state_manager           > Computing state (height: 2256489, ts=[Cid(bafy2bzaceaxkxrkacr3zg4c4lrplc3rxgigahpbcel3u235srkegt7b3bnrg6), Cid(bafy2bzacedrnmek3uxf6pu4h5oaqkfqtdzwjolsz6g345qr7xpwnu2wha6tou), Cid(bafy2bzaceds6oczifux46kqu6wogcdbyqohjin2nk3kp4n4t5olg427brskh4), Cid(bafy2bzaceakmxsz4ibs6gql6emvk6tymnegdswnmusp3cc5p74t46mxccilx6), Cid(bafy2bzacecibkiqpoymo5tedy4t6flr2wp7p7aunuq2h7a5nvxbhoxksxrpoy), Cid(bafy2bzacecuwargppyb7roctxk6tsgcutez7b47vy53fbtrtip2p2cxtnuqjw)])
StateDiff:
  Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
  Root: bafy2bzaceak4v3wjaz3eb7xnyeziglovuidrglgroctnuini6lab5m2kepkki

I'm getting bafy2bzaceak4v3wjaz3eb7xnyeziglovuidrglgroctnuini6lab5m2kepkki instead of bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum.
Besides, If I start to validate the chain a few epochs before, ie 2256400, it still leads to state mismatches which I was not expecting at all.
I did this experiment with the more recent snapshot as well and I'm seeing same behavior.
Any ideas? Looks quite wrong to me.

Epochs 2315480 to 2316480 validate without problem.

I've narrowed down the issue with EPOCH 2293819 to this message: https://filfox.info/en/message/bafy2bzacecg3nnswiqu7zhk7tdqosp6mpmp2mcapty7iwzf2jn2ovisopk57s
The smart-contract fails with ErrIllegalArgument and we somehow charge an incorrect amount of gas.

I can finally reproduce the first mismatch now!
$ ./target/release/forest --target-peer-count 50 --encrypt-keystore false --import-snapshot minimal_finality_stateroots_2257200_2022-10-17_16-00-00.car --halt-after-import --skip-load --height 2256480
 2022-11-14T16:46:19.214Z INFO  forest > Using default mainnet config
 2022-11-14T16:46:19.215Z INFO  forest::daemon > Starting Forest daemon, version 0.4.1+git.a63667c7
 2022-11-14T16:46:19.216Z INFO  forest_libp2p::service > Recovered libp2p keypair from "/Users/guillaume/Library/Application Support/com.ChainSafe.Forest/libp2p/keypair"
 2022-11-14T16:46:19.216Z INFO  forest::daemon         > PeerId: 12D3KooWQJic96UrJzWxzYn7vbTxy43VGqp76pwtKTdJyyDcVZUD
 2022-11-14T16:46:19.216Z WARN  forest::daemon         > Warning: Keystore encryption disabled!
 2022-11-14T16:46:19.216Z INFO  forest::daemon         > Prometheus server started at <IP_ADDRESS>:6116
 2022-11-14T16:46:19.216Z INFO  forest::daemon         > Admin token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJBbGxvdyI6WyJyZWFkIiwid3JpdGUiLCJzaWduIiwiYWRtaW4iXSwiZXhwIjoxNjczNjI4Mzc5fQ.RjBEYuOf9cQjHOv6fL43Yq5Nxt3Ec35vXuyBwh48EeI
 2022-11-14T16:46:20.128Z INFO  forest_genesis         > Initialized genesis: BlockHeader: Cid(bafy2bzacecnamqgqmifpluoeldx7zzglxcljo6oja4vrmtj7432rphldpdmm2)
 2022-11-14T16:46:20.128Z INFO  forest::daemon         > Using network :: mainnet
 2022-11-14T16:46:20.133Z INFO  forest::daemon         > JSON-RPC endpoint started at <IP_ADDRESS>:1234
 2022-11-14T16:46:20.133Z INFO  forest_chain_sync::chain_muxer > Evaluating network head...
 2022-11-14T16:46:20.133Z INFO  forest_rpc                     > Ready for RPC connections
 2022-11-14T16:46:20.434Z INFO  forest_genesis                 > Importing chain from snapshot at: minimal_finality_stateroots_2257200_2022-10-17_16-00-00.car
 2022-11-14T16:46:20.434Z INFO  forest_genesis                 > Reading file...
Importing snapshot 86.35 GB / 86.35 GB [=============================================================================================================================================================================================] 100.00 % 229.36 TB/s  2022-11-14T16:46:20.435Z INFO  forest_genesis                 > Loaded .car file in 0s
 2022-11-14T16:46:20.435Z INFO  forest_genesis                 > Validating imported chain from height: 2256480
 2022-11-14T16:46:21.527Z INFO  forest_state_manager           > Computing state (height: 2256480, ts=[Cid(bafy2bzacec4qdmkecot6zid3kxvmuhw3gs3jybaxbbzc7mt66monqheapljhq), Cid(bafy2bzaced3kzkxe35uezddhv472epmzzny55tfhr5ulzcqtnsogsy3osjlt4), Cid(bafy2bzacecalucyesfene2sw52wgvqaqvuchphmx2cohec7nw26s7kanrwsmo), Cid(bafy2bzaceaygpyuwvpwj6writaoolkn6rwngat66fzyuo46bhtfgflgdckzpq), Cid(bafy2bzacecr4yvdfwfptvdm76ko5544itn2lxy575in3nprnkzinbdxgw7qmw), Cid(bafy2bzacecouqcy56tv6nylseuulygiyero7hhyfm6zjgv5sdh3vks5g2d4ha), Cid(bafy2bzaceakwup5ee32uwht4fess56i5mihgojiuqysdfmatkovsq7kh3ygak)])
 2022-11-14T16:46:34.284Z INFO  forest_state_manager           > Computing state (height: 2256481, ts=[Cid(bafy2bzacea7xzbtvav2e4ukh5sq6ka2uyec2xlvgbediettilwkkwbptpp7k6), Cid(bafy2bzacecsl7sdyjwwe3zfdo3o22jg4ymn2p7xe3saoj44kjg5r7lmclnqeg), Cid(bafy2bzacectnlktgnlw2ck7mmombso6ed5cbqx6yyugusksdb24csgfetbnik), Cid(bafy2bzaceaoaoekki3xvo2seowsftr7imjf2r7m2qniapbl2vvic64glmpmkw), Cid(bafy2bzacedzinwhdhtdkd625alsmudy6265qyzutfzfylz5tng7acaxjgyjvy), Cid(bafy2bzacebydxzyhrahlokbccry3uqpxlwkj7vrozf5j6qyolvwcc3nypvuo6), Cid(bafy2bzacebstm2ydm3ok5lpkt4hxvsm46c6bv6taux4xbwrw5gxzh5xyfnqwk)])
 2022-11-14T16:46:40.760Z INFO  forest_state_manager           > Computing state (height: 2256482, ts=[Cid(bafy2bzaceau3ipf2adeacwr32zwldvy7awdb4ktvpzzimrldtzogvsepwguww), Cid(bafy2bzacea3h6qxczmgif2ue6k3dgmdruovfszgozlw7fe437jhz63jzexzr4), Cid(bafy2bzaced3cqaihh3st2khgok437ektpr5wbkbumdt3eshjoetsnhwtqyj74), Cid(bafy2bzacedtxu7fkegx3brcazlrhuogpoyuptuz5oke5e6z2qyxx52jdv3myw), Cid(bafy2bzacecw3d2rzlp2yr25ebcf7dq4axrvywi4cbazyx2sjztil5rbt5fqba)])
 2022-11-14T16:46:54.301Z INFO  forest_state_manager           > Computing state (height: 2256483, ts=[Cid(bafy2bzaceb35o2thunh4v47weblfemmopx7rxcs266vj7b5r5o4huklfzqfzs), Cid(bafy2bzaceb72homm3uqeu4n2lr7iu2lzobjm5x7rgraphn24levulbubp5kme)])
 2022-11-14T16:46:59.252Z INFO  forest_state_manager           > Computing state (height: 2256484, ts=[Cid(bafy2bzacec3hv4n4vdcexi2ajp2pmyayn7zguooh7lukxgh2sffhidkwpq2km), Cid(bafy2bzacedskmuoozuukhughdpkdt24hnf5kxbzsrxhgkaochp5zpav6526js), Cid(bafy2bzacedj5lypnws6uzpzdbmtffvv6jrjqkhavdg7xogdxydq5mu2imraoq), Cid(bafy2bzacec7fa4y6lovd6hvwdrze7ugryva3hsl7fuqantwrcwiw7s6kmebuy), Cid(bafy2bzacecwpbtbluhukb5yt7wzdytm6bv4rsesrgs4a5yszsncucgppxbkow)])
 2022-11-14T16:47:05.081Z INFO  forest_state_manager           > Computing state (height: 2256485, ts=[Cid(bafy2bzacebiqq55xhh4oorhgynp3xu66mteypmh3js2wjl2ujtz6r4iwcxmto), Cid(bafy2bzacea4x6ivlajuseygespzlas2aqasujwttutuevc2g4m5dgy5pjrsay), Cid(bafy2bzacedv23cc7itfaq4n6p2a5pvapwe2suej644jpp6cgt5xa427h7avp4), Cid(bafy2bzaceddtunqng27zwtopwrdrxjc7grhq72dxz33xhgq7ckceuyteoorgy)])
 2022-11-14T16:47:10.626Z INFO  forest_state_manager           > Computing state (height: 2256486, ts=[Cid(bafy2bzacebplslzpassxbetxpmlxxujpnzdhuzpi4dxaywksl4aclm36pqo3c), Cid(bafy2bzacebo5yomyaqcsg7wxoixk5gs6e7ya6xmiulkh47uqsqqrwcokozahi), Cid(bafy2bzacead4bwmgdl2sr4mjy4pqvlwyu6xl5rk37huqsxie5tssula72zbxi)])
 2022-11-14T16:47:15.943Z INFO  forest_state_manager           > Computing state (height: 2256487, ts=[Cid(bafy2bzacea3y2csw2h66knrty5berf7mhtu3lo7s4qjefa4locn362arz5xji), Cid(bafy2bzaced462i6lsyyvrtip7uulj7x2dce4u6sd5w3aqtg4jbbsg5pey25e4), Cid(bafy2bzacecsgxvp5wyi6yxr5onhww4p54rrrqeoaw4r5unixefevu74jamyte)])
 2022-11-14T16:47:21.380Z INFO  forest_state_manager           > Computing state (height: 2256488, ts=[Cid(bafy2bzacedtju7lxvpxnscpxod2svbwu76fbo6gfqj2dpbgjicdv37spitpyw), Cid(bafy2bzaceby4ncz67rjfne33uox5uvveifanvxbwsews4pydhjxggxz34aevu), Cid(bafy2bzacec64aepnsiqqtdkfhiyoedkuebahtabeqxhiz6gpd32eifxgjzzp4)])
 2022-11-14T16:47:26.218Z INFO  forest_state_manager           > Computing state (height: 2256489, ts=[Cid(bafy2bzaceaxkxrkacr3zg4c4lrplc3rxgigahpbcel3u235srkegt7b3bnrg6), Cid(bafy2bzacedrnmek3uxf6pu4h5oaqkfqtdzwjolsz6g345qr7xpwnu2wha6tou), Cid(bafy2bzaceds6oczifux46kqu6wogcdbyqohjin2nk3kp4n4t5olg427brskh4), Cid(bafy2bzaceakmxsz4ibs6gql6emvk6tymnegdswnmusp3cc5p74t46mxccilx6), Cid(bafy2bzacecibkiqpoymo5tedy4t6flr2wp7p7aunuq2h7a5nvxbhoxksxrpoy), Cid(bafy2bzacecuwargppyb7roctxk6tsgcutez7b47vy53fbtrtip2p2cxtnuqjw)])
StateDiff:
  Expected: bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72
  Root: bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum
Address f0681832 changed:
 ActorState { code: Cid(bafk2bzacedudbf7fc5va57t3tmo63snmt3en4iaidv4vo3qlyacbxaa6hlx6y), state: Cid(bafy2bzacea3bastjmzukhnuj7e7gwq3ziemd52xv52hmwtehlh7nflvpgtmbe), sequence: 143
- balance: TokenAmount(50.482498488811314626) }
AccountState { address: Address { network: Mainnet
+ balance: TokenAmount(50.482502313698535992) }
AccountState { address: Address { network: Mainnet
  payload: BLS([133, 97, 157, 54, 163, 240, 205, 60, 144, 165, 49, 110, 62, 35, 27, 183, 231, 17, 117, 97, 203, 136, 187, 169, 40, 161, 97, 185, 101, 225, 145, 17, 198, 122, 195, 194, 229, 121, 7, 62, 234, 56, 36, 81, 202, 52, 50, 248]) } }
Address f099 changed:
 ActorState { code: Cid(bafk2bzacedudbf7fc5va57t3tmo63snmt3en4iaidv4vo3qlyacbxaa6hlx6y), state: Cid(bafy2bzacedpuk5ggwoq3s2wixsyjjnexpsjstdlyntio76vs2lt2jvy3o6mau), sequence: 0
- balance: TokenAmount(33196505.252211233588514288) }
AccountState { address: Address { network: Mainnet
+ balance: TokenAmount(33196505.252207408701292922) }
AccountState { address: Address { network: Mainnet
  payload: ID(99) } }
 2022-11-14T16:57:16.858Z ERROR forest::daemon                 > Failed miserably while importing chain from snapshot minimal_finality_stateroots_2257200_2022-10-17_16-00-00.car: Tipset chain has state mismatch at height: 2256490, bafy2bzacec2zcy52ypkq2pnupw2tqan2ioev2maqrronq76otfyjyjdxara72 != bafy2bzacebp76qjdtbcaek2ko66byihpesvd22lmtzd27gcheqdthu2az2sum, receipts mismatched: true
 2022-11-14T16:57:16.863Z INFO  forest::daemon                 > Forest finish shutdown
$


Four reviews formatted to fit into one screen

All four reviews (2 internal + 2 AC) could not be viewed at the same time side-by-side.
Scrolling left to right in order to view the last review easily forces the screen to the previous page. Seeing all four reviews side-by-side on one screen is helpful when we write determination letters. Thanks.

Team members will need to reduce the view of their screen to less than 100% to fit all four reviews.

@fourthletter This we can fix with some CSS, no need to close it.
It's designed for up to 3 reviews but not hard to make more flexible.


net can't forward again?

my envs: openVINO2019.1.148+win10+VS2015
When I use bvlc_googlenet.xml and the bvlc_googlenet.bin model to extract image features, the network model can only successfully forward only one time. When the second time loop, images length is not the same with the first time,it will go wrong. Why,any idea ? thank you!
OpenCV: terminate handler is called! The last OpenCV error is:
OpenCV(4.1.0-openvino) Error: Assertion failed (!isInitialized()) in cv::dnn::InfEngineBackendNet::initPlugin, file C:\jenkins\workspace\OpenCV\OpenVINO\build\opencv\modules\dnn\src\op_inf_engine.cpp, line 688
The main code that caused the error is：
Net net = readNetFromModelOptimizer(xmlFile,model);// 此模式下必须设置为DNN_BACKEND_INFERENCE_ENGINE
	if (net.empty())
	{
		cout << "net is empty!" << endl;
	}
	net.setPreferableBackend(DNN_BACKEND_INFERENCE_ENGINE);
	net.setPreferableTarget(DNN_TARGET_CPU);

	int net_size = 224;
	images.clear();
	images.push_back(img);

	while (true)
	{
		Mat blob;
		blobFromImages(images, blob, 1.0, Size(net_size, net_size), Scalar(104, 117, 123), false);
		net.setInput(blob);
		Mat prob = net.forward("pool5/7x7_s1"); // second time, error! (when images length is not the same with the first time)
            images.push_back(img); // for example , add image to images
      }

I have reproduced this. It looks like this is a bug in OpenCV: changing the shape of the input blob causes it to reinitialize the backend, which it fails to do. I am thus going to transfer this issue to the OpenCV repository.


Adding Vectara connector

What's being changed:
New connector for Vectara
How did you test this change (include any code snippets, API requests, screenshots, or gifs):
Tested locally and also full loop with ngrok and cohere.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Wrong derivation for Type[T]

I have following minimal non-working example:
from typing import Generator, List, Type, TypeVar, Union

class LI(List[int]):
    pass
class LS(List[str]):
    pass

_iter_type = TypeVar("_iter_type")
class MyList(List[Union[LI, LS]]):
    def __iter_type__(self, *, type_: Type[_iter_type]) -> Generator[_iter_type, None, None]:
        for elem in self:
            if isinstance(elem, type_):
                yield elem

l = MyList()
def same(other: Union[LI, LS]):
    for elem in l.__iter_type__(type_=other.__class__):
        for v in elem:
            print(v)

The problem seems to be that the derivation of type_ argument for __iter_type__() on line 17 seems to be wrong; pop-up says type_ is Type[Type[LI] | Type[LS]] and it should be Type[LI] | Type[LS]. This seems to be a regression as it did not give errors before last update of vscode.
This gives the following errors:
{
	"resource": "/home/verhaegs/eda/code/PDKMaster/pdkmaster/test_iter.py",
	"owner": "_generated_diagnostic_collection_name_#2",
	"code": {
		"value": "reportGeneralTypeIssues",
		"target": {
			"$mid": 1,
			"external": "https://github.com/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md#diagnostic-severity-rules",
			"path": "/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md",
			"scheme": "https",
			"authority": "github.com",
			"fragment": "diagnostic-severity-rules"
		}
	},
	"severity": 8,
	"message": "\"Type[LI]\" is not iterable\n  \"__iter__\" method not defined",
	"source": "Pylance",
	"startLineNumber": 18,
	"startColumn": 18,
	"endLineNumber": 18,
	"endColumn": 22
}
{
	"resource": "/home/verhaegs/eda/code/PDKMaster/pdkmaster/test_iter.py",
	"owner": "_generated_diagnostic_collection_name_#2",
	"code": {
		"value": "reportGeneralTypeIssues",
		"target": {
			"$mid": 1,
			"external": "https://github.com/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md#diagnostic-severity-rules",
			"path": "/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md",
			"scheme": "https",
			"authority": "github.com",
			"fragment": "diagnostic-severity-rules"
		}
	},
	"severity": 8,
	"message": "\"Type[LS]\" is not iterable\n  \"__iter__\" method not defined",
	"source": "Pylance",
	"startLineNumber": 18,
	"startColumn": 18,
	"endLineNumber": 18,
	"endColumn": 22
}

Software used:

Pylance 2021.6.2
vscode: latest flatpak version 1.56.2-1620837933
OS: Ubuntu 20.04.2 LTS
Python: anaconda 3.7.10

Thanks for the bug report. This will be fixed in the next release. I've added a simplified version of your code to our unit tests since it covers a case that was previously not included in our testing.

This issue has been fixed in version 2021.6.3, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202163-23-june-2021


⚠ GitHub has degraded performance

In 077d967, GitHub (https://www.githubstatus.com/api/v2/status.json) experienced degraded performance:

HTTP code: 200
Response time: 237 ms

Resolved: GitHub performance has improved in c114ccb.


docs: translate to zh-cn

fixes #165
90%+ text was translated, I just need some time to double check. :)

the domain was not updated.

@kecrily thx for the reviewing, I've applied your suggesions! 😄

We can’t do a build until after the file is merged. I still have to manually set up the DNS.
Once you make this as ready, I can merge and set everything up.

@QC-L ptal~~

It's ready for review now! 🎉
let's just keep it opening to wait for a few more cn reviewers :)

Sounds good! I'll check back on Monday.


Unable to select/change audio input/output

Bug Report
Problematic Behavior
Users unable to select/change audio input/output devices in app
Expected Behavior

Select microphone
Select speakers/headphones
Changes persist during call

Investigation & Solutions

Collect affected user cases
Verify device selection handling
Test across browsers

Impact
Critical - blocks basic audio device functionality

Conference selector seems to be broken, while the one in settings seems to work fine.


model without ivector problem

Hi
I want to know whether this kaldi-android-demo support a model which is not trained with ivector feature. My model works well in this demo, but its size only for the ivector directory is 20M, so I want to test a new model without ivector.

Yes, it should work without ivector, just don't configure it in the model.cc, that will be ok. This is a good idea actually, I'm also experimenting on decoding without ivectors due to ivector stability problems. For now ivector is still required though. In our model I train extractor of dim 30 instead of standard 100, that makes extractor smaller and more stable.


enable gui

Currently it is not possible to stand up the GUI, this PR:

pins npm requirement to fixed version
fixes a typo
adds the required html file and modifies the gitignore file so it is tracked
modifies readme files to match required commands for standing up the GUI

Signed-off-by<EMAIL_ADDRESS><EMAIL_ADDRESS>

nudge to prevent stalebot closing PR


Update JavaScript Version of FTS Fuzzy Match to v0.2.0

The project needs help from someone fluent in JavaScript to update Forrest Smith's JavaScript version of fts_fuzzy_match v0.1.0 to v0.2.0 of the algorithm.
The updated file should be created in:
/fts_fuzzy_match/0.2.0/js/

The JavaScript version is released into the public domain, but the coder is free to use any license he/she pleases, as long as he/she credits the original author.

@tajmone I'd like to help.

Hi @nrgwsth,
that's great! Feel free to make a PR for the version 0.2.0 of the algorithm. I'm not really of the JS league, so I'm not fluent in that language.
Forrest Smith only update the C++ version of his algorithm to v0.2.0, but by diffing the two C++ versions you can see that he basically just added an extra recursion to attempt match variations in case the same pattern could lead to a higher score.


Using http injector for tunneling

I'm not exactly an expert on how it works but if you're on a WhatsApp only data plan. You can use the http injector app in the playstore to connect to a proxy server and get internet connection. It set's up a VPN.
I have seen this working pretty great having or 2Mbs. It avoids ISP speed restrictions too but I still don't know how it works. The payloads they use in the app are very secured and encrypted. Haven't able to peak how it works. Maybe I can get some info about how it works.

Maybe would be interesting but still would be out of scope of this project. This project is about tunneling TCP through WhatsApp messages not circumventing network restrictions.


Read meta data from environment

Read meta data from environment according to this.
I do not know how to run Andy in WebLab so I would like someone else to check that the output has correct meta data.

I would like to avoid the system call inside that class. I'd suggest creating a class to represent the student data and pass it to the Context. Check the AndyOnWebLab class, that's the main method that Weblab calls!


Cleanup freeCompilerArgs

https://kotlinlang.org/docs/opt-in-requirements.html

Addressed to #53


I want to add sitemap in this website

The current issue in the repository is the absence of a sitemap for the website. A sitemap is a file that lists all the pages on a website, allowing search engines to better understand and crawl the site's content. By adding a sitemap, we can improve the website's visibility and ensure that all pages are easily discoverable by search engines.

kindly assign me this issue i can solve this


Just downloaded, install file crashes upon opening.

Just downloaded the latest version and extracted it to my desktop, when I go to run the install file it automatically prompts me to close the program and notifies me that "Tibialyzer has stopped working"
I have not been able to access the program at all to update anything within it and was wondering how I can get this to work. I've ran it as admin as well and still the same issue.
Thanks!

There is no installation file. If Tibialyzer crashes upon opening, you are probably missing the .NET framework. Try following the installation instructions.


Running server in both https and http.

Hi Team,
I just configured my COMODO SSL and was able to run the instance on https in browser but not http has stopped working. Can you please let me know what is the desired setting to service both http and https at the same time.
PS - I am using pm2 for keeping the server running.
Thanks,
Abhishek Jain

I think we can either run HTTP or HTTPs, not both.
It shouldn't be a tough configuration on lib/socket.io IIRC although I don't know why you would want to do it.
I would have Node.js run on HTTP on some high port and use a LB functionality to crunch the SSL connection.

Yeah, that's what I did at end. I used nginx to proxy read on port 3000 but then I also had to change a little bit of code to get the IP addresses.
Thanks.

https in browser but not http has stopped working.

You might want to redirect all http traffic to https btw. Would solve your problem as well. ;-)

@simison possible, but it's a less secure way of doing things since a MITM can hijack your HTTP connection and redirect you elsewhere.
HTTPS's Strict Transport Security should help to minimize this


add userctx to callbacks

@M1cha Could you please give a little background on this merge request ?
We use the same function prototype for all of our sensor API, so migrating code from one Bosch sensor to another is easy.
Under what circumstances would user context be useful for the i2c/spi readout callback ?

@BoschSensortec If you don't want to use global variables(and thus unnecessarily limit the number of bmp280 instances to 1) you need some kind of state for using i2c. For linux that'd be a file descriptor, for zephyr it's a struct device *.
Passing a context to the callbacks is the only way to associate the bmp280 instance with an i2c bus.

Thanks for the explanation. For current Sensor APIs , we will not merge changes that would break backward compatibility such as these ones.
But we are taking the feedback that for future products, we could add a private void pointer to the callbacks.


Missing Node.dll

So far not related to Avast or AVG (as some have claimed.) Possibly related to https://github.com/dustinblackman/Championify/issues/24

Error is Vista related. https://github.com/dustinblackman/Championify/issues/20


[Enhancement] Improvement to single map export feature

This pull requests resolves item https://github.com/uber/kepler.gl/issues/446

Updated export map modal dialog

updated

@chrisirhc @heshan0131 I applied the changes requested, please review!

The feature developed in this code will be moved into a new issue https://github.com/uber/kepler.gl/issues/482 and pull request later on


Junit results are not guaranteed to be unique when uploading to Visual Studio

The TestCase name is only set to the spec description, so if multiple specs use some generic description then the test results can't be differentiated after the fact.
Could an extension method be exposed similar to modifySuiteName, something like modifyTestName so that if one desires to add metadata to the TestCase name, they can?

resolved with #142

#142 merged. Closing.


mqtt packet is always {}

I know support for mqtt other than infinimesh is limited.
I modified the mqtt_client.js to run on mosquito with username and password authentication.
However, with several different bacnet devices, all I get is empty {} messages to mqtt on a weird subscription.   devices/0x132/state/reported/delta
which seems hardwired into the code and doesn't make much sense to me.  I'm mostly a poke and try coder and I don't fully understand bacnet-stack.
I can read the bacnet OK with other apps including node-red.  I think I have the correct type and instances in the config file.
Also, the web server doesn't seem to work.  I get the main screen for "who is" and "object" but nothing happens when I click the buttons.  The REST API doesn't work either.
So is this so totally entwined with infinimesh that it is hopeless to try to fix it?
I think there are others who would like to use this gateway with their existing  setup.
Kevin
pi@pi3:~/bacnet-mqtt-gateway $ npm start

<EMAIL_ADDRESS>start /home/pi/bacnet-mqtt-gateway
node src/app.js

{"level":"info","message":"Gateway server listening on port 8083","timestamp":"2020-12-20 21:57:39"}
{"level":"info","message":"Device configs found: baspi.json,baspi1.json,baspi2.json","timestamp":"2020-12-20 21:57:39"}
{"level":"info","message":"Client connected","timestamp":"2020-12-20 21:57:39"}
{"level":"info","message":"Schedule polling for device <IP_ADDRESS> with expression */3 * * * * *","timestamp":"2020-12-20 21:57:39"}
{"level":"info","message":"Schedule polling for device <IP_ADDRESS> with expression */3 * * * * *","timestamp":"2020-12-20 21:57:39"}
{"level":"info","message":"Schedule polling for device <IP_ADDRESS> with expression */3 * * * * *","timestamp":"2020-12-20 21:57:39"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:42"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:45"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:48"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"{}","timestamp":"2020-12-20 21:57:51"}
{"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:51"}
^C

Hi Kevin,
if you are using other BACnet sniffer tools like YABE on your PC, make sure you close them all before running npm start.
Regarding the publishing format: You can edit the publish_msg in mqtt_client.js to your desire. E.g., you can publish each BACnet object on a separate topic. For example like this:
publishMessage(messageJson) {
    if(sendConfig == true) { // Publish config:
        console.log('CONFIGURATION:');
        console.table(messageJson);

    // Publish values:
    console.log('PUBLISH UPDATE:');
        Object.keys(messageJson).forEach(key => {
            // console.table('Key : ' + key + ', Value : ' + JSON.stringify(messageJson[key]))
            // const topic = 'devices/' + gatewayId + '/state/reported/'+key;
            const objectType = key.split('_')[0];
            var type = 'sensor';
            // console.log('ObjType: ' + objectType);
            if (objectType == '0') {
                type = 'sensor';
            } else if (objectType == '3') {
                type = 'binary_sensor';
            } else if (objectType == '13') {
                type = 'sensor';
            } else { type = 'unknownObject' };

            const topic = 'homeassistant/' + type + '/' + key + "/state";
            const message = JSON.stringify(messageJson[key].value);
            console.log(topic, message)
            this.client.publish(topic, message);
        });
    }
}

Matthias

Thanks Matthias, that was helpful.  I still don't read any objects and the web interface still doesn't work but there is some progress in mqtt.

I wasn't successful with the web interface either. I'm just editing the "baspi.json" with my bacnet objects:
Enter the IP of the BACnet device you want to read from.
Add the BACnet objects, which you want to read. You can use tools like YABE to figure out the objects you want to read:
ObjectType needs to be translated to its number, e.g. check here: https://www.winccoa.top/help314p016/BACnet/Bacnet_Applikation-06.htm
Instance number is available directly from YABE

@magicmatt007 thanks, can you please file an PR and we can add this into the readme. And if you find bugs, pls contribute the fix. We built this stack some time ago on customer needs. We are happy to look into improvements :)

could I

I know support for mqtt other than infinimesh is limited.
I modified the mqtt_client.js to run on mosquito with username and password authentication.
However, with several different bacnet devices, all I get is empty {} messages to mqtt on a weird subscription. devices/0x132/state/reported/delta which seems hardwired into the code and doesn't make much sense to me. I'm mostly a poke and try coder and I don't fully understand bacnet-stack.
I can read the bacnet OK with other apps including node-red. I think I have the correct type and instances in the config file.
Also, the web server doesn't seem to work. I get the main screen for "who is" and "object" but nothing happens when I click the buttons. The REST API doesn't work either.
So is this so totally entwined with infinimesh that it is hopeless to try to fix it?
I think there are others who would like to use this gateway with their existing setup.
Kevin
pi@pi3:~/bacnet-mqtt-gateway $ npm start

<EMAIL_ADDRESS>start /home/pi/bacnet-mqtt-gateway
node src/app.js

{"level":"info","message":"Gateway server listening on port 8083","timestamp":"2020-12-20 21:57:39"} {"level":"info","message":"Device configs found: baspi.json,baspi1.json,baspi2.json","timestamp":"2020-12-20 21:57:39"} {"level":"info","message":"Client connected","timestamp":"2020-12-20 21:57:39"} {"level":"info","message":"Schedule polling for device <IP_ADDRESS> with expression */3 * * * * *","timestamp":"2020-12-20 21:57:39"} {"level":"info","message":"Schedule polling for device <IP_ADDRESS> with expression */3 * * * * *","timestamp":"2020-12-20 21:57:39"} {"level":"info","message":"Schedule polling for device <IP_ADDRESS> with expression */3 * * * * *","timestamp":"2020-12-20 21:57:39"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:42"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:45"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:48"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Fetching device object values","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Sending actuals for device <IP_ADDRESS> to IoT Hub","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"{}","timestamp":"2020-12-20 21:57:51"} {"level":"info","message":"Publish message to MQTT Broker","timestamp":"2020-12-20 21:57:51"} ^C

could I be cheeky and ask for your mosquitto config for this? I am battling to get the formatting right... many many thanks

@kskenyon
Any chance that you still keep the mosquito config file?

I modified the mqtt_client.js to run on mosquito with username and password authentication.

Can you post the code for the modified mqtt_client.js?


[Bug]: Rich Text Editor is blank and cannot be loaded

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
normal circumstances：

false imagination：

Steps To Reproduce
Sometimes when you open a page, the rich text edit box is blank
Environment
Release
Version
Cloud

@edyou2021 can you please share the steps to reproduce the issue?


Swimmer

hey @coccoinomane , thanks so much for this bot. Really good work. Im working on getting it to work with swimmer network, not sure if u have already tested on that? If you havent, im willing to contribute for that

Hi @EugeneTeu,
Nice to meet you :-)
I haven't made any testing on Swimmer yet but, by all means, feel free to go ahead!
In the best case scenario, the update will entail just a change of RPC, but we cannot be sure until we try it.
Let me know if you need any help in setting up the bot or otherwise.
Cheers,
Cocco

@coccoinomane took a small crack at this (bot works fine for me for c-chain).
seems EIP-1559 is disabled on test net for now and they seem to be using a default gas price somewhere
https://docs.swimmer.network/user-docs/alpha-test-swimmer
have tried sending {'type': 1, 'chainId': 73771, 'gas': 300000, 'gasPrice': 0, 'nonce': 19}
but it seems i get a  {'code': -32000, 'message': 'must be a contract creator: address 0x....'}
likely that im being blocked by the RPC.
are you aware if for the normal operations will swimmer implement EIP1559?

base fee =<PHONE_NUMBER>0

Swimmer network in a day or two. @EugeneTeu @coccoinomane 🤞

I am getting myself prepared for the swimmer network as well. I think the API will be the same, but as @EugeneTeu mentioned above, subnet uses a fixed gas fee to start with, so dynamic gas to send tx might not work....time to dig up that old web3.py docs.

If the only difference will be fixed-gas fee, then we are set thanks to @EugeneTeu 💪
IMHO, it will still probably take a day or two to flatten the bumps.

@vancouverjackluo @coccoinomane I believe we could just keep the current structure and then just hardcode the gas txn to be 25 (or whatever it is set to) + change contract addresses.
i tested the bot out on swimmer net and seems to be running fine (mining at least)

@vancouverjackluo @coccoinomane I believe we could just keep the current structure and then just hardcode the gas txn to be 25 (or whatever it is set to) + change contract addresses.
i tested the bot out on swimmer net and seems to be running fine (mining at least)

@vancouverjackluo @coccoinomane I believe we could just keep the current structure and then just hardcode the gas txn to be 25 (or whatever it is set to) + change contract addresses.
i tested the bot out on swimmer net and seems to be running fine (mining at least)

I guess we could since there is no going back from Swimmer at this point cos they also plan on onboarding more games in the future with TUS being the gas.

Glad we waited a bit more before implementing the changes: Swimmer suspended until May.
It seems Crabada has to rewrite their entire Swimmer impementation.
Let's stay tuned for further news.

Good call here @coccoinomane and @EugeneTeu.
If I may suggest, we all know AVAX gas prices are so high right now because of looting bots coming back to play and other matter, we may want to implement a GasFeeCap function.
I saw this bot coded in Go you guys might want to check this out

Tuning gasPrice, gasTip and GasFeeCap(LegacyTx or eip-1559) to speed up Transactions.

Hi @nikohd12 ,
I like the GasFeeCap idea!
Would you mind opening a separate issue with a proposal?
If the planets align, I could implement it over the weekend :-)

Hi @nikohd12 ,
I like the GasFeeCap idea!
Would you mind opening a separate issue with a proposal?
If the planets align, I could implement it over the weekend :-)

Sure bro! Thank you!!!

Hello,
I didn't see any updates for new Swimmer network. Has anyone looked into it?

The bot is now compatible with the Swimmer Network!
Just follow the instructions in the tutorial linked here 🙂

Thank you! Something was wrong when I looked ino this repository as it seemed that it was not up to date. By the way, how could you find the new idle game api's url as it was not in crabada's docs?


Added Deta Deployment Action

I added this action in order to make it way easier for us to update our Deta-based backend with just a simple push to our main branch.

LGTM!


Any plans for scipy.optimize?

Description
I wonder if there are any plans/ETAs on scipy.optimize module?
Thank you!
Additional Information
No response

There are some discussions ongoing but no concrete plan yet. @Rolandw0w Is there a particular functionality in the scipy.optimize module that you'd like to have?
cc: @cjnolet for vis

The problem that brought me here is linear programming and its slowness for scipy implementation.
I thought of RAPIDS and cuml; I've successfully used them on Kaggle earlier, so I started looking for GPU implementations.
Thanks!

@Rolandw0w,
Indeed, the current plan is to generalize some of the solvers from cuml and move them to the RAFT project (https://github.com/rapidsai/raft)  so they can be exposed through the cupy.optimize package.

Sounds good, thank you!
Feel free to close this issue then.

Let's keep this issue open as other can find the latest status 😃

xref: https://github.com/rapidsai/raft/issues/374

@Rolandw0w I just want to follow up on this issue as we are now starting to make RAFT features available to cupy through pylibraft. If you had your choice, is there any particular linear programming method you'd prefer to see implemented first?

@Rolandw0w I just want to follow up on this issue as we are now starting to make RAFT features available to cupy through pylibraft. If you had your choice, is there any particular linear programming method you'd prefer to see implemented first?

@cjnolet Hi, I'm not Rolandw0w but I'd really like to have an implementation of SLSQP please (https://docs.scipy.org/doc/scipy/reference/optimize.minimize-slsqp.html).

@cjnolet If I had to choose, I'd prefer HiGHS dual simplex. IIRC, this method is suitable for parallel implementation.
But any other method would be great too.

In addition to SLSQP, CG, BFGS and L-BFGS-B are also great options for starter.

Tagging @teju85 for further viz.

Any update?

Any update on this? Would love to have a gpu version of scipy.optimize.minimize using SLSQP

Chiming in to agree with ndjvisser - I'd love a scipy.optimize.minimize implementation.

Don't know if possible, but I would like very much scipy.optimize.differential_evolution on cupy!

Maybe folks asking for this could share more about their use cases? How would you use this functionality? What would it help you accomplish?

Maybe folks asking for this could share more about their use cases? How would you use this functionality? What would it help you accomplish?

I don't have much knowledge about the subject at all, so I may be wrong in multiple accounts.
That said, recently I have started a deep quest into optimizing performance of a scipy.differential_evolution workflow (CPU).
One of the venues I explored was Differential Evolution in GPU, but I didn't find any python library offering it with same functionality of scipy's implementation, which is quite robust and rich.
I have found research papers citing how gpu could greatly improve performance of DE, though.
Currently I'm exploring other venues.

Pasting my comment from #6324 here - I have developed a vectorized version of bounded value least squares based on scipy.optimize.bvls that I'd love to contribute.  Should I just go ahead and fork and submit a PR?  Just asking first because on #6324 it says  If you want to work on new modules (🥚), first discuss with us on this issue.
https://github.com/cupy/cupy/issues/6324#issuecomment-2261191587

I think a cupy version of least_squares would be extemely useful. https://docs.scipy.org/doc/scipy/reference/generated/scipy.optimize.least_squares.html#scipy.optimize.least_squares


Add French translation of post 2 ("A Minimal Rust Kernel")

This pull request adds a French translation of the second post (A Minimal Rust Kernel).

@phil-opp Hello! This is a pull request for Hacktoberfest, it's ready for review. If you deem it acceptable but can't approve it or merge it, could you add the hacktoberfest-accepted label to it? Thank you! 😃

Hi @TheMimiCodes, thanks a lot for this PR!
cc @AlexandreMarcq @alaincao If you have time, it would be great if you could take a quick look at this PR.

Un noyau de rouille minimal

Hi, sorry, I missed the original notification mail. I just saw this today ...
I was not sure how I can make suggestions using a commit on a PR, so I made PR on the PR ;-)
There:
https://github.com/TheMimiCodes/blog_os/pull/1
so @TheMimiCodes can double-check.

I updated some local links to point to the FR pages when available, but 'not sure if they will work correctly.
I am not too familiar with markdown and could not test on a running application
I also modified links to the FR Wikipedia pages when they existed
I saw a lot of links like "[xxx][yyy]" or "[xxx](yyy)",
sometimes translations is on the left, sometimes on the right?
I am not too sure how things work. Maybe someone else should review them.
I have no idea what an "associations mémoire" is, but I 100% understand what a "memory map" is.
I would vote for leaving those technical terms as they are...
I "untranslated" those:

caisses -> crates: this is Rust "technical terms", not a "real" words
bibliothèque essentielle -> bibliothèque core: this is the name of the library
méthode caractéristique -> méthode trait: this is Rust "technical terms", not a "real" words

I changed

"Imprimer" -> "afficher": "Imprimer" now sound to me heavily linked to "printers" and not to "screens" anymore.
Gone is the time of the teletypes !
"Noter" -> "Notez": sounds to me a lot less "informal/imperative". As we say in french "détendu du slip" (relaxed from the thong?)

All in all, those are only suggestions. I have french-belgian ears, and I think the author is french-canadian (?), so things probably sounds very different ...

Hi,
I did a review on that POST-02 FRENCH version made by @TheMimiCodes and updated by @alaincao.
I'm a french (France) native speaker.
I think that POST-02 french translation is almost perfect and can by merged.
I find your work @phil-opp you did on that blog is amazing.
I will keep reading and doing translation for the next posts.

Thanks a lot for reviewing @fzingg!
@TheMimiCodes Could you look through https://github.com/TheMimiCodes/blog_os/pull/1 and merge the changes you agree with? After that we can merge :tada:.

@phil-opp If we do not have news from @TheMimiCodes and @alaincao in the next weeks, let me know if you want I copy the POST-02 french page and do a new PR.

I merged @alaincao's recommended changes in my branch, so this pull request is now ready to review once more. Thank you everyone for reviewing this translation!

Great, thanks again everyone!
Published at https://os.phil-opp.com/fr/minimal-rust-kernel/.

This is a pull request for Hacktoberfest, it's ready for review. If you deem it acceptable but can't approve it or merge it, could you add the hacktoberfest-accepted label to it? Thank you! smiley

@TheMimiCodes We don't need that label, given that it's merged now, right?

@phil-opp Correct, you can remove the label if you want. Thanks for asking!


[service-bus] Track2 - remove receiver and sender caching from track 1

Track 1 had a singleton architecture that would ensure only a single receiver and sender were created per entity.
This caching seems to have little benefit compared to just giving the user control over managing the lifetime of senders and receivers.
Oddly enough this is related to #7936, which spurred all of this investigation and helped uncover this caching.
Some items to consider:

These cached receiver/senders are stored as part of the ClientEntityContext and need to removed from there. That should give us all the places we need to chase down.

BIG NOTE: as part of the fix for #8746 I noticed some unintended dependencies in how
Receiver gets initialized - the context.streamingReceiver and context.batchingReceiver
assignments in _init() are how the Receiver itself can properly handle locking when
doing open()/close(). This is less of a big deal when we start auto-initializing Receivers after
they're created by ServiceBusClient.

This might be a good opportunity to actually return a Closeable instance from subscribe(), helping solve #7986 (for track 2) by giving us a natural place for the user to know that a connection has been established.
(via @ramya-rao-a ):  all clients for the same queue/topic/subscription used the same $management link. This was very intentional. Where as in Track 2, each sender, receiver and rule manager gets to have their own $management link. We need to look into what performance hit (if any) we see with this approach.

See how we can port https://github.com/Azure/azure-sdk-for-js/pull/8537 after concluding on whether $management link should be shared or not

CC: @ramya-rao-a  who had the history on this particular bit of behavior.

Speaking of caching, in Track 1, all clients for the same queue/topic/subscription used the same $management link. This was very intentional. Where as in Track 2, each sender, receiver and rule manager gets to have their own $management link. We need to look into what performance hit (if any) we see with this approach.

Also, now that we dont have intermediate clients for Queue, Subscription and Topics, we don't really need the ClientEntityContext class. We should be able to just use the ConnectionContext class like we did in Event Hubs

#9710 is the first step towards this goal

We had some other little issues - the bulk is taken care of with @ramya-rao-a 's PR and then the rest is basically mopped up with our unification work. Once those PRs are closed I think we can consider this one done.

All PRs have been merged.


Azure Explorer Database node shows Server node content

Azure Data Studio Version: master

Steps to Reproduce:

Connect to Azure subscription
Expand a Database node

Expected: See database child content similar to if I expanded a database node in Servers view
Actual: See server child content, where a database shows all the databases available on the server.  It should show tables, views, etc. as top-level child content.
For example, appdb shouldn't be displayed below master in below screenshot.

I can't seem to repro.

Can you try moving the connection to the servers view and see if it is the same as in the azure view?

@anthonydresser it appears to be working now.  I'll close until I get consistent repro.


Modify allow_gps_summary string

Fixes #1599

Merging this myself as it is an urgent fix.

Codecov Report

Merging #1608 into 2.7.x-release will not change coverage.
The diff coverage is n/a.

@@              Coverage Diff              @@
##           2.7.x-release   #1608   +/-   ##
=============================================
  Coverage           3.28%   3.28%
=============================================
  Files                128     128
  Lines               6877    6877
  Branches             674     674
=============================================
  Hits                 226     226
  Misses              6636    6636
  Partials              15      15

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 5aba745...a267b59. Read the comment docs.


newlineAndIndent crashes with multiple cursors

Go to codemirror.net
Place two cursors on line 5 in the  whitespace.

Press enter

Uncaught TypeError: Cannot read property 'anchor' of undefined
    at codemirror.js:5801
    at runInOp (codemirror.js:3210)
    at newlineAndIndent (codemirror.js:5797)
    at doHandleBinding (codemirror.js:4126)
    at codemirror.js:4190
    at CodeMirror.lookupKey (codemirror.js:5914)
    at CodeMirror.lookupKey (codemirror.js:5918)
    at lookupKeyForEditor (codemirror.js:4140)
    at dispatchKey (codemirror.js:4156)
    at handleKeyBinding (codemirror.js:4190)

Tested in Chrome and Firefox.

Thanks!


xpd_usb_wrapper.h: No such file or directory

It appears this file is missing. Can you help?

It's in the parent library: https://github.com/IntergatedCircuits/USBDevice/blob/master/PDs/STM32_XPD/xpd_usb_wrapper.h


Add ability to change the number of concurrent downloads

Opening this as a draft PR for two reasons:

It's not finished yet, only the actual settings page is updated
The switch and text input are using the default Material 2 design

Trust me, I'll definitely review this soon™


pageserver: Tune 503 Resource unavailable

503 Resource Unavailable appears as error in logs, but is not really an error which should ever fail a test on, or even log an error in prod, evidence.
Changes:

log 503 as info! level
use Cow<'static, str> instead of String
add an additional wait_until_tenant_active in test_actually_duplicate_l1

We ought to have in tests "wait for tenants to complete loading" but this is easier to implement for now.

I'm guessing that this test would already have failed sometimes with the pre-503 code (since 500s were also logged as errors), but this change makes sense to me: I think we'll also want to make e.g. 404s not log as errors in the near future too.

I'm guessing that this test would already have failed sometimes with the pre-503 code (since 500s were also logged as errors), but this change makes sense to me: I think we'll also want to make e.g. 404s not log as errors in the near future too.

@jcsp done in #5501


Fix 13926: Made the SslHandshakeTimeoutException constructor public

Motivation:
During our testing phase, I encountered a challenge with the SslHandshakeTimeoutException as its constructor was protected, making it inaccessible for direct instantiation within our test suite. This limitation prevented thorough testing of scenarios involving SSL handshake timeouts. To address this, I've made the constructor public, allowing us to create SslHandshakeTimeoutException instances within our tests effectively.
Modification:
Recognizing the need for comprehensive test coverage, I've made the constructor public for creating instances of SslHandshakeTimeoutException within our test module. This modification enables us to properly simulate and test scenarios related to SSL handshake timeouts, thereby enhancing the robustness and effectiveness of our test suite.
Result:
Fixes #13926.
This pull request resolves the challenge of inaccessible constructors for SslHandshakeTimeoutException.s. With this enhancement, we can now thoroughly test and validate scenarios involving SSL handshake timeouts, ensuring the reliability and effectiveness of our tests.

@normanmaurer Please consider this PR for the https://github.com/netty/netty/issues/13926 issue. Thanks

@normanmaurer Please consider this PR for the https://github.com/netty/netty/issues/13926 issue. Thanks