Kill finalizers (or, fix premature finalization)

Object.finalize is now (as of Java 9) deprecated. finalize got a perhaps undeservedly bad rap, and it's not a terribly useful method regardless. But whether by accident or malice, finalize became practically unusable around Java 8 when the JIT decided it was perfectly ok to let objects get finalized while execution is still inside the last call to one of their methods. So, it is time to say goodbye to finalizers.
More info: https://stackoverflow.com/questions/26642153/finalize-called-on-strongly-reachable-object-in-java-8
Here are the finalizers (and users of ReferenceQueue) that I found in the code:
PoolArena.finalize is useless. Its only purpose is to hurry up the GC. But because it's a finalizer, all it does is delay it! For correctness, PoolArena would need a reachabilityFence in every method. I'm guessing it hasn't yet caused problems because it's so long lived it only becomes unreachable at shutdown. But if it's essentially a singleton, why worry how it's GC'd? If somebody actually cared about freeing its memory, they'd have added `close`!
Recycler.WeakOrderQueue.Head.finalize also seems useless. It's supposed to be a GC optimization--but, again, a finalizer delays GC. If clearing the references really is a good optimization, then it will be even better if invoked directly, not through finalization. It's not clear how dangerous this finalizer is.
HashedWheelTimer.finalize seems to only be part of a bug-detection/logging feature, so is harmless. There is also a leak detector. (Maybe just keep the leak detector?)
PoolThreadCache.finalize ok if free is called (in which case it doesn't do anything). Will suffer from premature finalization if free is not called. It should be hooked up to the leak detector instead.
There is an ObjectCleaner, but I don't see it being used anywhere. If it is, it's going to cause problems or require reachabilityFence. Should be deleted.

The other uses of weak references don't use ReferenceQueues, other than the leak detector.

Recycler.WeakOrderQueue.Head.finalize was removed


[image_picker] - Request multiple images at once

Right now the picker defaults to single mode, it would be nice to be able to have a multi-mode, by passing a parameter when you launch it, then an array is returned of files instead of just one.
for android this might help speed things up
unique code
intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true);

full example
Intent intent = new Intent();
intent.setType("image/*");
intent.putExtra(Intent.EXTRA_ALLOW_MULTIPLE, true);
intent.setAction(Intent.ACTION_GET_CONTENT);
startActivityForResult(Intent.createChooser(intent,"Select Picture"), 1);

for iOS I think maybe using this library might help, and seems up to date.
https://github.com/hackiftekhar/IQMediaPickerController

would love to see this functionality also

this functionality is needed here too.

related @https://github.com/flutter/flutter/issues/16054

It seems not natively supported by iOS but android seems to support it (>18). If anyone can create a PR for Android, I am happy to review it!

@acidjazz I like your suggestion can you create PR? Thanks :)

this plugin solved all my problems
https://pub.dev/packages/file_picker

I am not able to actively work on this recently. I will un-assign myself from this issue. Feel free to pick this up if anyone is interested!

I've tested everything I could find to do this.

https://pub.dev/packages/photo_manager
https://pub.dev/packages/photo
https://pub.dartlang.org/packages/multi_image_picker
https://pub.dartlang.org/packages/flutter_multiple_image_picker
https://pub.dartlang.org/packages/custom_multi_image_picker
https://pub.dartlang.org/packages/multiple_image_picker

Packages are either incomplete (image only, no video) or critically buggy and not actively maintained.
iOS and Android both natively support multi-media picking, is it really that hard to support it as part of the official media picking library?

@lifenautjoe Android does natively support a multi image picking UI. However, I am not aware that iOS has a native image picking UI. iOS does have native APIs to query photo assets but it doesn't have any UI binding to it. Ideally, we can expose these APIs so user can directly access photo assets from dart, we can also create a custom UI to pick multiple images on iOS.

This would be the best UI.
Same as on this package: https://github.com/Sh1d0w/multi_image_picker

@b-jan I agreed, that package is good. However, It required the minSdk to 19 instead of 16, and might need to tweak some configuration. If the plugin used 16, It would be the best imo.

I would love to see this feature, any chance of seeing this implemented soon? The lack of this feature degrades usability and is a nightmare to users to have to click the pick image button n times. It would otherwise be painful for developers to rely on unofficial plugins for this basic functionality.

Half a year has passed... Any progress? Thanks

Would love to see it released

any update

I switched to https://pub.dev/packages/file_picker

Any progress yet? This is a feature that shoud be officialy supported

Any Progress on this... This is the very important feature to have

In flutter, every now and then I get a basic requirement.
I start exploring and end up with an 2/3 year old open issue :(

I just stumbled over this issue because I need to let the user pick multiple images, too.
I tried many other packages, but they did not satisfy me.
As I further searched for it, I just found this pull request updated a few weeks ago.
This seems to solve this issue as soon as it is ready to be published in a next update.
I tried the pull request in my code and it seems to work fine.

please try images_picker

@chavesgu Looks promising, but gives me errors on iOs :(

Are there any updates?

Just tried implementing a cool image feature in my Flutter Web App, and I stumbled on this issue.
Would LOVE to be able to let my users select multiple images at once, instead of having to select one at a time.
Hope we can get this implemented soon-ish. The PR looks promising. Let's hope we get this soon! <3
https://github.com/flutter/plugins/pull/3783

why is this ticket closed? the issue is not fixed yet

@LongZhai Just published 0.8.1 which fixes this issue :)

@cyanglaz Thanks for your prompt response. Could you let me know which function will be used to pick up multiple images and what is the return type? I did not find the function specs.

@cyanglaz Thanks for your prompt response. Could you let me know which function will be used to pick up multiple images and what is the return type? I did not find the function specs.

getMultiImage()

@cyanglaz Thanks for your prompt response. Could you let me know which function will be used to pick up multiple images and what is the return type? I did not find the function specs.

Hi @LongZhai,
I created a PR to update the example app to support the multi-image feature and its implementation. Feel free to check it :)

Does this Feature work on Flutter Web?
I tried here: https://github.com/MalteMagnussen/flutterhobby/blob/main/lib/ImageSorting/image_sorter.dart
The idea is that the user can upload a bunch of images and then sort through them on the site: https://maltemagnussen.com/#/imagesorting and then delete all the ones that weren't dragged to the pile on the right side.
Sadly you can't use File to delete images on Web afaik, so the feature is kinda on pause for now.
This is just a hobby project to practice Flutter and try things like using File and Draggable etc. The idea for the feature came from my brother who takes 300 images per day on Vacation, and wants an easy way to view and sort them.

Does this Feature work on Flutter Web?
I tried here: https://github.com/MalteMagnussen/flutterhobby/blob/main/lib/ImageSorting/image_sorter.dart#L41
The idea is that the user can upload a bunch of images and then sort through them on the site: https://maltemagnussen.com/#/imagesorting and then delete all the ones that weren't dragged to the pile on the right side.
Sadly you can't use File to delete images on Web afaik, so the feature is kinda on pause for now.
This is just a hobby project to practice Flutter and try things like using File and Draggable etc. The idea for the feature came from my brother who takes 300 images per day on Vacation, and wants an easy way to view and sort them.
EDIT: Nevermind, it is Unimplemented.
Error: UnimplementedError: pickMultiImage() has not been implemented. at Object.throw_ [as throw] (http://localhost:55539/dart_sdk.js:5059:11) at image_picker_for_web.ImagePickerPlugin.new.pickMultiImage (http://localhost:55539/packages/image_picker_platform_interface/src/method_channel/method_channel_image_picker.dart.lib.js:75:17) at image_picker.ImagePicker.new.getMultiImage (http://localhost:55539/packages/image_picker/image_picker.dart.lib.js:45:48) at image_sorter._SortImageWidgetController.new.getImage (http://localhost:55539/packages/flutterhobby/ImageSorting/image_sorter.dart.lib.js:735:46) at getImage.next (<anonymous>)
Will have to wait until this MultiImagePicker works on Web, and you can somehow either delete user images, or zip the kept images and allow user to download that.

Hi @MalteMagnussen,
Unfortunately, this feature is implemented only for Android 4.3+ and iOS 14+ for now. If you have ideas on how to update the web part feel free to share :)

@LongZhai Just published 0.8.1 which fixes this issue :)

Hello! I have seen your message but couldn't understand which plugin you were referring. Then I found it. If anybody else wondering, here is the repo:
Flutter Plugins --> ImagePicker
Very Important Feature
I cannot see any property limiting the image count that can be selected. Will there be that feature? It is very important I think because lots of developers want to control how many images a user can pick with multi-picking.
Could you please implement that too?
If anybody wondering, currently, I am using this package. However, it doesn't have a feature to limit the maximum pickable image count. :(
File Picker v3.0.3
Using this codepiece
await FilePicker.platform.pickFiles(type: FileType.image, allowMultiple: true);

Hi @yasinarik,
It would be great if you open a new issue for this proposal since this issue is closed and it can be hard for people to notice your comment. Also, you can explain a bit more why this feature is important and what are use-cases.
Thanks!


Modpack not running (Create: Above and Beyond) [Fixed]

the create above and beyond is not running

I did recreate this will try my best to find the bug

Fixed please test it now and confirm that it is fixed

hey what keyword of the mod pack should i input fore create above and beyond


docs: quick start guide of cosign image signing

Signed-off-by: Xynnn007<EMAIL_ADDRESS>

This error seems not related to this PR. We can fix it in another PR.


LIVERY SUBMISSION：JUNEYAO AIRLINES B787-9(YuanShen Livery）

it is 2048*2048
And it is China's first anime-style livery aircraft! A lot of people love it, so I made this one!

@kolos26 When I click on it, it's Qantas Airways. Please check it, thank you


typo: Resouce -> Resource

It's correct under the parameters section, but not under the Syntax. I assumed it was a typo rather than a product bug

Not so sure. This indicates the typo might be in the code as well:
https://github.com/dotnet/coreclr/blob/master/src/inc/MSCOREE.IDL#L104

Thanks, for loking it up. Should there be a note about the misspelled parameter?

I discussed this with @rpetrusha and we don't think we need to add a note. Do you want to just keep the other changes? I'd just fix the params section like I did in the other PR though this time.

I'll just close this since the change will be the reverse of this PR/commit.
RE: the idea of a note. When I saw the discrepancy between the sample and parameter description, my assumption was a doc bug rather than a product bug. I understand that calling out "we shipped a boo boo" doesn't look great, but  think others coming across this might make the same assumption.
Pointing the source in the other repo was also helpful, so linking to that would be great if you end up reformatting these types of documents in the future


Any plans to support Go SDK v2?

Are there any plans to support using V2 Go SDK?

If anyone finds this, we completely removed the need to use aws-iam-authenticator using AWS Go SDK V2 like this:
https://github.com/weaveworks/eksctl/pull/5016


Add ClimaExplorer

This commit adds an interactive viewer for ClimaAnalysis.
Work in progress!
example screencast

I see for now ClimaExplorer is not using Observable
Observables makes things a bit smoother because it only updates one object (e.g., a dot or a line) and does not recreate parent objects (a figure, an axis, etc.). Currently ClimaExplorer recreates everything each time, which can be slow and clunky (resizing everything each time for example).
Note that sometime you do want to recreate the whole figure, in which case SpecApi is more responsive. - but I think in our case we want Observables ideally

3140a7b switch to WGLMakie, but all I did is copy-paste the CairoMakieExt and replace with WGLMakie, likewise in scripts.
This works, and the app is much faster and more responsive.
However, you may want a different design (compatibility with both CairoMakie and WGLMakie? or no duplicate of code in Ext?) so feel free to update or delete this commit and rework it

3140a7b and c5d50d2 switch to WGLMakie, but all I did is copy-paste the CairoMakieExt and replace with WGLMakie, likewise in scripts.
This works, and the app is much faster and more responsive.
However, you may want a different design (compatibility with both CairoMakie and WGLMakie? or no duplicate of code in Ext?) so feel free to update or delete this commit and rework it
(Note, I wanted to squash these 2 commits into one, and I did locally, but I am a bit worried that if I do git push -f it will remove previous commits, so for now I leave these 2)

I think there should be a way to have a single MakieExt that can use different backends, but I haven't looked at how to accomplish this


Database

Where ia the database stored/how can i acces it?
Does it create some admin panel?

If you've set up a database surely you know how to access it? What database are you using?

When the server runs it should make a database. You need to go to \FXServer\resources\vrp\cfg\base.lua and edit the file to suit your database. For example my database is running on my server so my file looks like:
local cfg = {}
-- mysql credentials
cfg.db = {
host = "<IP_ADDRESS>", -- database ip (default is local)
database = "vrpfx",   -- name of database
user = "root",    --  database username
password = ""   -- password of your database
}
cfg.save_interval = 30 -- seconds
cfg.whitelist = false -- enable/disable whitelist
cfg.ignore_ip_identifier = true -- This will allow multiple same IP connections (for families etc)
-- delay the tunnel at loading (for weak connections)
cfg.load_duration = 5 -- seconds, player duration in loading mode at the first spawn
cfg.load_delay = 0 -- milliseconds, delay the tunnel communication when in loading mode
cfg.global_delay = 0 -- milliseconds, delay the tunnel communication when not in loading mode
cfg.ping_timeout = 5 -- number of minutes after a client should be kicked if not sending pings
cfg.lang = "en" -- en / fr / it / ger / pt / ru / lith / dan / ar / pl / es / swe / fin (English/Français/Italiano/Deutsche/Português/Pусский/Lietuvių/Dansk/العربية/Polskie/Español/Svenska/Suomalainen)
cfg.debug = false
return cfg
Before you run your server make sure you have HeidiSQL installed and running along with Xampp. Then in HeidiSQL  right click the left hand panel and then Create New>Database. Call this the same as the on in base.lua. Then run the server and you should be good to go!
https://www.heidisql.com/
https://www.apachefriends.org/index.html

This is not an help section, please use the FiveM forum topic.


Add an EditorConfig

We should add an EditorConfig to this project. I suggest we clone the one used by corefx or such.

Turns out corefx doesn't seem to have one. But this looks pretty authoritative. We should consider using it.

Just validate that it does not reformat my source, which is using the Mono coding style.

Just validate that it does not reformat my source, which is using the Mono coding style.

Is there a EditorConfig for that code style we can copy?

Just got pointed out to this one, will try this weekend:
https://github.com/mono/monodevelop/blob/master/.editorconfig


Added SpongeForge and Nukkit. Renamed SpongeVanilla variables.

I have renamed the variables so they don't conflict with SpongeForge

Just an update for ya, theres going to be changes to the seeder setup, I'll comment here when they are complete. At that point you can update this service to match those changes, and then we should be good.
Thanks again for your patience :)

Alrighty

So this will actually be handled by service exports. Hold onto your configuration and when 0.7 rolls around you'll be able to export and share this will anyone who would like to use it. 👍


regex error reading a binary .ply

I am trying to read in a .ply file but keep getting a regex_error.
== params ==
source[0]:              /data/eos/TLS/malaysia/MLA-01/2018-07-17.001.riproject/extraction/rxp2pcd_i/mal01_100.ply
outdir:                 /home/ucfaptv/public_html/potree/mine/
spacing:                0
diagonal-fraction:      200
levels:                 -1
format:
scale:                  0
pageName:               mla_test
projection:

ERROR: regex_error

The header to my file looks like this:
ply
format binary_little_endian 1.0
comment Author: Phil Wilkes
obj_info generated with pcd2ply.py
element vertex 46452751
property float x
property float y
property float z
property float intensity
end_header

What could be causing this?
Is it related to issue #27 ? Running grep I can't find boost::regex in the code anywhere.

Hi,
Closing this because PotreeConverer 1.7 is now replaced by a complete rewrite, PotreeConverter 2.0, and the old version will no longer be worked on.


Added support for CSV x-forwarded-proto header in ProxyFix

It is a common practice to add make CSV based  'x-forwarded-proto' headers
An example is node's http-proxy

Updated.


ajax graphs are locking on when there are no downsampled datata

work in socket timeout or something or muffing...  ;)

https://github.com/grafana/grafana/issues/1850

https://github.com/OpenTSDB/opentsdb/issues/304

cloud be that it's leaking sockets?

I have reported the issue to the OpenTSDB project too, I have just wanted to be sure that the issue is an OpenTSDB issue.......

motherfucker

I'd probably go about this starting at https://www.google.cz/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=opentsdb locking connection on when there are no data

it seems that deleting data helps for some reason.....
https://github.com/OpenTSDB/opentsdb/issues/500

hmm...

fixed? need to test....

fixed


I want to embed wrappers

We need a way to support embedding wasm wrapper within the host app.
Feature has been outlined here: https://hackmd.io/oTuN7E68R5O517KKDNv-KQ
Blocked by:

[x] #1102
[x] #1103

Hey @nerfZael what is the spec for this now that the blocking issues are completed?


Simplify axis parameters

"The main problem with the current interface is that you can create plots that is perfectly valid in schema but not actually doing what you want. For example, the axis parameter is really tricky to use as it just doesn't work and there is no error message when you don't understand the inner workings of Plotly.swift and the plotly js library." - Issue #16 @ProfFan

Just to make the problem clear, here's how shared axes and subplots work at the moment.
In JavaScript, there are two things that somehow need to be associated to each other. trace.xaxis needs to match an entry in layout.xaxis. trace.xaxis is a simple string like "x"/"x1", "x2", "x3", etc... On the other hand layout.xaxis is an array of quite complex xaxis objects. This object describes the range, title, tickmarks and many other properties that show up on the final figure.
String "x"/"x1" corresponds to the first xaxis object , x2 to the second one and so on to infinity and beyond...  The layout.xaxis object doesn't have to explicitly exist and things still work bacause Plotly.js implicitly creates them. Or it is also possible to build the axis with a layout.grid property into a nice regular matrix arrangement. The Y axis behaves exactly the same way with a "x" -> "y" replacement.
Plotly.swift basically adopted the pattern without modifications. The whole thing is very error prone and there's no error when one makes a mistake. Since the non-existing axes are created automatically Plotly.js just makes up a new axis which results in surprising behavior.
Here's an example in JavaScript:
var trace1 = {
  type: 'scatter',
  x: [1, 2, 3], y: [4, 5, 6],
  xaxis: 'x1', // Alternatively 'x' or omitted altogether
  yaxis: 'y1'  // Alternatively 'y' or omitted altogether
};

var trace2 = {
  type: 'scatter'
  x: [20, 30, 40], y: [50, 60, 70],
  xaxis: 'x2',
  yaxis: 'y2',
};

var layout = {
  grid: {rows: 1, columns: 2, pattern: 'independent'},
};

Plotly.newPlot('myDiv', [trace1, trace2], layout);

And here's the corresponding Swift code. Here, the axis matching is done by using uid: Int parameter of the constructor.
let trace1 = Scatter(
    x: [1, 2, 3], y: [4, 5, 6],
    xAxis: .init(uid: 1),
    yAxis: .init(uid: 1)
)

let trace2 = Scatter(
    x: [20, 30, 40], y: [50, 60, 70],
    xAxis: .init(uid: 2),
    yAxis: .init(uid: 2)
)

let layout = Layout(
    grid: .init(rows: 1, columns: 2, pattern: .independent)
)

let figure = Figure(data: [trace1, trace2], layout: layout)

By re-using the same axis string (i.e. "x2") in multiple trace objects you can achieve plotting on a shared x-axis. This is very flexible and allows plotting of various mixtures of traces on a shared x axis with an independent y axis or vice versa. Here's an example.
As usual in the open source world, the documentation for the entire problem is sparse. For a detailed comparison of more chart types one can use the unit tests. All subplot examples from Plotly.js webpage are currently implemented as this test suite.

Wow this is a great explanation! Thank you @vojtamolda !

Enough is enough 👿
It's about tie to fix the mess. I just found a nasty bug #18 in the subplots/axis logic that's been sitting there since at least since the last release.

Problem
As is outlined above, JavaScript's (and also Plotly.swift's as of `v0.4.0) implementation that use axis matching by name/uid doesn't exactly use the best of what Swift has to offer. There are is no type safety and manual uid matching makes it very easy to make a typo.
By default all traces of the same kind share their axes. So the final figure is "one chart" with no subplots. This is difficult to grasp for beginners and I'd like to make this explicitly visible in the source code.
Solution
Let's leave out grid matrix-like subplot layouts for later. I don't think any choices here will have any effect on it.
The primitive use cases should stay identical to JavaScript. The simple use cases should stay simple. Ideally, the design should imply that compiled code is correct. "Default" trace -> subplot axis association should "just work" like in JavaScript. Same goes for more advanced subplot/axis matching. The default behavior between JavaScript and Swift should match to the largest possible extent. There should also be no surprises for experts who already know Plotly well.
All axis-like objects use Swift's reference semantics. The XAxis, YAxis, Geo, Mapbox and others are all classes. This allows for cross referencing the same instance in multiple different traces and achieve sharing of the axis, i.e. placing the traces on the same axis system. The default trace constructors initializes the subplot properties to the .preset static member with uid equal to 1. This way it is possible to do identity checks of each instance against the .preset.
When a Figure is constructed, the constructor collects all the subplot axis from traces, checks for both unique uid and unique instance. Then it assigns the non-duplicated objects to the corresponding storage in layout.
As a simplification of the most common use case, there is an extension of [XAxis] with a static .preset(....) method that takes the same arguments as the constructor but allows for customization of the default axis shared by all traces that don't explicitly change their subplot axis to a non-preset value.
Examples
Primitive
Here's a figure with two traces and shared axes. The code is virtually identical to JavaScript and one doesn't need to worry about layout, subplots, axis or anything else.
Figure(
    data: [
        Scatter(x: [1, 2], y: [3, 4]),
        Scatter(x: [1, 2], y: [4, 5])
    ]
)

Simple
Here's a figure with two traces same as above, but now the axis are labelled. The trick here is that Scatter.xAxis is initialized to a static XAxis.preset instance. This makes the sharing of axes between traces explicitly visible in the source code of the library. The [XAxis].preset(...) function doesn't creates a new axis with the same uid as the XAxis.preset but all the other properties can be customized.
Figure(
    data: [
        Scatter(x: [1, 2], y: [3, 4]),
        Scatter(x: [1, 2], y: [4, 5])
    ],
    layout: Layout(
        xAxis: .preset(title: "X Label"),
        yAxis: .preset(title: "Y Label")
    )
)

Complex
This example is a more complex chart with a small inset plot in the top right corner. All the axes are created with a call to the constructor without explicitly involving the layout. The Layout.xAxis and .yAxis get filled in automatically in the constructor of the Figure by collecting the Scatter.xAxis attributes of the two traces.
let trace1 = Scatter(
    x: [1, 2, 3], y: [4, 3, 2],
    xAxis: .init(), yAxis: .init()
)
trace1.xAxis.anchor = .yAxis(trace1.yAxis)
trace1.yAxis.anchor = .xAxis(trace1.xAxis)

let trace2 = Scatter(
    x: [20, 30, 40], y: [30, 40, 50],
    xAxis: .init(domain: [0.6, 0.95]),
    yAxis: .init(domain: [0.6, 0.95])
)
trace2.xAxis.anchor = .yAxis(trace2.yAxis)
trace2.yAxis.anchor = .xAxis(trace2.xAxis)

let figure = Figure(data: [trace1, trace2])

Implemented in release 0.5.0.


Update react

This PR is updating a few things about react, some are already presenting warnings:

isMounted() is deprecated as mentioned on issue #162.
react.createClass() is deprecated as mentioned on issue #154.
React.PropTypes will soon be deprecated as mentioned by Facebook (https://facebook.github.io/react/warnings/dont-call-proptypes.html) and should be imported as prop-types.
TouchableWithoutFeedback was being imported and not used.
GooglePlacesAutocomplete now is exported as Default and as a component.

@FaridSafi Do you need any help for merge this PR?

Would be great to get this into the next release, currently incompatible with react-native 0.47 due to the breaking changes in React 16.

Thank you @esganzerla :)

Thank's for this update, feels good to not have any red lines in console anymore


Refactor CompileDirectoryEntry, print size

Fixes https://github.com/pytorch/pytorch/issues/134301
Signed-off-by: Edward Z. Yang<EMAIL_ADDRESS>

Stack from ghstack (oldest at bottom):

(to be filled)

cc @Chillee

You might have some trouble with third-party/ when you check this in because human_bytes isn't in our internal Cargo.toml(so idk if it has deps that are incompatible with existing ones). But hopefully it should be fine since it seems like a simple enough library


fix: center banner position on banner detail page

image still small in the mobile view.

@KirDE i have made a update.


What kind of data does app-os-monitor receive?

Hello ,
I have installed the app-os monitor driver and app.And then I also confirmed the store(timeseries collection).
The following document is what kind of information?
{ "_id" : ObjectId("59eef1e3fe27380030993cac"), "datasource_id" : "loadavg15", "data" : 0.169921875, "timestamp" :<PHONE_NUMBER>835 }

load average and Memory consumption

From current pc?

from current pc if run outside vm? or for the VM if inside a VM!

Host pc or guest pc?

Gest if your running in a vm host otherwise :-)

I understand Thanks you :)


Add DRY21 Modbus control script

@anataty it worth to mention that DCN/IDC is required and that Modbus TCP of the Electrolyser is used.

@anataty ping.


Improving logical structure through javascript

Hey there!
You have an interesting project, I would like to contribute to It ,

[x] By refactoring code to make it easier to understand by doing some logical improvements.
[x] Keeping a single source of truth for songs, eliminating extra HTML code.

Hey there! You have an interesting project, I would like to contribute to It ,

[x]  By refactoring code to make it easier to understand by doing some logical improvements.
[x]  Keeping a single source of truth for songs, eliminating extra HTML code.

If that is okay give me 👍so I can proceed further.

https://github.com/AnshSinghSonkhia/40Pie-Music-Player-Website/pull/56
This PR makes the required improvement.


Improved Tamil and Sinhala traineddata

Improved by training on custom fonts.
 Error rate = 0.485
Sinhala
Finished! Error rate = 4.237

Thank you for for submitting Improved Tamil and Sinhala traineddata. However this repo only holds the files that  were trained at Google by Ray Smith. You should submit these to the repo tessdata_contrib.  Please make sure to include a readme file similar to https://github.com/tesseract-ocr/tessdata_contrib/blob/main/khmLimon.md which shows the improvements with your new version of files. Thanks!

@stweil Is it possible to move this PR to tessdata_contrib?

Thank you for for submitting Improved Tamil and Sinhala traineddata. However this repo only holds the files that were trained at Google by Ray Smith. You should submit these to the repo tessdata_contrib. Please make sure to include a readme file similar to https://github.com/tesseract-ocr/tessdata_contrib/blob/main/khmLimon.md which shows the improvements with your new version of files. Thanks!
Edit: Research Paper: Tamizhi-Net OCR: Creating A Quality Large Scale Tamil-Sinhala-English Parallel Corpus Using Deep Learning Based Printed Character Recognition (PCR) Github Repo: aaivu-tamizhi-net-OCR

Thanks a lot, sir. I will follow the given details and update it soon.

@stweil Is it possible to move this PR to tessdata_contrib?

I am afraid that is not possible. We need a new pull request for tessdata_contrib.
@Chaarangan, please add documentation as suggested by @Shreeshrii to your model files. It is also important to describe all steps (command lines, fonts used, installation instructions for fonts, training texts, ...) which where used to generate the new models.


Server responds with 401 after some time of inactivity, works after reload

After some time of inactivity, api calls return a 401, when reloading (once or twice) it works.
I call the api using useStrapi4() and find(). The Public role has permission to find and findOne of the collection type I am querying.
The request:
...
mounted() {
  this.$strapi.find("home").then(({data}) => {
    this.page = data;
  });
},
...

The response:
{
  "data": null,
  "error": {
    "status": 401,
    "name": "UnauthorizedError",
    "message": "Missing or invalid credentials",
    "details": {}
  }
}

I have a hunch that it may have something to do the the JWT token, but I don't know how to debug it.
Strapi 4.1.9
Nuxt 3.0.0-rc.5
DB Postgres
Hosted on Railway.app

A bit old but it can be related to Strapi’s default database connection settings. I have previously same issue, which could be fixed through increasing number of connections:
module.exports = ({ env }) => ({
  connection: {
    client: "postgres",
    connection: {
      host: env("DB_HOST", "<IP_ADDRESS>"),
      port: env.int("DB_PORT", 5432),
      database: env("DB_NAME", "devDB"),
      user: env("DB_USER", "devUser"),
      password: env("DB_PASSWORD", "devPassword"),
      ssl: false,
    },
    pool: {
      min: 0,
      max: 10,
    },
    debug: false,
  },
});


Using a mixture of 16-bit and 32-bit dynamic index buffers causes incorrect rendering

When mixing 16bits and 32bits dynamic index buffers, the rendering is incorrect.
Works fine with static index buffers.

Repro sample example-01-cubes on this branch : https://github.com/bkaradzic/bgfx/compare/master...CedricGuillemet:reproUint16Uint32?expand=1

That repro URL is truncated.

https://github.com/CedricGuillemet/bgfx/tree/reproUint16Uint32

Reproduced and figured out what's the issue... Will be fixed soon.

@CedricGuillemet Let me know if this fixes your other use case.

@bkaradzic I'll test in Babylon Native tomorrow! Thank you for the quick fix!

LGTM! Thank you!


How to use with a Node service which only offers normalized req.url?

Related discussion on spectrum.chat
When using a "serverless" Node function on ZEIT's now.sh, I have access to req and res in the function. Here is the original code I tried:
const options = {
  originWhitelist: ['http://localhost:3000'],
  requireHeader: ['origin', 'x-requested-with'],
  removeHeaders: ['cookie', 'cookie2']
};
const cors_proxy = require('cors-anywhere').createServer(options);
module.exports = (req, res) => {
  cors_proxy.emit('request', req, res);
};

However, it appears that the supplied url property on req is normalized, and that I cannot access the original url. An employee suggested this workaround in the function body:
module.exports = (req, res) => {
  cors_proxy.emit(
    'request',
    Object.assign(req, {url: req.url.replace(':/', '://')}),
    res
  );
};

but trying that gave me no success. (More details at the discussion linked at the top of this issue.)
Can you offer a suggestion for this case? I thought about using a custom header for the destination URL, like below, but would prefer not to since it's very hacky.
module.exports = (req, res) => {
  let url = '/';
  if (req.headers['x-proxied-url']) url += req.headers['x-proxied-url'];
  else url += 'iscorsneeded';
  const reqModified = Object.assign(req, {url});
  cors_proxy.emit('request', reqModified, res);
};

My recommendation on things to try out:

Try to find a way to get the original unnormalized URL.
If it is not possible, try to ask the (hosting) platform to not normalize the URL.
If that is not possible, try to assign req.url = req.url.replace(^\/https?:\/(?!\/)/, "$&/"); before emitting req.url as a fragile work-around.
If you really need the original URL, and none of the previous options are feasible, switch to a different hosting provider.

Thanks for the suggestions.

For anyone else who might come across this: I decided to use a query parameter to hold the destination URL, like so:
module.exports = (req, res) => {
  let url = '/';
  if (req.query._url) url += req.query._url;
  else url += 'iscorsneeded';
  const reqModified = Object.assign(req, {url});
  cors_proxy.emit('request', reqModified, res);
};

The methods suggested by Rob were not feasible with ZEIT, and using a static URL with variable header values conflicted with browser caching and concurrent requests due to cache locking.


refactor: move logic to ServerResponseWriter

Codecov Report

Merging #1223 (475569c) into main (aae4766) will decrease coverage by 0.03%.
The diff coverage is 66.66%.

@@            Coverage Diff             @@
##             main    #1223      +/-   ##
==========================================
- Coverage   58.88%   58.85%   -0.04%
==========================================
  Files          74       74
  Lines        2464     2479      +15
  Branches       65       64       -1
==========================================
+ Hits         1451     1459       +8
- Misses       1013     1020       +7

Impacted Files
Coverage Δ

...io-http/src/main/scala/zhttp/service/Handler.scala
68.00% <44.44%> (-9.28%)
:arrow_down:

...ain/scala/zhttp/service/ServerResponseWriter.scala
92.30% <83.33%> (-4.36%)
:arrow_down:

zio-http/src/main/scala/zhttp/service/Server.scala
46.66% <0.00%> (-1.95%)
:arrow_down:

...main/scala/zhttp/http/headers/HeaderModifier.scala
18.60% <0.00%> (+1.16%)
:arrow_up:

Continue to review full report at Codecov.

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


[TW#17765] I2C crashing - watchdog timeout (master & v3.0 branch)

I have a project that has three I2C slave devices on a single bus (running at 100kHz). For some time I was developing with ESP-IDF 2.1.1 and everything was working pretty well, except for a weird problem where the I2C master would freeze up after a few minutes. I did some research and it looks like this is a problem with the I2C master hardware state machine which has been addressed in more recent commits of ESP-IDF. So to make use of this fix I migrated my project to use master (595688a32ad653d8e6cb1c7682b813f96125853e). I had to make a few changes (remove references to FreeRTOS heap measurement commands, add nvs_flash_init() before initialising WiFi) but then everything seemed to work well. The slave devices are all being polled correctly and everything seems happy.
The project is here: https://github.com/DavidAntliff/esp32-poolmon/tree/ESP-IDF_master
I came back a little while later and the application is crashing over and over with the following console output shortly after boot:
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Register dump:
PC      : 0x400859f3  PS      : 0x00060034  A0      : 0x80084685  A1      : 0x3ffb0590
0x400859f3: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-master/components/freertos/./queue.c:2037

A2      : 0x00000001  A3      : 0x00000000  A4      : 0x3ffb05b0  A5      : 0x00000002
A6      : 0x3ffbc970  A7      : 0x00060021  A8      : 0x800859f3  A9      : 0x3ffb0570
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x00000002  A13     : 0x3ffbadc0
A14     : 0x00000000  A15     : 0x400849fc  SAR     : 0x00000012  EXCCAUSE: 0x00000005
0x400849fc: i2c_isr_handler_default at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023

EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff

Backtrace: 0x400859f3:0x3ffb0590 0x40084682:0x3ffb05b0 0x40084a89:0x3ffb05e0 0x40082ba5:0x3ffb0610 0x4000bfed:0x00000000
0x400859f3: xQueueGenericSendFromISR at /Users/david/esp32/esp-idf-master/components/freertos/./queue.c:2037

0x40084682: i2c_master_cmd_begin_static at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023

0x40084a89: i2c_isr_handler_default at /Users/david/esp32/esp-idf-master/components/driver/./i2c.c:1023

0x40082ba5: _xt_lowint1 at /Users/david/esp32/esp-idf-master/components/freertos/./xtensa_vectors.S:1105

Rebooting...

A software or on-board reset does not stop this endless reset behaviour, however removing power for a short period of time does "fix" the issue. It is strange that a brief ESP32 reset does not clear it. (EDIT: but a long reset press does).

Could the first non-ISR call reach them if the FSM was in a bad state?
In the backtrace I can see that the watchdog did actually fire with the CPU at this line:
		taskENTER_CRITICAL_ISR(&pxQueue->mux);

So it is blocked by the mutex. I think I can imagine a situation where this could happen - if the non-ISR call to i2c_master_cmd_begin_static calls xQueueOverwriteFromISR and takes the mutex, but the ISR interrupts and tries to write to the queue, then the ISR will be blocked.
Yes, I have tried without the ATTiny, and I wasn't able to cause the problem. However I've also tried without the LCD 1602 and without the TSL2561 and I don't see the problem with those absent either (and sometimes it runs for days before the error occurs so it's hard to conclude anything in those cases), so I haven't been able to isolate it to a specific slave unfortunately. I only see this problem when all three are present, although with more time I can do more exhaustive testing. I suspect that it's interaction between transactions to multiple I2C slaves that might be causing the problem, but I do need to prove that.
I will try a few things:

your suggestion of an early call to i2c_hw_fsm_reset to try and stop the boot loop.
an experimental rewrite of i2c_master_cmd_begin to do the same operations but without the ISR-specific calls.
try to eliminate I2C slave devices by removing them and wait for the error to occur.
determine whether the SDA & SCL lines are pulled up or driven high by a slave (or the master) when the fault occurs.

In answer to 1, yes, calling i2c_hw_fsm_reset at the beginning of i2c_driver_install does stop the crash-boot-crash loop.

Hi,
I have a simular problem since IDF3.0rc1. With IDF2.1.1 there was no crash.
When a tmp102 is disconnected I got the following error until it's reconnected:
ESP_ERROR_CHECK failed: esp_err_t 0xfffffffff at 0x401068f1
0x401068f1: tmp102_init1 at C:/msys32/home/projects/ulp_cc_templogger/main/main.c:164
file: "C:/msys32/home/projects/ulp_cc_templogger/main/tmp102.c" line 199
func: tmp102_init1
expression: i2c_master_ccmd_begin(I2C_NUM_0, cmdconfig, 100 / portTICK_PERIOD_MS)
Backtrace: 0x400883bb:0x3ffc1f60 0x400887f1:0x3ffc1f80 0x401068f1:0x3ffc1fa0 0x40107261:0x3ffc1fc0 0x400d13f8:0x3ffc1ff0
0x400883bb: invoke_abort at Y:/VM/Share/GitHub/esp-idf-v3.0-rc1/components/esp32/panic.c:572
0x400887f1: _esp_error_check_failed at Y:/VM/Share/GitHub/esp-idf-v3.0-rc1/components/esp32/panic.c:584
0x401068f1: tmp102_init1 at C:/msys32/home/projects/ulp_cc_templogger/main/main.c:164
0x40107261: app_main at C:/msys32/home/projects/ulp_cc_templogger/main/main.c:460
0x400d13f8: main_task at Y:/VM/Share/GitHub/esp-idf-v3.0-rc1/components/esp32/cpu_start.c:456
Rebooting...
ets Jun  8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x17 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv::0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
Code:
void setup_i2c()
{
//Configure as I2C master
i2c_config_t conf;
conf.mode = I2C_MODE_MASTER;
conf.sda_io_num = SDA_PIN;
conf.scl_io_num = SCL_PIN;
conf.sda_pullup_en = GPIO_PULLUP_ENABLE;
conf.scl_pullup_en = GPIO_PULLUP_ENABLE;
conf.master.clk_speed = 100000;
ESP_ERROR_CHECK(i2c_param_config(I2C_NUM_0, &conf));
ESP_ERROR_CHECK(i2c_driver_install(I2C_NUM_0, I2C_MODE_MASTER, 0, 0, 0));

}
void tmp102_init1()
{
i2c_cmd_handle_t cmdconfig = i2c_cmd_link_create();
ESP_ERROR_CHECK(i2c_master_start(cmdconfig));
ESP_ERROR_CHECK(i2c_master_write_byte(cmdconfig, (TMP102_ADDR1 << 1 | I2C_MASTER_WRITE), ACK_CHECK_ON));
ESP_ERROR_CHECK(i2c_master_write_byte(cmdconfig, 0x01, ACK));		//configuration register
ESP_ERROR_CHECK(i2c_master_write_byte(cmdconfig, 0xE1, ACK)); //powersave + trigger oneshot
ESP_ERROR_CHECK(i2c_master_write_byte(cmdconfig, 0xA0, ACK)); //
ESP_ERROR_CHECK(i2c_master_stop(cmdconfig));
ESP_ERROR_CHECK(i2c_master_cmd_begin(I2C_NUM_0, cmdconfig, 100 / portTICK_PERIOD_MS));// Crash when tmp102 is not connected.
i2c_cmd_link_delete(cmdconfig);
i2c_cmd_handle_t cmdreadreg = i2c_cmd_link_create();
ESP_ERROR_CHECK(i2c_master_start(cmdreadreg));
ESP_ERROR_CHECK(i2c_master_write_byte(cmdreadreg, (TMP102_ADDR1 << 1 | I2C_MASTER_WRITE), ACK_CHECK_ON));
ESP_ERROR_CHECK(i2c_master_write_byte(cmdreadreg, 0x00, ACK));		//Set to read temperature
ESP_ERROR_CHECK(i2c_master_stop(cmdreadreg));
ESP_ERROR_CHECK(i2c_master_cmd_begin(I2C_NUM_0, cmdreadreg, 100 / portTICK_PERIOD_MS));
i2c_cmd_link_delete(cmdreadreg);
}
My problem is always reproducable. If there is a new test i2c driver, I can test it.

@ginodecock your ESP32 reboots because a call to ESP_ERROR_CHECK has failed - the function within has returned a non-ESP_OK code. As written, if any of your i2c function calls hit an error, your ESP32 will reboot. What you'll need to do is remove all the ESP_ERROR_CHECK wrappers and see if your code triggers a watchdog panic in the i2c interrupt handler.

@igrr does the ESP-IDF FreeRTOS port support "interrupt nesting"? Apparently calling a FromISR function outside of an ISR context is only "probably" safe if interrupt nesting is supported. I'm wondering if the problem I'm seeing is caused by an I2C hardware FSM failure in the non-ISR context of i2c_master_cmd_begin_static that causes it to call xQueueOverwriteFromISR, taking the internal mutex, only to be interrupted by the ISR, which then blocks itself on xQueueOverwriteFromISR and fires the watchdog, causing the ESP32 to reboot. Then, because the FSM freeze isn't addressed by i2c_hw_fsm_reset until after a subsequent transaction has started, this never gets to happen because any subsequent I2C transaction fails immediately. I'm not sure why this always results in a watchdog+reset at that point, but an early preventative call to i2c_hw_fsm_reset seems to avoid it.
There's still some gaps in my understanding. Any comments from Espressif would be helpful please. I'm going to try some tests this weekend to develop this hypothesis and then attempt to prove or disprove it.

Hi,
I don't see a watchdog panic in the i2c interrupt handler.
When modifying the ESP_ERROR_CHECK I got -1 as reported error.

HI, Sorry I am coming late into this discussion but some of the problems look familiar. Some background.
We have custom designed and built ESP32 controller with 8x I2C/1-Wire (DS2482-800 bridge) inputs and 16x I2C/GPIO (PCA9555) outputs with various other inputs. The 1-Wire inputs are used to read iButtons (room access and bathroom water access) and the 16x GPIO's outputs are used to drive 8x LEDs (in the iButton readers) and 8x Relays (switching door strikers and water solenoid valves).
In a test environment with short leads all worked perfectly but in the live environment with longer UTP cabling driving the LED & Striker and reading the 1-Wire we had catastrophic results. Similarly on the bathrooms where the DC solenoid and LED/1Wire cabling was separated.
The solution (so far) has been very simple. We simply soldered an 1N4007 diode with reverse bias as close as possible to the door striker and the water solenoid valve. This has the effect of absorbing (shorting) the reverse EMF introduced when power is removed from the striker or solenoid valve.
I have not been able to look at your schematic since the link is not working.
Hope this helps a bit.
Andre

@ammaree Hi André, thank you for your comments. I'll fix the link shortly.
It's fairly clear to me that I have some electrical issues on one of my I2C sensors, and your suggestion may well help with that. However, I tried an experiment: I set up four I2C slave devices (AVR ATtiny84 and 85s) on very short cables, and wrote an ESP32 program to fire off I2C transactions to each in parallel. The bus looks good and it runs well at 400 kHz. However, in the middle of the night, there was a single incident which triggered this bug, causing a watchdog timeout and then a subsequent crash loop.
So, my concern is that although I can make my own electrical side more reliable (and I will), there's a serious bug in ESP-IDF at the moment which causes a catastrophic and persistent failure once triggered. I'd like to track this down and solve it, because it seems that even with a good I2C bus, there's always the risk of an error that could cause this problem.
The challenge at the moment is finding a way to trigger this bug reliably. It's easy to create a noisy bus, but it seems that this bug is related to a possible race in the driver that is only apparent on a noisy bus, but is still relatively rare. Once I can get a simple circuit working that reliably triggers the bug, it should become a bit easier to track it down.

I fixed the schematic link earlier. Here it is too.

I've found a reliable way to cause the crash involving 4 x AVRs acting as I2C slaves, and a long cable to a TSL2561, however I will work on simplifying the set-up so that it can be reproduced by others - more on this soon.
Note: I disabled the crash loop by calling i2c_hw_fsm_reset at the beginning of i2c_driver_install. This helps because now it only crashes due to the "initial" fault.
It now crashes pretty reliably every 30 seconds or so. Using the gdb info line *0xaddress technique, I've inspected the stack traces and although the reported error is always "Core 0 panic'ed (Interrupt wdt timeout on CPU0)", and it always happens within the i2c driver, the exact location of each panic varies a little. Here's a selection of the places where it has failed - each one is the first frame reported in the backtrace, over a series of independent crashes in the same build:
(gdb) info line *0x400866ed
Line 157 of "/Users/david/esp32/esp-idf-v3.0/components/freertos/./portmux_impl.h"
   starts at address 0x400866ed <vTaskExitCritical+53> and ends at 0x40086705 <vTaskExitCritical+77>.

       assert(mux->count < 0x100); // Indicates memory corruption

(gdb) info line *0x40086604
Line 4203 of "/Users/david/esp32/esp-idf-v3.0/components/freertos/./tasks.c"
   starts at address 0x40086604 <vTaskEnterCritical> and ends at 0x40086607 <vTaskEnterCritical+3>.

#ifdef CONFIG_FREERTOS_PORTMUX_DEBUG
    void vTaskEnterCritical( portMUX_TYPE *mux, const char *function, int line )
#else
    void vTaskEnterCritical( portMUX_TYPE *mux )
#endif
    {    // <------ Line 4203
        BaseType_t oldInterruptLevel=0;

(gdb) info line *0x400849d9
Line 376 of "/Users/david/esp32/esp-idf-v3.0/components/driver/./i2c.c"
   starts at address 0x400849cf <i2c_isr_handler_default+111> and ends at 0x400849db <i2c_isr_handler_default+123>.

                p_i2c_obj[i2c_num]->status = I2C_STATUS_ACK_ERROR;

(gdb) info line *0x400845e0
Line 1168 of "/Users/david/esp32/esp-idf-v3.0/components/driver/./i2c.c"
   starts at address 0x400845dc <i2c_master_cmd_begin_static+124>
   and ends at 0x400845e9 <i2c_master_cmd_begin_static+137>.

        xQueueOverwriteFromISR(p_i2c->cmd_evt_queue, &evt, &HPTaskAwoken);

(gdb) info line *0x4008560b
Line 2065 of "/Users/david/esp32/esp-idf-v3.0/components/freertos/./queue.c"
   starts at address 0x40085606 <prvCopyDataToQueue+106> and ends at 0x40085612 <prvCopyDataToQueue+118>.

                --( pxQueue->uxMessagesWaiting );

Note that it stops in a different place each time - could this be due to memory corruption as one of the code comments above suggests?

Also, I think I have disproved my earlier hypothesis that the queue mutex is being held by the non-ISR context call to xQueueOverwriteFromISR, resulting in a watchdog timeout. I added some logging around the mutex take and give and after many, many crashes I haven't seen any evidence that the ISR is blocked by the non-ISR's hold on the mutex. So I think we can discount this theory.

@panfeng-espressif @igrr I have found a way to reproduce this issue with a much simpler program and hardware setup.
Please see my new repository here: https://github.com/DavidAntliff/esp32-i2c-error-1503
With my "DOIT" boards I'm able to reproduce simply by hooking up two wires to two GPIOs (as I2C SDA and SCL) and repeatedly touching them together. Not a true representation of any properly configured I2C bus, of course, but it does trigger the exact same issue I see in my "complete" system, without all the overhead of extra I2C devices, use of RMT, WiFi, etc.
This should hopefully make it much easier for the Espressif team to reproduce and debug. Please let me know if this helps.

I would suggest you add some logging to the isr and see if there are a bunch of interrupts being generated at the same time.  If so then instead of looping certain code paths in the isr should probably clear ALL interrupts before calling other functions.

@negativekelvin does ESP-IDF support any logging from an ISR? I assume printf isn't going to work as it will be too slow. I can log simple values to an ad-hoc timestamped array but if something already exists I'll use that.
When you say "multiple interrupts being generated at the same time" do you mean that all-but-one interrupt is being ignored, or that they are being resolved in an incorrect order? What sort of bug do you anticipate here? The hardware FSM is getting "stuck" in this case, so I'm keen to better understand how this might relate to interrupts.
Or, are you suggesting that the ISR is spinning (looping) too much due to too many interrupts (in too short a time) and that causes the watchdog to fire? That seems plausible and fast logging might show that up.

ESP_EARLY_LOGI
Yes too many interrupts or some other race condition between two interrupts

I haven't gotten nearly as deep into this as @DavidAntliff has but I believe I am also having the same issues.  It behaves exactly like he described.  It will work reliably for a day straight then suddenly go into an endless bootloop with the same Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0) error until I disconnect power completely.
Here are the complete logs right before the reboot:
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x400845fd  PS      : 0x00060034  A0      : 0x80084a7c  A1      : 0x3ffb05b0
0x400845fd: i2c_master_cmd_begin_static at /home/khendricks/dev/esp32/tools/esp-idf/components/driver/./i2c.c:947

A2      : 0x00000001  A3      : 0x00000001  A4      : 0x800d17de  A5      : 0x3ffbb880
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x3ffbd0d8  A9      : 0x00000001
A10     : 0x00000001  A11     : 0x00000000  A12     : 0x3ffb05b0  A13     : 0x00000002
A14     : 0x3ffbd1e4  A15     : 0x00060021  SAR     : 0x00000011  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff
Core 0 was running in ISR context:
EPC1    : 0x400d1b9a  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x400845fd
0x400d1b9a: esp_vApplicationIdleHook at /home/khendricks/dev/esp32/tools/esp-idf/components/esp32/./freertos_hooks.c:85

0x400845fd: i2c_master_cmd_begin_static at /home/khendricks/dev/esp32/tools/esp-idf/components/driver/./i2c.c:947

Backtrace: 0x400845fd:0x3ffb05b0 0x40084a79:0x3ffb05e0 0x40082b95:0x3ffb0610 0x400d1b97:0x00000000
0x400845fd: i2c_master_cmd_begin_static at /home/khendricks/dev/esp32/tools/esp-idf/components/driver/./i2c.c:947

0x40084a79: i2c_isr_handler_default at /home/khendricks/dev/esp32/tools/esp-idf/components/driver/./i2c.c:947

0x40082b95: _xt_lowint1 at /home/khendricks/dev/esp32/tools/esp-idf/components/freertos/./xtensa_vectors.S:1105

0x400d1b97: esp_vApplicationIdleHook at /home/khendricks/dev/esp32/tools/esp-idf/components/esp32/./freertos_hooks.c:85

Core 1 register dump:
PC      : 0x400d1b9a  PS      : 0x00060034  A0      : 0x80086748  A1      : 0x3ffbbe40
0x400d1b9a: esp_vApplicationIdleHook at /home/khendricks/dev/esp32/tools/esp-idf/components/esp32/./freertos_hooks.c:85

A2      : 0x00000008  A3      : 0x00000001  A4      : 0x00000001  A5      : 0x3ffbb984
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x3ffb371c  A9      : 0x3ffb36e0
A10     : 0x00000000  A11     : 0x80000001  A12     : 0x00000000  A13     : 0x00000001
A14     : 0x00060021  A15     : 0x00000000  SAR     : 0x00000000  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

Backtrace: 0x400d1b9a:0x3ffbbe40 0x40086745:0x3ffbbe60
0x400d1b9a: esp_vApplicationIdleHook at /home/khendricks/dev/esp32/tools/esp-idf/components/esp32/./freertos_hooks.c:85

0x40086745: prvIdleTask at /home/khendricks/dev/esp32/tools/esp-idf/components/freertos/./tasks.c:4571

My current setup is a single ST VL53L0X Time-Of-Flight sensor hooked up to the ESP32 via a 56cm cable and 4.7kohm pull-up resistors.  My esp-idf is on master at commit https://github.com/espressif/esp-idf/commit/daa8cfa800677a71a3447eba418a4336979a3cb8 .

Appears I too have experienced this same issue.  One SHT-31 on the i2c bus and seven devices on a 1-wire bus (via RMT).  Log message immediately proceeding the WDT timeout indicated the read of the SHT-31 failed with esp_rc=-1
`I (1265887) mcrTimestamp:  Sat Feb  3 23:45:50 2018 heap=166k first=259k min=163k max=170k delta=120
W (1265917) mcrI2c readSHT31: read failed for i2cDev(mcrDev(mcrDevAddr(0x44) id=i2c/542419a4ae30.01.sht31 desc=sht31 rus=20374 wus=0 reading=0x3ffd5cb4) bus=1 use_mplex=true) esp_rc=-1
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x400845ff  PS      : 0x00060034  A0      : 0x40082560  A1      : 0x3ffb05e0
0x400845ff: i2c_isr_handler_default at /Users/thughey/devel/esp-idf/components/driver/./i2c.c:1023
0x40082560: _xt_lowint1 at /Users/thughey/devel/esp-idf/components/freertos/./xtensa_vectors.S:1105
A2      : 0x3ffbee50  A3      : 0x3ff53000  A4      : 0x00000400  A5      : 0x00000000
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x00000001  A9      : 0x00000000
A10     : 0xabc4f586  A11     : 0x00000001  A12     : 0x800d3132  A13     : 0x3ffbdb20
A14     : 0x00000000  A15     : 0x00000000  SAR     : 0x00000015  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff
Core 0 was running in ISR context:
EPC1    : 0x400d3402  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x400845ff
0x400d3402: esp_vApplicationIdleHook at /Users/thughey/devel/esp-idf/components/esp32/./freertos_hooks.c:85
0x400845ff: i2c_isr_handler_default at /Users/thughey/devel/esp-idf/components/driver/./i2c.c:1023
Backtrace: 0x400845ff:0x3ffb05e0 0x4008255d:0x3ffb0610 0x400d33ff:0x00000000
0x400845ff: i2c_isr_handler_default at /Users/thughey/devel/esp-idf/components/driver/./i2c.c:1023
0x4008255d: _xt_lowint1 at /Users/thughey/devel/esp-idf/components/freertos/./xtensa_vectors.S:1105
0x400d33ff: esp_vApplicationIdleHook at /Users/thughey/devel/esp-idf/components/esp32/./freertos_hooks.c:85
Core 1 register dump:
PC      : 0x400d3402  PS      : 0x00060334  A0      : 0x80086d08  A1      : 0x3ffbe0e0
0x400d3402: esp_vApplicationIdleHook at /Users/thughey/devel/esp-idf/components/esp32/./freertos_hooks.c:85
A2      : 0x00000008  A3      : 0x00000001  A4      : 0x00000001  A5      : 0x3ffbdc18
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x3ffb34fc  A9      : 0x3ffb34c0
A10     : 0x00000000  A11     : 0x00000001  A12     : 0x8008571f  A13     : 0x3ffc6080
A14     : 0x00000003  A15     : 0x00060023  SAR     : 0x00000000  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000
Backtrace: 0x400d3402:0x3ffbe0e0 0x40086d05:0x3ffbe100
0x400d3402: esp_vApplicationIdleHook at /Users/thughey/devel/esp-idf/components/esp32/./freertos_hooks.c:85
0x40086d05: prvIdleTask at /Users/thughey/devel/esp-idf/components/freertos/./tasks.c:4554
CPU halted.
`

Unfortunately I haven't had a chance to investigate this further - in particular the possibility of a flood of interrupts starving the watchdog. I hope to revisit at some stage but I'm not sure when, as I've already spent three weeks chasing this and I need to move on with other tasks. Of course eventually I'll be forced to revisit if it isn't fixed in the meantime since my project is pretty much dead with this issue present.
In the meantime I believe I've demonstrated that the problem is real, is not related to my project specifically, and that there should be enough info here for Espressif to take over, reproduce and find the root cause.
On that note, has anyone had a chance to follow my reproduction instructions and reproduce the issue by simply brushing two wires together while running my example code? I've noticed it's more difficult to reproduce on certain boards (newer LoLin32 Lite boards seem much more resilient than my older "DOIT" boards) , however I've been able to eventually reproduce it on all of mine, so it would be interesting to see how easily anyone can reproduce it on other boards, since I think there's some sort of electrical component to this too (perhaps in how bus noise propagates onto the board and triggers interrupts).

I've not attempted to recreate the issue with your code or by brushing wires together.  At this point my code is stable after I cleaned up my code to avoid hammering away at the i2c bus.  I'll let me board soak for awhile to see if the issue resurfaces.

Seem's I'm having the same (or very similar) issue as the rest here. In my case I always get timeouts reported by the I2C driver (the actual text is from my own I2CMasterDevice class) just before the timeout.
I'm communicating on two separate buses with two ADS1115 and one MCP23017. They are both read based on a timer tick() as well as a "ready interrupt" from the respective devices.
It happens very rarely (many days in between) so I don't have more than a stack trace.
E (4356362) I2CMasterDevice: Error during read - Send command error, no ACK from slave
E (4356362) I2CMasterDevice: Error during write - Send command error, no ACK from slave
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
Core 0 register dump:
PC      : 0x40083f3c  PS      : 0x00060034  A0      : 0x400824f4  A1      : 0x3ffb09f0
0x40083f3c: i2c_master_cmd_begin_static at /home/permal/esp/esp-idf/components/driver/./i2c.c:778

0x400824f4: _xt_lowint1 at /home/permal/esp/esp-idf/components/freertos/./xtensa_vectors.S:1105

A2      : 0x3ffd9848  A3      : 0x3ff67000  A4      : 0x00000400  A5      : 0x00000001
A6      : 0x00000000  A7      : 0x00000000  A8      : 0x800843cc  A9      : 0x00000000
A10     : 0x00000001  A11     : 0x00000001  A12     : 0x800d350a  A13     : 0x3ffc0160
A14     : 0x00000000  A15     : 0x00000000  SAR     : 0x00000012  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff
Core 0 was running in ISR context:
EPC1    : 0x400d2242  EPC2    : 0x00000000  EPC3    : 0x00000000  EPC4    : 0x40083f3c
0x400d2242: esp_vApplicationIdleHook at /home/permal/esp/esp-idf/components/esp32/./freertos_hooks.c:85

0x40083f3c: i2c_master_cmd_begin_static at /home/permal/esp/esp-idf/components/driver/./i2c.c:778

Backtrace: 0x40083f3c:0x3ffb09f0 0x400824f1:0x3ffb0a20 0x400d223f:0x00000000
0x40083f3c: i2c_master_cmd_begin_static at /home/permal/esp/esp-idf/components/driver/./i2c.c:778

0x400824f1: _xt_lowint1 at /home/permal/esp/esp-idf/components/freertos/./xtensa_vectors.S:1105

0x400d223f: esp_vApplicationIdleHook at /home/permal/esp/esp-idf/components/esp32/./freertos_hooks.c:85

Core 1 register dump:
PC      : 0x400d2242  PS      : 0x00060234  A0      : 0x8008b330  A1      : 0x3ffc0740
0x400d2242: esp_vApplicationIdleHook at /home/permal/esp/esp-idf/components/esp32/./freertos_hooks.c:85

A2      : 0x00000008  A3      : 0x00000001  A4      : 0x00000001  A5      : 0x3ffc0270
A6      : 0x00000000  A7      : 0x00000001  A8      : 0x3ffb34b0  A9      : 0x3ffb3474
A10     : 0x00000000  A11     : 0x00000000  A12     : 0x8008a578  A13     : 0x3ffdf6b0
A14     : 0x00000000  A15     : 0x3ffc0400  SAR     : 0x00000000  EXCCAUSE: 0x00000005
EXCVADDR: 0x00000000  LBEG    : 0x00000000  LEND    : 0x00000000  LCOUNT  : 0x00000000

Backtrace: 0x400d2242:0x3ffc0740 0x4008b32d:0x3ffc0760
0x400d2242: esp_vApplicationIdleHook at /home/permal/esp/esp-idf/components/esp32/./freertos_hooks.c:85

0x4008b32d: prvIdleTask at /home/permal/esp/esp-idf/components/freertos/./tasks.c:4702

Hello, I found that sometimes there was a strange low level on SCL when SDA was prepared to start a I2C transmission. This made I2C transmission failed sometimes. Have you met such kind of condition before?

Pretty sure I am seeing this now as well. I've just updated IDF to a5eb369126e5cef31715d2755931cf933bb98bee and now am getting random watchdog crashes after a failed I2C read:
E (105377) FB_HAL_V1R (0107) fb_hal_battery_task fb_hal_adc_read_channels
ets Jun  8 2016 00:22:57

rst:0x7 (TG0WDT_SYS_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:5648
ho 0 tail 12 room 4
load:0x40078000,len:0
load:0x40078000,len:13912
entry 0x40078fd8
W (91) boot: PRO CPU has been reset by WDT.
W (91) boot: WDT reset info: PRO CPU PC=0x40085652
0x40085652: spi_flash_op_block_func at /Users/jason/esp/esp-idf/components/spi_flash/./cache_utils.c:82 (discriminator 1)

W (91) boot: WDT reset info: APP CPU PC=0x40093ebf
0x40093ebf: is_free at /Users/jason/esp/esp-idf/components/heap/./multi_heap.c:339
 (inlined by) multi_heap_malloc_impl at /Users/jason/esp/esp-idf/components/heap/./multi_heap.c:370

I appreciate that these things take time. I'm disappointed that after 15 days there hasn't been an Espressif reply to my reproduction instructions. Once I found a way to easily reproduce it I had what I thought to be a reasonable expectation that Espressif would at least try it out and report back. It only takes a few seconds to put the test system together, compile and flash my GitHub project, then brush a few wires together to reproduce the bug. I can reproduce it on all my ESP32 boards (across two manufacturers).
Unfortunately I lack the experience and equipment to debug a timing issue in an interrupt service routine, especially as ESP_EARLY_LOG adds delays to the routine that affect the timing. Someone at Espressif with a hardware debugger would make much faster work of this issue. However if there's additional testing I can do, I'm more than happy to do so - I just need some guidance please.

Hi David !
I suggest that you scope (with osciloscope)  the SDA and SCL lines during your tests. Test one device at time. I noticed that both lines are very sensitive to the squaring of signals! In my case, I used 3K3 ohms resistors to pullup lines. I have seem  that you are using internall pullups.
When I scoping the first test, the SCL  produce constant clock 100 KHz ! - strange behavior. After 3k3 resistors , both SDA and SCL function correctly.
https://www.esp32.com/viewtopic.php?f=18&t=4742&p=20511&hilit=i2c+scanner#p20511

@Gustavomurta thanks for the advice. Here's the thing - I know that my I2C bus isn't perfect, and it would be good if I could condition my signals to avoid an issue, but the problem is that there's always a risk of errors on the bus due to noise. In the event of a failed I2C transaction, the bus will be in an error state, and that's fine. The problem is that the ESP32 peripheral has a bug that causes its internal finite-state-machine (FSM) to lock up. This is a known issue and acknowledged by Espressif. There is a fix in the 3.0 stream that attempts a FSM reset when there is a transaction timeout and the hardware busy flag is still raised. The issues that I have are related, I think:

there's some sort of condition that occurs when the bus is in an errored state that results in the interrupt service routine starving the scheduler and causing a watchdog reset.
almost every single time this happens, the subsequent reset causes another crash because the FSM is in the locked state, and there's no code in the I2C init function to reset the FSM state. The reset only occurs after a failed transaction, but at init time there are no transactions yet. So it doesn't get cleared. I added a FSM reset and that appeared to avoid this second issue (a reset due to 1. no longer causes a chain of resets due to 2.)

So my point is that although there's a lot I can do to improve the I2C bus in my particular circuit, there's a real issue with the ESP32 software interaction with the hardware at the moment that is causing I2C for multiple people, and Espressif are in the best possible place to investigate this now that there's a way to reproduce it.
I am using external pull-ups BTW. The issue is also unrelated to bus speed. It happens at 10 kHz almost as often as it happens at 100 kHz.

Ok, I was curious to know what the value of the resistors you are using. Thank you.

I have also recently faced this problem, and I agree with @DavidAntliff that there is something wrong in i2c driver not being fully tolerant to errors in transmissions.
In my case, it was due to not using external pullups, so I was just using the internal ones, with just one peripheral and 5cm cables in a breadboard. I was seeing random communication errors, and at some point, the wdt interrupt timeout error would appear. Once this error appeared, ESP32 was stuck in a reboot loop. I had to unpower the ESP32, or make a long push on the reset button, in order to work again. When touching the cables with my fingers, this happened a lot more and earlier, that's how I realized I needed external pullups.
Once I put external pullups (4.7K), all communication errors and wdt interrupt errors are gone. But I understand there is something wrong with the driver, and there is the risk of entering this error state. Maybe if there is a lot of external EMI? Or maybe if some connection is a bit loose? Or in case the i2c pad of the wrover module I am using disconnects from my pcb and catches EMI noise... I dont know...
This scares me because my product has internal battery and there is no power switch, nor a reset button... and the battery and pcb is inside a housing, not accesible to the user...  So if this happens, I am in a big trouble, and the product will have to be shipped back to me in order to open it and unpower it. Right now I am looking for a solution and I may add a way of resetting ESP32 from another MCU, my product has ESP32+nRF52.
This should be addressed looking for the real cause and fixing it, in order to make i2c driver fully tolerant to communication errors.
I have seen some people at the forum reporting that some gpio interrupts are happening more times than expected, could this be related?
Maybe the EMI noise + extra interrupts triggering are overflowing the interrupt handler or taking too much time?

Hi Luis, If there are many doubts, I suggest you to test with  3K3 resistors for 3.3V.
4K7 resistors are for 5V.

Thank you @Gustavomurta .
Using an oscilloscope was on my to-do list, but I did not get to do it because pullups seemed to fix the error.

@panfeng-espressif sorry, I missed your comment:

Hello, I found that sometimes there was a strange low level on SCL when SDA was prepared to start a I2C transmission. This made I2C transmission failed sometimes. Have you met such kind of condition before?

No, I haven't specifically noticed this - is this something you've seen with my circuit, or in general? My reproduction method ("brush the SDA/SCL wires together") could easily replicate this scenario though. I thought that it was a known issue that grounding SCL or SDA at the wrong time could cause the FSM to enter a locked state?

Just found this other issue at the arduino-esp32 repo, could be related?
https://github.com/espressif/arduino-esp32/pull/1065
Can anyone test if changing that pin declaration as they propose has any effect?

@DavidAntliff
Because we are celebrating the Spring Festival the last week, I'm quite sorry for the last response.
It is the phenomenon I saw with your code. When using the example code of ESP-IDF, it didn't come out. I would take your suggestion and do further test .

@luisonoff thanks, I'll look into it with my reproduction code.
@panfeng-espressif ok, that sounds strange - I can't recall anything in my code that would drive SCL low - the GPIO is only used for I2C operations. Do you see this often? I will keep an eye out for it.

I think I have had the same boot-loop issue a few times, using IDF da81b97 (git from 2017-12-31).

I am seeing this issue using esp-idf master 3ede9f (Feb 20, 2018) and using ESP32-DevKitC.
In my case, I first observed this issue while running a test whose side effect is some noise on the I2C bus. This noise in turn leads to some failed I2C transactions after which I immediately see the crash with
Guru Meditation Error: Core  0 panic'ed (Interrupt wdt timeout on CPU0)
During normal circumstances when all I2C transactions succeed (with a 1.2K pullup), I can keep running without any errors.
In trying to reproduce the same error without running my complicated test, I was able to use pull-ups of a higher value (4.7K) to cause the crash. In this case I observe quite a few failed I2C transactions during normal operation and then the crash.
Seems like the driver is not able to handle some error conditions and ultimately causes the crash. Would be great if someone can look into this since it is hard to guarantee that the I2C bus will always function without any errors.

@luisonoff When the FSM gets hungup in a Bus Busy state, it can be recovered by manually stimulating SCL, SDA.  I have connected 2 additional GPIO pins, one to SCL. one to SDA. By transmitting a START, (SDA going low while SCL high, then nine SCL High->Low, then (STOP) SCL High (100us delay)then SDA High. This bus busy state can be cleared.
Chuck.

@stickbreaker interesting - I see you've done some work on this on the Arduino side. Can you explain how your FSM clearing approach is different to i2c_hw_fsm_reset()?
However the main issue, in my opinion at least, is the watchdog reset inside the interrupt service routine, and it's not 100% clear to me that this is caused by the FSM busy state (although all indicators so far suggest that it is). Is there an opportunity to trap and clear this FSM busy state before the watchdog timeout occurs? I suspect not though, since the interrupts have already been generated. But this is all guesswork on my part.
@panfeng-espressif @igrr Given that many people have now reported seeing this issue too, is Espressif able to give us an update on their investigation please? I'm hoping for a fix so my project can proceed.

@DavidAntliff i2c_hw_fsm_reset() is attempting to work around the problem that the fsm will see a glitch on SDA as a multiMaster bus capture. Once the FSM sees 'another' master transacting the bus it will initiate a Bus_Busy State until it sees a complete transaction with a Valid STOP. The basis of this problem is the FSM's interpretation of START:

A START condition is High SCL, HIGH SDA then SDA LOW then SCL LOW.
The FSM interprets SCL HIGH, SDA HIGH  then SDA LOW then SDA HIGH.
This LOW going 'glitch' on SDA should not be interpreted as START, It should just be ignored.  The reason the protocol defines START as a voltage level sequence is to immunize the FSM from signal glitches.

Since all of the problems have been encountered by people using the ESP32 in a SINGLE Master I2C configuration, the FSM will infinitely hang waiting for the 'other' master to complete it's transaction.
The use of additional GPIO pins to act as another I2C master will solve the Bus_Busy problems,  Actual TIMEOUT interrupt cascades I haven't solved.
static esp_err_t i2c_master_clear_bus(i2c_port_t i2c_num) acts like an I2C master to send out a null transaction. Except, there is no initial START(It drops SCL before SDA). So, it is another illegal transaction.
i2c_master_clear_bus
 gpio_set_direction(scl_io, GPIO_MODE_OUTPUT_OD);
    gpio_set_direction(sda_io, GPIO_MODE_OUTPUT_OD);
    gpio_set_level(scl_io, 0);
    gpio_set_level(sda_io, 0);
    for (int i = 0; i < 9; i++) {
        gpio_set_level(scl_io, 1);
        gpio_set_level(scl_io, 0);
    }
    gpio_set_level(scl_io, 1);
    gpio_set_level(sda_io, 1);
    i2c_set_pin(i2c_num, sda_io, scl_io, 1, 1, I2C_MODE_MASTER);
return ESP_OK;

This code should be changed to something like this:
    gpio_set_level(scl_io, 1); // initial condition SCL needs to be High
    gpio_set_level(sda_io, 1);// initial conditions SDA needs to be high
    // a small delay (5us) 1/2 clock at 100khz
    gpio_set_level(sda_io, 0);// Issues START
    // a small delay (5us) 1/2 clock at 100khz
     for (int i = 0; i < 9; i++) {
        gpio_set_level(scl_io, 0);
    // a small delay (5us) 1/2 clock at 100khz
        gpio_set_level(scl_io, 1);
    // a small delay (5us) 1/2 clock at 100khz
    }
    gpio_set_level(sda_io, 1); // Issue STOP

The history of needing this function traces back to hardware glitches that occur when attaching the GPIO pins to the hardware peripheral.  @ESP32DE and I solved these glitches for the Arduino environment proposal to i2c.  I don't know the equivalent pin assignment sequence for IDF.  I don't use directly use esp32-IDF.
In my testing I no longer need to execute this function at every boot.
with a quick looking through of the IDF i2c code, I see a few design idea I don't support.

First, exiting through portYIELD_FROM_ISR(); at every opportunity.
portYIELD_FROM_ISR(); should only be called at the end of the ISR.  If one of the OS calls returns (HPTaskAwoken == pdTRUE), Then at the END of the ISR call portYIELD_FROM_ISR() instead of just exiting the ISR.  HPTaskAwoken just means that the FOREGROUND process must Yield. not the ISR. so, as soon as you complete your ISR (which should be Short, Deterministic, and NO waits) Call portYIELD_FROM_ISR(); to task switch to the higher priority FOREGROUND task.

I think the multiple portYIELD_FROM_ISR() throughout the ISR is the cause/basis of this Issue.  A single interrupt is not completing before the next byte moves.  HPTaskAwoken only needs to be acted on ONCE, just before the end of the ISR.  I would create a SINGLE HPTaskAwoken variable at the top of the ISR and pass it by reference to all sub-Functions.  The FreeRTOS ISR functions will not clear it, only SET it.  So, if any of the OS functions set it, it will cascade until that last step before the ISR returns.  I haven't studied this ISR, in my verion, I have a subfunction that does my exit operations it is the only place that can call portYIELD_FROM_ISR().
This code is from my ISR statemachine.
 if (activeInt & I2C_TRANS_COMPLETE_INT_ST_M) {
    i2cIsrExit(p_i2c,EVENT_DONE,false);
    return; // no more work to do

inside i2cIsrExit() all of my ISR cleanup, foreground notifications, and a potential portYIELD_FROM_ISR() is executed, the return; exits from my ISR back to the interrupted foreground task.
From my point of view, ISR's must complete. They are atomic. If an ISR can't complete in a short FINITE timespan, it is coded wrong.

Second, I have discovered the FSM.command[] list has some order rules. If the command I2C_CMD_END is used, when the command[] buffer is refilled, the positions of command[] at and beyond where I2C_CMD_END was placed cannot be reused.
In my implementation of I2C for Arduino, If I need to use I2C_CMD_END because of data block length I only use command[15] for end. The FSM allows each command to move upto 255 bytes, so before I need to use an 'END' a Master Write would have to send over 3060 bytes. A single Read is a little more limited because of the last byte NAK.  I don't see any consideration for these 'rules'.

Chuck.

@DavidAntliff I have reported this issue, and our engineer is working on the problem now. As soon as we have any conclusion, I will reply to you here.

Is this Problem related to https://www.esp32.com/viewtopic.php?f=2&t=2632&p=16910&hilit=juergen#p16910?
I saw that the I2C Interrupt randomly stopped working and the i2C Interrupt monitoring timed out.
What I found out was: it never occured if I have no Network traffic through WLAN. (using REST requests). And when I am hammering the System with a high frequency of web requests the I2C fails much more often and the I2C timeout stopps.
I assume that there is a Problem with the Interrupt handler between I2C and somewhat of  websocket activities through WLAN (as STA or AP does not matter).
The i2c Fails when having Websocket acticities. When there is more activity it fails more often  And it does not without websocket activities.
Juergen

Software reset does not reset peripherals. so, when the I2C state machine has a serious error, the system will restart repeatedly unless a  system reset.  I found, when the  the communication environment is relatively poor, ack will be wrong, and then generate an interruption. we use a while loop to handle all interrupts, houwerver,  for some reason, ack error caused this loop to execute more than 700 times in isr context. so the system crashed.  we are looking for a solution to this problem and any progress will be notified here. thanks !!

@koobest I just found a way to reset the I2C peripherals that seems to do a power on reset.  It clears out all registers, resets the Bus_busy flags, initializes the hardware state back to a Power On condition.
I work on the Arduino branch,  a patch merge containing just this reset is arduino-esp32 pr 1201.
Chuck.

@koobest if you can work out why the ISR loop runs 700 times (and presumably neglects kicking the watchdog resulting in the crash) then that would be very useful, as I believe that is the main issue here.
If you call  i2c_hw_fsm_reset in i2c_driver_install then this also stops the repeated crashing. It will still crash once, of course.

Just wanted to let you know that there is a new commit in master from today that seems to fix this issue. I have not tested it yet.  :)

@luisonoff thank you for the alert!
I have tested ESP-IDF commit 391c3ff959f9eb1b2975cb0d7b29c0478f3b6a48 with my reproduction project on one of my "DOIT" boards and I can happily report that I am unable to reproduce my issue by rubbing SDA and SCL together rapidly. I spent maybe 4 minutes rapidly mechanically shorting them and did not see a single crash.
Then I reverted back to 2e7613b6560775b27c50eb81e81d5c3ff712b866 (just prior to the "fix") and verified that the issue can be reproduced. In fact it was extremely easy to reproduce it, many times per minute.
So I can conclude from this that commit 892f3907fa2e074943e865b68f2fda3da600584b appears to resolve the issue, for me at least, on this board.
I'll try it on my Wemos LoLin32 Lite next, and report back if the results are any different.

I can also confirm that this fix works for me. My ESP32 does not crash anymore even though there is noise on the I2C line.
Thanks.

Another successful story. I was using an SSD1306 via i2c combined with a UART device and it used to fail. Updated to the latest version that includes this fix and now things just work!!! :D
Thanks for this great fix. My hobby project can now continue!!

Hi DavidAntliff ,
I am trying to apply the patch 892f390 but unfortunately I am using arduino ide and I did not find the file i2c.c.
So my question is where is the file driver/i2c.c in arduino ide and how to apply the patch in arduino ide.
Please guide me to resolve the i2c issue due to watch dog timer.
Thanks and regards,
Satyabrata


sox

Hi there,
I see this warning, is it required?
'sox' is not recognized as an internal or external command,
operable program or batch file.
SoX could not be found!

You need to go into your environment path and add sox there for it to show up in the terminal. Click new and add the path of the file.

If you tried running this on colab notebook, I have added a commit to fix this issue, so deleting and restarting the runtime should make it work now.

Appreciate your work in providing this code. Thanks a lot.
That error went away.
Is this of any concern faiss avx2?
2023-09-06 07:52:33 | INFO | faiss.loader | Loading faiss with AVX2 support.
2023-09-06 07:52:33 | INFO | faiss.loader | Could not load library with AVX2 support due to:
ModuleNotFoundError("No module named 'faiss.swigfaiss_avx2'")
2023-09-06 07:52:33 | INFO | faiss.loader | Loading faiss.
2023-09-06 07:52:34 | INFO | faiss.loader | Successfully loaded faiss.

No its not an issue. It'll still work with that warning.


enrich the model via composition

Thoughts on how we might get the concept of enhancing our content such as exhibitions, installations, etc etc - basically leveraging the work done on the article body, and allowing us to enrich the other bits of content.
What this is proposing is we create another layer, the web layer, which carries with it data that is specific to our site, but not necessarily the content itself. I am thinking of it as: "If we were an API, what would we expose, and what would we not.".
This means that descriptions etc is still definitely necessary for SEO, sharing, RSS and any other form of distribution, but we can also have a more enriched version for our specific needs on the site when we want to make things shine.
What the body might look like?

Questions and considerations:

As it stands, all bodies are equal. An enriched body is the same shape whether it's part of an exhibition, installation, or event. To maintain multiple shapes and renderings would have too high a cost in maintenance for the size of the team, and probably the value changing it would add (but always happy to be told how not).
What technical restrictions are we imposing on ourselves?
How do we avoid conflating this with real model data i.e. relationships? e.g. How do we make sure that an exhibition has the relationship to it's exhibits, when we've allowed you to just embed it in the body (a reason people won't do that is you then lose the 2 way relationship)...
Which content types would we want this on?
Is this something we want?
How much work is it to do?

Closing in favour of smaller PRs.


Revert "added support for cells with multiplicity=* in the kore to ja…

Reverts kframework/k#1639
This seems to have broken ExpandMacros for the OCAML backend.

Reverting that definitely breaks Kore execution. Did you update any bugs to attempt to notify @andreistefanescu  or I that you were doing this? The notice on the pull request doesn't seem to have been enough to generate a notification.

Yeah, I informed Andrei that I was doing this.

Ok, I suppose that's not unreasonable. This does interfere with my attempts to work on Kore as well.


The log directory is not accessible on few Android 11 based phones

The log directory which loadgen creates is not accessible on few Android 11 based phones. So, probably we should generate the results in some accessible location instead of using /sdcard/Android/data path.

Is this needed in 1.1 for submission verification?

Per @mcharleb - we don't need this for verification. Only shows up on Pixel, x86 / ARM emulation.


VersionTupleSyntax should be parsed as (up to) 3 integer literals

Issue Kind
Other
Source Code
@available(macOS 10.4p2.1, *)

Description
The given source should produce an error, rather than a valid parse with 10.4.p2 as the majorMinor and 1 as the patch on VersionTupleSyntax. Ideally VersionTupleSyntax would contain major, minor, and patch.

The structure of VersionTupleSyntax should be like:
    children: [
      Child(name: "Major",
            kind: .token(choices: [.token(tokenKind: "IntegerToken")])),
      Child(name: "PeriodForMinor",
            kind: .token(choices: [.token(tokenKind: "PeriodToken")]),
            isOptional: true),
      Child(name: "Minor",
            kind: .token(choices: [.token(tokenKind: "IntegerToken")]),
            isOptional: true),
      Child(name: "PeriodForPatch",
            kind: .token(choices: [.token(tokenKind: "PeriodToken")]),
            isOptional: true),
      Child(name: "Patch",
            kind: .token(choices: [.token(tokenKind: "IntegerToken")]),
            isOptional: true),
    ]

And the parser should reject integer literals with non-decimal characters e.g. 0x01

I imagine "1." or "1.2." should also be rejected, so it's more like (I, .I?, .I?) than (I, .?, I?, .?, I?), right?

I imagine "1." or "1.2." should also be rejected, so it's more like (I, .I?, .I?) than (I, .?, I?, .?, I?), right?

Right, or more like (I, (.I, (.I)?)?). The parser will reject those.
Unfortunately, we don't have a way to declare grouped optional without introducing a nominal syntax type, the declaration will be flatten.

Gotcha. Okay, works for me! Thanks for taking a look at this.


Runtime incompatible with backends other than IBM Quantum

Before Primitives and the Runtime one could just call backend.run()  and have things work regardless of whether that backend was real, a sim, local or remote IBM Quantum or otherwise.  However, with the Primitives (and runtime service in general) this is no longer the case.  This makes for lots of branching in code for doing things based on runtime or local / not IBM Quantum backends, and is necessarily required for things like using the local Aer simulator in CI.  Thus the introduction of Runtime makes for a more fractured ecosystem than previously existed.  It would be nice if the uniformity of the old `backend.run() style could be preserved with the introduction of Runtime.  If anything, at bare minimum, Qiskit's own components, e.g. Aer, BasicAer, etc., should be compatible with Runtime.  Without this it makes Runtime integration tricky and not really worth the effort at present.

Yes this is on the roadmap. This is why the base primitives were places in Qiskit. The idea is that estimation or sampling are well-defined tasks that any backend can implement. So all providers should implement the primitives. The IBM implementations rely on runtime, however one can mock them in software for any provider even if they do not have a runtime.

Closing, since we now have the base primitives in terra as well as BackendEstimator and BackendSampler that would work with backends that don't have their own primitives.


SRS only supports H.264 Baseline profile in WebRTC, not High profile

I have been exchanging SDP information between WebRTC and SRS and noticed that the encoding only supports the H.264 Baseline profile. It appears that SRS does not support the High profile for H.264. Can you confirm if this is the case?

在SrsRtcConnection::negotiate_publish_capability()中硬编码仅支持42e01f


Task :freerasp-react-native:minifyReleaseWithR8 FAILED

Describe the bug
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':app:checkReleaseAarMetadata'.
> Could not resolve all files for configuration ':app:releaseRuntimeClasspath'.
   > Failed to transform fingerprint-android-2.0.0.aar (com.github.fingerprintjs:fingerprint-android:2.0.0) to match attributes {artifactType=android-aar-metadata, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime}.
      > Execution failed for ExtractAarTransform: \.gradle\caches\modules-2\files-2.1\com.github.fingerprintjs\fingerprint-android\2.0.0\86b82e2d54f4304ac7cfc45324b1d2653358864\fingerprint-android-2.0.0.aar.
         > invalid entry CRC (expected 0x40ee5fd6 but got 0x2bc2b301)

To Reproduce

npx @react-native-community/cli init bug-repro--version 0.76.5
npm i freerasp-react-native
cd android
.\gradlew assembleRelease

Expected behavior
Working release build.
Please complete the following information:

Device: -
OS version: Windows 11
Version of freeRASP: Tested 3.9-3.13

Additional context

Hi @talaikis ,
Seems like the cached version of fingerprintjs does not match the one in the project.
Please try to delete the\.gradle\caches\modules-2\files-2.1\com.github.fingerprintjs\fingerprint-android\2.0.0\ folder and then build the project to download new file, or clear the whole gradle cache (on Windows by deleting the \Users\<YourUsername>\.gradle\caches folder).
Let us know if it helped.
Regards,
Tomas

After cache delete now even debug doesn't work with the similar error:
> Could not resolve all files for configuration ':app:devDebugRuntimeClasspath'.
   > Failed to transform fingerprint-android-2.0.0.aar (com.github.fingerprintjs:fingerprint-android:2.0.0) to match attributes {artifactType=android-aar-metadata, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime}.
      > Execution failed for JetifyTransform: $HOME\.gradle\caches\modules-2\files-2.1\com.github.fingerprintjs\fingerprint-android\2.0.0\86b82e2d54f4304ac7cfc45324b1d2653358864\fingerprint-android-2.0.0.aar.
         > Jetifier failed to transform: $HOME\.gradle\caches\modules-2\files-2.1\com.github.fingerprintjs\fingerprint-android\2.0.0\86b82e2d54f4304ac7cfc45324b1d2653358864\fingerprint-android-2.0.0.aar
           The error was: java.util.zip.ZipException - invalid entry size (expected 2071 but got 2094 bytes)
           To fix this issue, see https://issuetracker.google.com/issues/184622491

Error fades after explicitly adding higher fingerprint-android version: com.github.fingerprintjs:fingerprint-android:2.2.0,but release variant still doesn't build. I can change it in Android code, Tried to patching gradle, compile, etc. versions, but no idea how to find where fingerprint-android is placed. With latest React Native, fingerprint-android version 2.2.0 should be used.


Don't use goog.string.newlines.*

…instead simply use String.prototype.split with a regular expression.
I was also thinking of inlining the regular expression, so if everybody likes that better, I can update this PR.
Please review.

Looks good.  I think it is nice to create once and reuse the regex.  Please merge.

Thanks again, Tim.

I had to rebase. Will merge once everything is green again.


feat: implement AssetEntryDto JsonLd validator

What this PR changes/adds
Implement AssetEntryDto validator.
Why it does that
validation
Further notes

the validator has been implemented as a "rule" engine, and an instance can be built fluently, see AssetEntryDtoValidator for an example
some further work needs to be done, e.g. use "problem builder pattern" for violations

Linked Issue(s)
Closes #3142
Please be sure to take a look at the contributing guidelines and our etiquette for pull requests.

Codecov Report
Patch coverage: 80.48% and project coverage change: +0.08 :tada:

Comparison is base (8e05ee0) 65.15% compared to head (e07d692) 65.24%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3149      +/-   ##
==========================================
+ Coverage   65.15%   65.24%   +0.08%
==========================================
  Files         824      831       +7
  Lines       16627    16739     +112
  Branches      915      922       +7
==========================================
+ Hits        10834    10921      +87
- Misses       5424     5444      +20
- Partials      369      374       +5

Impacted Files
Coverage Δ

...nector/api/management/asset/AssetApiExtension.java
0.00% <0.00%> (ø)

...r/api/management/asset/model/AssetEntryNewDto.java
100.00% <ø> (ø)

...types/domain/edr/EndpointDataAddressConstants.java
100.00% <ø> (ø)

.../web/spi/exception/ValidationFailureException.java
0.00% <0.00%> (ø)

...nector/core/validator/JsonObjectValidatorImpl.java
33.33% <33.33%> (ø)

.../org/eclipse/edc/spi/types/domain/DataAddress.java
78.94% <50.00%> (ø)

...e/edc/validator/jsonobject/OptionalIdNotBlank.java
66.66% <66.66%> (ø)

...g/eclipse/edc/validator/jsonobject/JsonLdPath.java
80.00% <80.00%> (ø)

...ement/asset/validation/AssetEntryDtoValidator.java
82.35% <82.35%> (ø)

...ipse/edc/connector/core/CoreServicesExtension.java
94.44% <100.00%> (+0.15%)
:arrow_up:

... and 5 more

... and 3 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Suggestion: Remove JndiLookup.class from log4j-core-2.*.jar until migrating away from log4j-core

First, I'm not a Java dev.
Still, I want to give two remarks/observations/suggestions about the whole log4j mess:

A library that tries to parse strings it was only supposed to log, and even has code that allows initiating outbound network connections based on the results of that parsing, is broken by design and probably shouldn't be used at all.
An API that uses the same input vector to handle both potentially malicious input and to configure what the library actually does with the supplied potentially malicious input seems fundamentally unfit for purpose. IMO, this is comparable to patching together SQL query strings from unsanitized user input instead of just using prepared statements.
Until the migration away from this broken API is completed, it might be wise to preemptively, as a defense in depth measure, apply even to log4j versions >= 2.16.0 (explicitly including 2.17.0 and beyond) the mitigation method that upstream still recommends for users of log4j >= 2.0.0 < 2.16.0 who are unable to upgrade:zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

This simply deletes from the JAR file the class that actually performs the JNDI lookups. As far as I can tell, just like probably 99% of log4j users, you don't actually use log4j's JNDI "feature" at all, so the only "use case" for that class would actually be an attacker trying to execute malicious code after managing to find yet another way of circumventing upstream's patches to this fundamentally unsafe API.

Thanks for the recommendation the server is already running with log4j 2.17.0 with disabled JNDI

@hardfalcon Thanks for your suggestion and contributing to this porject. If you are happy with the answer above, please, close this issue. Of course, any further suggestions are welcome. Best wishes, DS

Corona-Warn-App Open Source Team


Update index.md

added the link to playground app from the app store

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.
[x] None of my changes are plagiarized from another source without proper attribution.
[x] My article does not contain shortened URLs or affiliate links.

If your pull request closes a GitHub issue, replace the XXXXX below with the issue number.
Closes #XXXXX

just added the playground app from the apple app store

Thank you for opening this pull request.
This is a standard message notifying you that we’ve reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
Reason: We do not accept PRs which only add links when there are already valid reference links for the article.  Instead of just adding a link, it would be great if you can add original content. Paraphrased content from another source should be referenced.
Thank you and happy coding.