Cannot review my new commit

Logs from AppVeyor:
[00:02:59.25]  [PowerShell]  .\Start-CarbonTest.ps1
The term 'ï»¿' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
at , C:\projects\carbon\Carbon\Carbon.psm1: line 2725
at , C:\projects\carbon\Carbon\Import-Carbon.ps1: line 64
at , C:\projects\carbon\Carbon\Import-Carbon.ps1: line 44
at , C:\projects\carbon\Start-CarbonTest.ps1: line 28
at , : line 82
+ CategoryInfo          : ObjectNotFound: (ï»¿:String) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : CommandNotFoundException
+ PSComputerName        : localhost
The module to process 'Carbon.psm1', listed in field 'ModuleToProcess/RootModule' of module manifest 'C:\projects\carbon\Carbon\Carbon.psd1' was not processed because no valid module was found in any module directory.
at , C:\projects\carbon\Carbon\Import-Carbon.ps1: line 64
at , C:\projects\carbon\Carbon\Import-Carbon.ps1: line 44
at , C:\projects\carbon\Start-CarbonTest.ps1: line 28
at , : line 82
+ CategoryInfo          : ResourceUnavailable: (Carbon:String) [Import-Module], PSInvalidOperationException
+ FullyQualifiedErrorId : Modules_ModuleFileNotFound,Microsoft.PowerShell.Commands.ImportModuleCommand
+ PSComputerName        : localhost
C:\projects\carbon\Start-CarbonTest.ps1 : The term 'Get-PowerShellModuleInstallPath' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
at , C:\projects\carbon\Start-CarbonTest.ps1: line 30
at , : line 82
+ CategoryInfo          : ObjectNotFound: (Get-PowerShellModuleInstallPath:String) [Start-CarbonTest.ps1], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException,Start-CarbonTest.ps1
at Write-WhiskeyInfo, C:\projects\carbon\PSModules\Whiskey\0.44.0\Whiskey.psm1: line 6731
at Write-WhiskeyError, C:\projects\carbon\PSModules\Whiskey\0.44.0\Whiskey.psm1: line 6591
at , : line 88
+ CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Write-WhiskeyInfo
+ PSComputerName        : localhost
VERBOSE: [00:02:59.91]  [PowerShell]  Exit Code  0
VERBOSE: [00:02:59.92]  [PowerShell]  $?         False
VERBOSE: [00:02:59.98]  [PowerShell]  FAILED in 00:00:02.4139742
VERBOSE: [00:02:59.98]  [PowerShell]
VERBOSE: [00:02:59.99]  [PowerShell]  FAILED in 00:00:03.9679738
VERBOSE: [00:02:59.99]  [PowerShell]
Uploading artifact appveyor_APPVYR-WIN_2020-01-05_21_01_33.trx (54,083 bytes)...100%
Uploading artifact dotnet.publish.Carbon.Test.csproj.log (951,410 bytes)...100%
Uploading artifact dotnet.test.Carbon.Test.csproj.log (157,583 bytes)...100%
Uploading artifact msbuild.Carbon.csproj.log (390,764 bytes)...100%
Uploading artifact msbuild.Carbon.Iis.csproj.log (388,170 bytes)...100%
Uploading artifact msbuild.Carbon.sln.log (3,637,192 bytes)...100%
Uploading artifact msbuild.Carbon.Xdt.csproj.log (380,528 bytes)...100%
Uploading artifact nunit3+uvlq5egf.2fj.xml (33,668 bytes)...100%
The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: C:\projects\carbon\whiskey.yml: Task "PowerShell": PowerShell script ".\Start-CarbonTest.ps1" threw a terminating exception.

Looks like there is a byte-order mark at the beginning of one of your new files. Make sure the files are encoded as UTF8 without BOM.


No Response

Hello :)
There seems to be a problem.
I installed the Homebridge plugin, entered the token and the Ip address. After restarting the Homebridge the vacuum cleaner also appeared in the Home App, but it says "no answer". I have activated all options.
Following is in the config:
"accessories": [         {             "name": "Dirty Harry",             "ip": "<IP_ADDRESS>",             "token": "c952a406c5340c61b669ff7b0b1931ce",             "pause": true,             "dock": true,             "accessory": "XiaomiRoborockVacuum"         }     ]
If you need some more information, you can ask me.
Many greetings from Hannover :)

Here the error output. It says the device is no vaccum cleaner. But it is!
It is the xiaowa e series.

MiioDevice Object:
MiioDevice {
model=roborock.vacuum.e2,
types=miio,
capabilities=
}

I entered into the if statement which checks if the device is a vaccum cleaner. This is the result.
I don't know why its not working...
[9/18/2019, 11:19:41 AM] [Dirty Harry] Initializing XiaomiRoborockVacuum accessory... [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | Connected to: <IP_ADDRESS> [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | Model: roborock.vacuum.e2 [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | State: undefined [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | FanSpeed: undefined [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | BatteryLevel: undefined [9/18/2019, 11:19:41 AM] [Dirty Harry] INF getSerialNumber | roborock.vacuum.e2 | Serial Number is undefined [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | Serialnumber: undefined [9/18/2019, 11:19:41 AM] [Dirty Harry] INF getFirmware | roborock.vacuum.e2 | Firmwareversion is 1.3.0_0686 [9/18/2019, 11:19:41 AM] [Dirty Harry] STA getDevice | Firmwareversion: 1.3.0_0686 [9/18/2019, 11:19:41 AM] [Dirty Harry] ERR getState | this.device.state | TypeError: this.device.state is not a function

new fw?

Firmware is updated. Or what do you mean?

Hey! I can see your model is roborock.vacuum.e2. It is not listed yet as a valid model. Similarly, it might not be updated in the miio package. @nicoh88 we might need to update both

Done. ✅ Version 0.6.4 published.
FanSpeed is speedmodes_gen3 for roborock.vacuum.e2. No idea if right. 👎
sudo su -
npm install -g homebridge-xiaomi-roborock-vacuum@latest --unsafe-perm

Thank you @nicoh88! I can see you also updated the miio module accordingly. @PatrickSTM, when testing, please, make sure the miio module is also updated to version "0.15.8-nicoh88"

Hey there!   I have a RoboRock S5 with firmware 3.3.9_001886 that I'm  trying to get to work, but i'm also seeing the errors:
INF ensureDevice | undefined | The socket was destroyed or not initialised, initialising the device
I have a dhcp reservation for the IP of the vac and I know that's working properly.  I have the Miio package installed.    Any thoughts as to where I might be going wrong?
Thanks!

Hi @monteroman, I have the exact same model and firmware and it's working just fine for me.
Q: Do you see the error 'ERR getDevice | Is not a vacuum cleaner!'? If so, I'm afraid either the token or the IP are wrong.

I did finally get it running 2 nights ago.  Yup, token was wrong.

On Dec 20, 2019, at 8:03 AM, Alejandro Fernández Haro<EMAIL_ADDRESS>wrote:

Hi @monteroman, I have the exact same model and firmware and it's working just fine for me.
Q: Do you see the error 'ERR getDevice | Is not a vacuum cleaner!'? If so, I'm afraid either the token or the IP are wrong.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Great to hear that! I'll close this issue then if you don't mind.

I don’t mind at all.  Thank you for the follow up.

On Dec 20, 2019, at 1:42 PM, Alejandro Fernández Haro<EMAIL_ADDRESS>wrote:

Great to hear that! I'll close this issue then if you don't mind.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.


Use compactMap(_:)

Environment

DIKit 0.3.2
Xcode 9.3.2

Swift 4.1.2

Current behavior
Xcode outputs warnings that flatMap' is deprecated since Swift 4.1.
Using to compactMap(_:) for the case where closure returns an optional value.

👍 👍


What is the purpose of normalizeFlags?

I read the code but my understanding of it doesn't match what happens when I remove that function entirely.
It looks like the only things it does in practice is to disallow using the long form and the short form alias of the same flag in a same call.
Is there a reason why that should be disallowed? Or is that a necessity due to some constraint I am not seeing?

@fiatjaf Thats one of the reasons. The other reason is that the flag aliases values are duplicated into the set for retrieval but set.Value function.

@fiatjaf looking at it further it appears that the function is redudant. It is a holdover from an early v2 codebase. I have removed in v3.

Thank you, this is good news!


Parse Error

I'm parsing JSON sent to a socketing server like so;
        try
 	{
		nlohmann::json json;
		json.parse(request);

		if (json[0].get<std::string>().find("z") != std::string::npos && json[0].get<std::string>().find("L") != std::string::npos &&
			json[0].get<std::string>().find("|") != std::string::npos && json[0].get<std::string>().find("jM") != std::string::npos)
			return true;
	}
	catch (nlohmann::detail::parse_error e)
	{
		c_logger::error(e.what());
		return false;
	}

This is the output from the server after receiving the request;
[~] = {"auth":"p4AzO|L1jMf=","request":"update_ips","ips":{"ip1":"<IP_ADDRESS>","ip2":"122.311.33.87","ip3":"<IP_ADDRESS>3",},"ip_amount":3}
[~] [error] = [json.exception.parse_error.101] parse error at 120: syntax error - unexpected '}'; expected string literal

I really don't see what the issue is, it's probably something really stupid. Help would be appreciated.

How does the JSON test request looks like? If it is the string in the first line of the output, then the comma after "<IP_ADDRESS>3" is wrong. This also coincides with column 120.

My bad, should have removed that last comma. However, I'm now getting;

JSON_THROW(type_error::create(302, "type must be string, but is " + std::string(j.type_name())));

While in debugging I was unable to see the property type_name, m_type is equal to null. This occurs on this check right here;
if (json["auth"].get<std::string>().find("z") != std::string::npos && json["auth"].get<std::string>().find("L") != std::string::npos &&
			json["auth"].get<std::string>().find("|") != std::string::npos && json["auth"].get<std::string>().find("jM") != std::string::npos)
			return true;

Never mind, the issue was creating a json object then going json.parse. I presumed this would automatically update the object but it doesn't (I believe), so I had to assign the output of the parse to a variable.

Do you need further assistance.

I'm good, thanks.


Modbus unexpected error flow (IDFGH-3829)

Environment

Development Kit:      NA
Kit version NA
Module or chip used:  ESP32-WROOM-32D
IDF version (run git describe --tags to find it): v4.1-rc
Build System:         CMake
Compiler version xtensa-esp32-elf-gcc (crosstool-NG esp-2020r2) 8.2.0
Operating System:     Windows
(Windows only) environment type: MSYS2 mingw32
Using an IDE?: Yes (eclipse)
Power Supply:         NA

Problem Description
After upgrade to tag v4.1-rc, Modbus communication sporadically encounters errors that modifies SW flow.
Although this is not confirmed yet, this new error seems to cause desynchronization among exchanged Modbus frames.
Indeed, we've encountered multiple "resource release failure" or "Take resource failure" messages that causes SW fails in our application.
So we've tried to investigate by adding more log, and we've found a weird behavior on error management, please read below.
In function eMBMasterPoll, checking EV_MASTER_EXECUTE: if eException is raised, xMBMasterPortEventPost modifies code execution strangely, cf. log sample below and instrumented function eMBMasterPoll in attachement.
Expected Behavior
Expected log in case of exception would be the following, based on instrumented file (this "good" error management behavior has been observed somewhere else during our logs):
MB_PORT_COMMON: ERR 3
MB_PORT_COMMON: ERR 4
MB_PORT_COMMON: error type = 2
MB_PORT_COMMON: error step 1
MB_PORT_COMMON: error step 2

Actual Behavior
Actual log in case of exception is the following, based on instrumented file:
(13164) MB_PORT_COMMON: ERR 3
(13186) MB_PORT_COMMON: error type = 1 // Error type gets modified here: otherwise, we should have had type 2
(13198) MB_PORT_COMMON: error step 1
(13206) MB_PORT_COMMON: error step 2
(13385) MB_PORT_COMMON: eMBMasterPoll: Unprocessed event 4

ERR 4 gets never displayed at all, and unprocessed event makes me think that we jump somewhere back to the function start when doing xMBMasterPortEventPost( EV_MASTER_ERROR_PROCESS ), without displaying ERR 4 and clearing event 4.
After checking the code, I would say eMBMasterPoll gets interrupted by xMBMasterRTUTimerExpired between display of ERR3 and 4, and that eMBMasterCurErrorType gets modified to 1 by vMBMasterSetErrorType(EV_ERROR_RECEIVE_DATA) in xMBMasterRTUTimerExpired.
I don't know whether it is expected or not, but I'm expecting maybe a real time scheduling issue...
You will find our SDKconfig attached. Especially, do you have a requirement on FreeRTOS timer daemon task priority to handle Modbus event groups ? So far it has the lowest priority in our project.
Steps to reproduce
Our setup is the following:

board 1 (master) sends periodic requests to board 2 (slave)
board 1 and board 2 are under OTA process, and can reboot asynchronously (I mean in the middle of a Modbus request/response for example).

With the previous version, we did not have any issue. But now communication seems to be messed up after multiple OTA cycles. The problem does not appear systematically though? Although, we can't log the Modbus exchanged frames.
So far, we don't have any ideas on how to reproduce this easily. But we always end up there after roughly 15/20 OTAs...
What I want to point out is the error message: we've never have it before, that's why I suspect something new that could desynchronize.
Thank you for your help.
// If possible, attach a picture of your setup/wiring here.
Code to reproduce this issue
NA
Debug Logs
Cf. Actual Behavior
Other items if possible
SDKconfig attached as JPG otherwise GitHub rejects it...

eMBMasterPoll.txt

Thanks for the detailed report and letting us know, we would look into.

@simon-thiebaut,
I am sorry to hear about these issues in v4.0-rc. It is true there are several issues exist in this release and fixes were not back ported correctly. The most important things are: Wi-Fi coexist, NVS read/write, UART fifo read issues. I am working on it and already ported fixes of UART driver as well as Modbus and example fixes. Currently, my project is able to pass most of tests and I will be able to provide fixes for you as soon as possible. Preliminary results can be ready for test at the end of this week or start of next week.

Hello @alisitsyn ,
I'm working with @simon-thiebaut we would like to know where your progress is on these issues?
Moreover, you talking about on the tag v4.0-rc, but we are on the tag v4.1-rc, it's the same fixes?

Hello @Zodiac-Onnillon,
I apologize for the delays. Have some unexpected issues. The fixes will be ported to v4.1 as well.
I had hard time to reproduce your issues and will continue with this as soon as possible.

Hello @alisitsyn,
Are you about to fix this issue?
Do you know how long you need to finish and merge the correction on the mainline?
Please keep me posted.

Hello @Zodiac-Onnillon,
Could you answer my questions below:

Do you have tasks with a priority higher than CONFIG_FMB_SERIAL_TASK_PRIO and what is the priority compare to Modbus tasks priority?
Do you have NVS R/W tasks that have a priority higher than Modbus tasks?

The priority of Modbus tasks is important for v4.1-rc  and should be configured to be higher than other tasks priority. The Modbus stack uses polling mode to read/send data instead of custom interrupts and other tasks can delay the processing of the events by the Modbus FSM. Then the T35 timer is triggered that causes the timer expired function to send EV_MASTER_FRAME_RECEIVED, but the input buffer is not processed correctly due to processing delays. This behavior depends on the activation timing of the higher priority tasks and the receive state machine can go to STATE_M_RX_ERROR and modify the set the error code to EV_ERROR_RECEIVE_DATA. The above can cause the FSM may not be released from the previous transactions correctly.
In later releases, the T35 feature is modified to monitor the timeout using UART timeout feature instead.
There are some other reasons for this behavior.
My proposals:

Increase the priority of CONFIG_FMB_SERIAL_TASK_PRIO in your application to be higher than the highest priority of your other tasks.
I am going to send you the patch for v4.1-rc to solve known issues up to Friday this week.

Hello @alisitsyn,
Thank you for your reply,
1. The task CONFIG_FMB_SERIAL_TASK_PRIO is configured with priority 10 and no application task has a higher priority. Our Modbus application task has a priority configured at 5.

2. Yes, we have NVS R/W used on the application tasks. All the application tasks not exceed priority 7. So we had some tasks set as the same priority as Modbus task and a few higher than Modbus like the Wifi task.

Therefore we waiting for your patch then we will check and change all the priority for the Modbus task like your proposal.
Then we can pass some test and inform you about the correction.

Hello @Zodiac-Onnillon,
Please apply the patch below to v4.1-rc.
patch_drv_modbus_v41_rc_1.zip
Please perform your tests and let me know the result and send me the logs. Thanks.

Hello @Zodiac-Onnillon,
If you have the test results for the patch could you share them here?
On my side the Modbus with the patch applied was able to work when tasks with even significantly higher priority than Modbus tasks exist as well as with NVS access.
Thanks.

Dear @Zodiac-Onnillon,
Please let me know the results of your testing with the applied patch.
Thank you.

Hi @alisitsyn ,
Sorry for the delay, we were going on production on a project.
So we've finally tested your patch, and we still have issues.
We need to do more tests, but please find below some information:

when our product is in normal mode, issues do not seem to happen
when the device is in a special mode, we encounter weird behavior (we can't tell yet for sure that are the source of the problem we have, but we wanted to share that with you).

This special mode is an over the air FW update of the product. We are performing stress loops of OTA to validate our FW, and we encounter issues with both the tag v4.1-rc and your patch. However we do not have such issues when we are on our commit (that is based on fork of Espressif official repo, somewhere before v4.1-rc).
What happens is that during OTA, we perform an erase of the Espressif partition that will receive the new FW. This erasing is made in SDK API esp_ota_begin, and is blocking the Espressif for the duration of the erase.
However, we've observed that some Modbus frames are still being issued during this operation (though most of the time there is no Modbus activity at all during it). It is not the case on our previous "custom" version.
Also, these Modbus requests are weird: indeed, they are split in 2 or 3 packets, separated by a period between roughly 100 and 200 ms, it varies.
Could this cause a Modbus stack desynchro ?
We've taken a logic analyzer (Saleae) capture of this issue, however the capture is around 130 MB, I don't know how to share it with you...
I've attached a picture of the issue as a starting point. In the orange box, 2 frames are sent although they shall not. Requests are on the bottom graph, and responses on the top one. The first request is split in 2, and the 2nd in 3. And obviously there is no response as the slave do not understand these split frames.

Please let us know.
On our side, we'll force loops of blocking flash erase, so that hopefully the problem is reproduced more easily.
But in the meantime, any advice would be appreciated.
Thank you for your feedback.
Best regards,

Hi @Zodiac-Onnillon,
Thank you for the update. I did not a complete detailed investigation of the behavior during FW update yet and below I will try to share some thoughts related to showed behavior.
The processing of incoming Modbus frame is performed in the functions port/portserial_m.c::usMBMasterPortSerialRxPoll(), xMBMasterPortSerialTxPoll(). In this release, these functions are used to read/write the incoming data byte by byte from/to UART FIFO buffer. The current approach was selected intentionally to use existing freemodbus architecture for RTU, ASCII, and allow to define custom buffer size for Modbus stack.Unfortunately, this does not work reliably when the processing task is suspended periodically by higher priority tasks.During transmission, it can make gaps when feeding the UART FIFO in xMBMasterPortSerialTxPoll() function. The same behavior applies to usMBMasterPortSerialRxPoll() and when the FMB_TIMER_PORT_ENABLED is disabled it helps to process incoming frames correctly but increases frame processing time.
The Flash write/erase during OTA update also causes IRQ processing delays because it disables CPU cache and the FMB_TIMER_ISR_IN_IRAM option allows to mitigate the delays. It is possible the next portion of data in the ring buffer be transferred into FIFO during OTA update that explains the packets splitting.
In the previous release, the read of the full FIFO is performed as one function call using a temporary buffer to keep data then the poll function was performing processing of the buffer byte by byte. This explains why the previous version of Modbus was working for you better.
The above could make Modbus FSM be unreliable and cause desynchronization of the stack due to fragmented packets. The stack was not designed to be functional in such a case. What I can propose is to destroy Modbus before the start of OTA update and start it again after reset. This is a really unusual case from my point of view.
Do you really need the Modbus to be functional during OTA update?

Hello @alisitsyn ,
Again sorry for delay.
Finally we have decided to not upgrade to this tag at this stage of the project, due to the uncertainty we sill have around Modbus. So we have kept the previous version for THIS project
BUT: we're starting a new project based on the previous one, and as we have a bit more time we'd like to push the investigations to decide whether or not migrating.
Just to give you the info: we wanted to upgrade the SDK because we had a Wifi memory leak, that could only be fixed by upgrading the SDK (based on what we've been told in another tick).
But by doing this, we a have to take the full SDK, including this Modbus upgrade (though we were pretty much satisfied with the previous version).
Also, to clarify our projects:

the system is based on 2 boards, communicating over Modbus (Espressif board being the master)
the firmwares of the 2 boards are downloaded through Wifi
when time comes to update the slave board, the Espressif sends the slave board FW chunkwise over Modbus (write multiple registers, 64 bytes/32 registers; so yes we need Modbus during OTA...)
also, one more requirement is that the OTA is transparent to the user, as one board is an HMI with displayed data read from the 2nd board. So again, this means that during OTA, Modbus comm shall be up and running.

So basically during OTA, we have :

sequences of wifi download, partition write, partition read, and "big" transfers over Modbus using multiple registers
in parallel, our Modbus table application keeps being updated periodically by sending Modbus requests

As far as I understand from our discussion, the new Modbus implementation is not compliant with these requirements, so here are my questions:

do you think the new Modbus stack could be compliant to this requirements in a near future ? Or absolutely not ?
if we want to stick to the previous implementation of Modbus stack, can we "simply" keep the whole SDK corresponding to the v4.1-rc, but replacing the folder freemodbus by the previous version that we use and that we have "qualified" on our previous project ? Shall we expect any side effects ?

Thank you for your feedback.
Best regards,

Hi @alisitsyn ,
May I update my previous comment: actually I think I've pointed out the issue...
Some of our Modbus requests can take longer to be processed. I've checked the timings: we can take 337 ms before replying to a Modbus request.
But the timeout is set to 400 ms on Espressif.
I think that the issue comes from the fact that the first request gets a timeout, but the reply is always sent, even after time out. I think we are borderline on timings, that's why we do not have the problem all the time. However, I can reproduce it almost always bby adding a delay before replying to Modbus requests on the slave side.
Question is: what is supposed to happen if bytes are received AFTER request is considered as timeout by the stack ? Is it safely managed ?
From our observations, it seems that we are desynchronized, and never be good again.
Also, we have the following error logs:
E (23403) MB_PORT_COMMON: xMBMasterRunResTake(159): xMBMasterRunResTake:Take resource failure.
E (23405) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x103) (ESP_ERR_INVALID_STATE).
E (23418) HMI_MB: hmi_modbus_read_value CID = 7 error=(0x103) (ESP_ERR_INVALID_STATE)
E (23426) MODBUS: Read error on CID 7
E (23427) MB_PORT_COMMON: vMBMasterRunResRelease(172): vMBMasterRunResRelease: resource release failure.
E (24456) MB_PORT_COMMON: 0
E (24457) MB_PORT_COMMON: xMBMasterRunResTake(159): xMBMasterRunResTake:Take resource failure.
E (24459) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x103) (ESP_ERR_INVALID_STATE).
E (24472) HMI_MB: hmi_modbus_read_value CID = 8 error=(0x103) (ESP_ERR_INVALID_STATE)
E (24480) MODBUS: Read error on CID 8
E (24481) MB_PORT_COMMON: vMBMasterRunResRelease(172): vMBMasterRunResRelease: resource release failure.
I (24730) SHADOW_Z: Shadow buffer: {"state":{"reported":{"equipment":{"hp_0":{"cl":0}}}}}
E (25516) MB_PORT_COMMON: xMBMasterRunResTake(159): xMBMasterRunResTake:Take resource failure.
E (25516) MB_PORT_COMMON: 0
E (25517) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x103) (ESP_ERR_INVALID_STATE).
E (25531) HMI_MB: hmi_modbus_read_value CID = 9 error=(0x103) (ESP_ERR_INVALID_STATE)
E (25540) MODBUS: Read error on CID 9
E (25540) MB_PORT_COMMON: vMBMasterRunResRelease(172): vMBMasterRunResRelease: resource release failure.
I (25995) SHADOW_Z: Shadow buffer: {"state":{"reported":{"equipment":{"hp_0":{"cl":1}}}}}
E (26569) MB_PORT_COMMON: xMBMasterRunResTake(159): xMBMasterRunResTake:Take resource failure.
E (26570) MB_PORT_COMMON: 0
E (26570) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x103) (ESP_ERR_INVALID_STATE).
E (26584) HMI_MB: hmi_modbus_read_value CID = 11 error=(0x103) (ESP_ERR_INVALID_STATE)
E (26593) MODBUS: Read error on CID 11
E (26593) MB_PORT_COMMON: vMBMasterRunResRelease(172): vMBMasterRunResRelease: resource release failure.
E (27630) MB_PORT_COMMON: 0
E (27631) MB_PORT_COMMON: xMBMasterRunResTake(159): xMBMasterRunResTake:Take resource failure.
E (27633) MB_CONTROLLER_MASTER: mbc_master_get_parameter(111): SERIAL master get parameter failure error=(0x103) (ESP_ERR_INVALID_STATE).
E (27646) HMI_MB: hmi_modbus_read_value CID = 46 error=(0x103) (ESP_ERR_INVALID_STATE)
E (27653) MB_PORT_COMMON: vMBMasterRunResRelease(172): vMBMasterRunResRelease: resource release failure.

Hi @simon-thiebaut,
Thank you for your update. Sorry for the delays with answer. I am pretty busy with other things after my vacation and need more time to analyse the results. This issue the next in my queue and I will respond ASAP.
Hope for understanding. Thank you.

Hi @alisitsyn ,
No problem, I understand, don't worry.
Just a new info: I think I understand why the previous stack was "more stable" for us... actually I've found an old patch from us on the stack that workarounds an unknown problem we faced in the past. I don't think this was notified to Espressif at that time, so please find the diff below:

I will apply it on the new stack to see if we're still getting stuck, but I'm pretty sure we'll not be.
So I think the real questions in all my comments is the one from the previous comment: "what is supposed to happen if bytes are received AFTER request is considered as timeout by the stack ? Is it safely managed ?" (cf. log errors we have).
Thank you.

Hi @simon-thiebaut,
In normal processing the release of semaphore should be performed in one place - in the modbus event handler: https://github.com/espressif/esp-idf/blob/357a2776032299b8bc4044900a8f1d6950d7ce89/components/freemodbus/modbus/mb_m.c#L454
In cases when the event handler and serial processing task are often suspended by other high priority tasks the release can be delayed. In this case the release is delayed but response timeout received and the stack starts new transaction This patch can be useful in this case only and can prevent blocking of stack when incorrect packet received. But blocking is fixed in later modbus updates, in worst case the release of resource must called after several transactions. Your patch does not allow to avoid errors when timeout expired but packet received and the same way it will release sema after 5 continuous failed transactions in this case . It could be just part of solution and not complete. From my point of view there is other thing that explains why the v4.0 release was working better for you:
https://github.com/espressif/esp-idf/blob/v4.0/components/freemodbus/port/portserial_m.c#L109
In this code we read the complete message just once into temporary buffer using blocking function. The packet processing of the incoming buffer faster without blocking in this case. The same is for xMBMasterPortSerialTxPoll().
I think you need to port this part from your previous code. In the v4.1 I updated this part to do blocking call to read each byte from FIFO and this is required to support custom modbus buffer size. This will allow to decrease polling time significantly in case when your OTA task and other high priority tasks do actively their work. I think you need to port just this serial code from v4.0.

Thank you for your analysis @alisitsyn .
So to sum up:

semaphore management:

I should remove our patch with the 5 retries
I should replace vMBMasterPortSerialRxPoll and xMBMasterPortSerialTxPoll functions with the one in provided in your link.

task desynchronization risk:

so we need to absolutely respect timeouts value, even if we need to increase it, as the stack might not support to receive too late responses.

Is that correct ?
I will do the modifications and trigger tests probably on monday now. I'll keep you updated.
Thank you again, and have a nice week-end.

@simon-thiebaut,

I should remove our patch with the 5 retries

You could verify this but from my point of view it useless and will not solve the issue but can have side effects;

I should replace and adapt vMBMasterPortSerialRxPoll and xMBMasterPortSerialTxPoll functions with the one in provided in your link.

Yes, I think this might help in your particular case of using Modbus with OTA update but has to be checked carfully.

so we need to absolutely respect timeouts value, even if we need to increase it, as the stack might not support to receive too late responses.

When the response timeout is expired the master starts the next transaction. Once it is sent the master does not have any way to determine if the received frame in the fuffer is response for expired transaction or for the new one (as it is for Modbus TCP with MBAP TID field). I think what master can do in this case is to flush received buffer right before sending a new request:
void vMBMasterPortSerialEnable(BOOL bRxEnable, BOOL bTxEnable)
{
    // This function can be called from xMBRTUTransmitFSM() of different task
    if (bTxEnable) {
        bTxStateEnabled = TRUE;
        uart_flush_input(ucUartNumber); // <<< flush input buffer with expired response before send the new master transaction
    } else {
        bTxStateEnabled = FALSE;
    }
    if (bRxEnable) {
        bRxStateEnabled = TRUE;
        vMBMasterRxSemaRelease();
        vTaskResume(xMbTaskHandle); // Resume receiver task
    } else {
        vTaskSuspend(xMbTaskHandle); // Block receiver task
        bRxStateEnabled = FALSE;
    }
}

Master also is able to drop fragmented frames. If the response is received but during processing the additional frame is received it will process just first frame and drop second one:
// UART receive event task
static void vUartTask(void* pvParameters)
{
    uart_event_t xEvent;
    USHORT usResult = 0;
    for(;;) {
        if (xQueueReceive(xMbUartQueue, (void*)&xEvent, portMAX_DELAY) == pdTRUE) {
            ESP_LOGD(TAG, "MB_uart[%d] event:", ucUartNumber);
            switch(xEvent.type) {
                //Event of UART receiving data
                case UART_DATA:
                    ESP_LOGD(TAG,"Data event, len: %d.", xEvent.size);
                    // This flag set in the event means that no more
                    // data received during configured timeout and UART TOUT feature is triggered
                    if (xEvent.timeout_flag) {
                        // Workaround: The UART driver can cut mb frame
                        // (generate timeouts for incomplete frame) when wifi is active
                        if (xEvent.size <= MB_SER_PDU_SIZE_MIN) {
                            break;
                        }
                        // Response is received but previous packet processing is pending
                        // Do not wait completion of processing and just discard received data
                        // as incorrect (fragmentation of response).
                        if (vMBMasterRxSemaIsBusy()) {
                            uart_flush_input(ucUartNumber);
                            break;
                        }
                        // Get buffered data length
                        ESP_ERROR_CHECK(uart_get_buffered_data_len(ucUartNumber, &xEvent.size));
                        // Read received data and send it to modbus stack
                        usResult = usMBMasterPortSerialRxPoll(xEvent.size);
                        ESP_LOGD(TAG,"Timeout occurred, processed: %d bytes", usResult);
                        // Block receiver task until data is not processed
                        vTaskSuspend(NULL);
                    }
                    break;

Hi @simon-thiebaut,
Sorry for the delays.
The reason for the errors is that the xMBMasterPortSerialTxPoll() should be reverted to previous version and both polling functions TX/RX should be reverted in your slave code as well.
I try to check the approach with reverted poll functions as well as other idea. Unfortunately I don't have your code to check. I will try other way to check.

Hello @alisitsyn
No problem.
Note for your investigations, thank you.
Please note: on our slave, we are not using an Espressif chip, but we have integrated FreeModbus as a standalone librarie (quite old version, taken directly from https://www.embedded-solutions.at/en/freemodbus/). It has been kept unmodified for months now).
However for our Espressif master: I'd like to share new findings regarding my previous comment.
As I said, with the partially patched polling functions (RX patched, but not TX), I had after some request timeouts a misalignment between requests and responses.
I've added more log, and I've manage to point out where the shift occurs (cf. attached "Timeout shift issue.txt"). For a request, the log sequence is the following:
HMI_MB: CID R1 XXX => XXX is CID value; request start at our application level
MB_MASTER_SERIAL: uart rx break. => UART task event (please note I have not enabled all logs in this task, just unexpected/failure cases)
MB_PORT_COMMON: RX 0 => FreeModbus RX FSM has processed first byte of response
MB_PORT_COMMON: RX E => FreeModbus RX FSM has ended processing of full response frame
MB_PORT_COMMON: eMBMasterPoll: Packet data received successfully (0).
POLL RCV buffer: . => response frame data bytes
HMI_MB: CID R2 XXX => XXX is CID value; request end at our application level
What we can see at t = 68423 is that CID 72 is requested by our app. Then OTA stuff occurs, probably causing then the subsequent timeout in the log at t = 68578. Due to this error, our app considers the request ended and failed at t = 68588.
However, we can see that we then receive the response frame, before our app performs a new request to the Modbus stack (at t = 68966). This causes the mutex give failure at t = 69022, as it has already been released when timeout occured before.
Finally, later we can see our app requests CID 73 at t = 69325. And request is considered over right after, before anything gets log from Modbus stack, at t = 69336.
Following that, all requests and responses are misaligned: request N receives response N-1.
So it seems that the Modbus stack does not clear/ignores properly received bytes outside request context (as we mentioned in an earlier post).
I think this was probably hidden by our 5 retries fix in previous version. However following this log I've tried to patch the library to recover from this shift. Things seems better now, but I need to do more tests. You will find attached the 2 Git patches I have applied for my tests (sorry I had to rename .patch extension to .log for attaching files):

0001-bugfix-Espressif-workaround-proposal-for-Modbus-late.patch.log => RX/TX poll functions rework for latency improvements
0002-bugfix-workaround-to-clear-Modbus-stack-misalignment.patch.log => Modbus stack resources/variables clearing force between each requests

Very probably my patch does not cover all Modbus use cases and is not the most optimized, but as it gives results I will test it "as it is". Please let me know if you see better ways to handle that, and also if I must be aware of possible dangerous side effects of it.
I'll keep you updated of my stress test results, but they are quite long (OTA loops). So if good, it can take 4
0001-bugfix-Espressif-workaround-proposal-for-Modbus-late.patch.log
/5 days. If not, it will be shorter.
Thank you for your feedback on this.
Best regards,
0001-bugfix-Espressif-workaround-proposal-for-Modbus-late.patch.log
0002-bugfix-workaround-to-clear-Modbus-stack-misalignment.patch.log
Timeout shift issue.txt

Hello  @simon-thiebaut,
Thank you for extended information and patches. The expired response can be received at any time and really can cause an issue.
I verified your logs and checked the patch. It works good with my environment and tests and is able to repair FSM from failure. The same approach should be applied for the mb_ascii_m.c. For now I think it does its work good but still have some stress tests to check.

Hello @simon-thiebaut
I just tried the fix that you committed to BadrBouaddi repository and it fixes the issue that I've been battling with for a week.
Could you create a PR on esp-idf repository so that everyone can enjoy the fix?
Thanks

Hello @simon-thiebaut,
Do you have any new results of the testing? Could you create the PR for misalignment fix to merge it to master and backport to other branches?

Hello @DaniusKalv and @alisitsyn ,
Sorry for delay, last week was a delivery week...
So for the test results:

we made 200 OTA loops, that causes the exchange of roughly 567000 chunks of 64 data bytes over Modbus with blocking delay close to the Modbus timeout => device is no more stuck
normal long term running: we have currently 14 devices running for more than a week without troubles. Still to monitor over time, but encouraging.

FYI, before OTA loops were failing after ~15 loops, and devices stopped to run after ~3 days.
OK I will do the PR, but probably tomorrow or on wednesday.
Thank you.
Best regards,

Hi @DaniusKalv and @alisitsyn ,
Ok so actually I've not created the PR yet, because we still have an issue regarding the 2nd point:
"normal long term running: we have currently 14 devices running for more than a week without troubles. Still to monitor over time, but encouraging."
Devices were not monitored properly. After a new diagnostic, it appears that we have roughly 1 communication loss per day with the new stack. It is not the case with the previous stack (we compare also devices with this old stack).
After analysis, it appears there is one scenario in the new stack where the client is not notified of an error, and can be stuck in the request finish waiting API - considered as a "communication freeze".
I've patched it last week, then we've restarted the tests. We have a meeting this afternoon to check the test results.
If they are OK, I will add this patch before creating the PR.
Sorry again for the delay, I'll keep you updated.
Thank you,
Best regards,

@simon-thiebaut Was a PR ever raised for your fixes?

@atanisoft thanks for digging this out, it was completely out of my mind, too many things to handle this year, I apologize for such a delay.
So to answer your question, no I haven't created a PR on that. Due to our project timeline we decided to keep our "patched but qualified" ESP SDK to go to production.
Anyway I need to take time to gather the last statuses on these points before creating the PR. Especially I need to go back in history to check if we did not add more patches.
I'm creating a ticket right now in our system to not forget. But unfortunately I can't tell you when I'll be able to handle that, we are very busy until march 22... I'll keep you informed ASAP.
Thanks for your understanding.

It looks to me that the issue is still present.
I am getting the following errors after some time of Modbus reading with the master.
I (30925454) count_task: RAM left 128216
E (30925994) MB_PORT_COMMON: xMBMasterRunResTake(183): Take resource failure.
E (30925994) MB_CONTROLLER_MASTER: mbc_master_get_parameter(85): Master get parameter failure, error=(0x103) (ESP_ERR_INVALID_STATE).
E (30925994) MASTER_TEST: Characteristic #0 (Data_channel_0) read fail, err = 0x103 (ESP_ERR_INVALID_STATE).

This issue have been fixed in the esp-modbus component which can be used from esp-idf v4.1. In order to use the new component please follow the requirements below:

Include the line below to the root CMakeLists.txt file of your  project folder:

set(EXCLUDE_COMPONENTS freemodbus)

The main component folder of the project shall include the packet manager manifest file as in example.

The slave response time CONFIG_FMB_MASTER_TIMEOUT_MS_RESPOND shall be configured to be higher than the maximum slave response time for slaves in your network.

The component freemodbus provided in old revisions of esp-idf will not be updated. Please use the  esp-modbus component.
This ticket is going to be closed. Feel free to reopen new issue if you have issues.
Thank you.


[FEATURE] references/links to external resources to support download & using the repository

Description
Reference to external links to resources, to support the new user to download and use the repository as the data source is more than 500MB and Github has limitations for the large files.

[ ] Fetching the data source should be clearly mentioned.

Hi @JiyaGupta-cs  I would like to work on this issue for GSSOC'24 and all other issues as well. I am attaching my resume for reference of my work. https://drive.google.com/file/d/1HgwfbdcNRL-e9LTkqVRpu3XAbmMK8faf/view?usp=sharing . My discord id:- 210906_sakshamagarwal

Dont start right now, start after may 10

You can start working on it i have added the labels. @Sakshamag21

Hello @sanjay-kv . I would like to work on this issue for GSSOC'24.
My discord I'd : "namecontributor_36700_96512"
I want to explain my way of approach for this issue :

To resolve the issue of hosting large data files on GitHub, I can consider using external services those are designed for handling large files.(for this I have to make changes and updates in README file)
Hosting data on external storages.
Providing clear instructions and explaining how to use them.
4)Offering support if any issues encountered.
keeping files updated.

Hoping for the positive consideration.
regards,
Contributor | Phanisai.

Issue will be assigned to Only 1 person ...FCFS basis.
Others get a chance if the issue gets stale & the assignee is inactive for 5+ days
Also if you would like to work on more issue create a new issue and I will create label and assign you.

Is this issue still open?
I would like to work on it , if the issue hasn't been resolved yet
My discord Id: Mansi_1004


Glare effect removal

Hi. My question is simple. Does zxing has mechanism to remove glare effect from barcodes?

The answer is: it depends on the type of glare and the type of barcode. Do you have a sample image?

If you don't have any more input on this matter or you feel like your question is answered, please close the issue.


docs: new integration guides

[x] I have followed the Your First Code Contribution section of the Contributing guide

Summary
Integration guides for all current React related frameworks/technologies that flowbite-react can be installed into.
Changes

[x] replace @mapbox/rehype-prism in favor of rehype-prism-plus for line highlighting features (see screenshots below)
[x] create new "integration guides" section
[x] create new integration guides for the following:

[x] Next.js
[x] Vite
[x] Remix
[x] Astro
[x] Gatsby
[x] Laravel
[x] Parcel
[x] Create React App
[x] RedwoodJS

[x] explicit dark mode support integration for the frameworks that do SSR

Result
New "Integration guides" section

New code highlight line

I don't have time to check the Astro, CRA, Laravel, RedwoodJS instructions but your instructions for the rest, which I have used a few times myself, look great.

Every single guide was tested by hand, from scratch, so I think we're covered there :D


fix: rpc control messages 0.4.x

Fixes #117 for gossipsub 0.4.x line

Codecov Report

Merging #133 into 0.4.x will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##            0.4.x     #133   +/-   ##
=======================================
  Coverage   80.00%   80.00%
=======================================
  Files           1        1
  Lines          10       10
=======================================
  Hits            8        8
  Misses          2        2

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 a590997...bab97c5. Read the comment docs.


Remove ability to start pulling while inside a container

About the PR
Prevents an exploit by which a player can cause pullable objects to become teleported to a known and configurable location by simply pulling them after performing a setup. This is done by removing the ability to initiate a pull while the player is inside of a container, which I couldn't really think of a legitimate purpose for.
Why / Balance
Remove exploits add fun
Media

[X] This PR does not require an ingame showcase

Changelog
no cl no exploits

Added the forgotten check that would have been obvious to someone awake and going back to dev environment to see what bugs I would have introduced


Add GOGH_USE_NEW_THEME flag for immediate theme switching

This commit builds upon #443 (it must be merged first)
Add GOGH_USE_NEW_THEME to directly use the new theme in the terminal (if supported by terminal)
Actual effect will differ between terminals, for example in xfce4-terminal when using the flag the theme is immediately changed.
Currently only xfce4-terminal is supported. Tilix should theoretically also be supported but the current implementation of applying it as the current theme didn't seem to work for me.
Nevertheless this new flag allows future terminals to also switch directly the theme if implemented.
This closes #440

A lot of work, thank you very much.


ESP32-C3 LIBUSB error (openocd, probe.rs) (IDFGH-7149)

Environment

Development Kit: N/A (custom)
Kit version (for WroverKit/PicoKit/DevKitC): N/A (custom)
Module or chip used:  ESP32-C3-MINI-1
IDF version: v4.4
Build System:  idf.py
Compiler version: (crosstool-NG esp-2021r2-patch2) 8.4.0
Operating System: Windows 10
(Windows only) environment type: PowerShell.
Using an IDE? Yes, esp-idf vscode extension
Power Supply: USB

Problem Description
I cannot open the built-in USB interface with LIBUSB, no matter whether I use the espressif provided drivers, default windows, or zadig drivers (I tried every combo).
Expected Behavior
I can use libusb's open function on the device. This would allow me to use probe.rs.
Actual Behavior
Depending on which drivers I use (WinUSB, libusbk, usbser, espressif), I get any of the following errors:
LIBUSB_ERROR_NOT_FOUND
LIBUSB_ERROR_ACCESS
I may have also gotten these, but I'm not sure:
LIBUSB_ERROR_NOT_FOUND
LIBUSB_ERROR_NOT_SUPPORTED
The strangest part was that when I unchecked "Ignore Hubs or Composite Parents" in Zadig, and made the composite parent use WinUSB, I actually successfully opened the device with libusb, which meant that the probe.rs debugger worked! The issue with this approach was that it removed the two USBCDC interfaces and now it was only a WinUSB interface, which meant no COM port. So I was unable to flash the device at all anymore (at least using the UART setting in esp-idf vscode).
Steps to reproduce
Have a board using the built-in JTAG/Serial over USB (aka no UART chip, just uses D+ D- pins on esp32c3 directly)
Try using either openocd (which uses libusb), probe.rs debugger (uses libusb), or maybe manually try opening the device with libusb.
Code to reproduce this issue
cargo.toml should use probe-rs = "0.12.0"
fn main() {
    // Get a list of all available debug probes.
    let probes = probe_rs::Probe::list_all();
    println!("{probes:?}");

    // Use the first probe found.
    let probe = probes[0].open().unwrap();
}

Debug Logs
[ESP JTAG (VID: 303a, PID: 1001, EspJtag)]
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: ProbeCouldNotBeCreated(Rusb(NotFound))', probe\src\main.rs:7:34
stack backtrace:
   0:     0x7ff7a678ae8f - std::backtrace_rs::backtrace::dbghelp::trace
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\..\..\backtrace\src\backtrace\dbghelp.rs:98
   1:     0x7ff7a678ae8f - std::backtrace_rs::backtrace::trace_unsynchronized
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\..\..\backtrace\src\backtrace\mod.rs:66
   2:     0x7ff7a678ae8f - std::sys_common::backtrace::_print_fmt
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\sys_common\backtrace.rs:67
   3:     0x7ff7a678ae8f - std::sys_common::backtrace::_print::impl$0::fmt
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\sys_common\backtrace.rs:46
   4:     0x7ff7a679fffa - core::fmt::write
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\core\src\fmt\mod.rs:1168
   5:     0x7ff7a6788078 - std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\io\mod.rs:1660
   6:     0x7ff7a678d18b - std::sys_common::backtrace::_print
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\sys_common\backtrace.rs:49
   7:     0x7ff7a678d18b - std::sys_common::backtrace::print
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\sys_common\backtrace.rs:36
   8:     0x7ff7a678d18b - std::panicking::default_hook::closure$1
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:211
   9:     0x7ff7a678cc84 - std::panicking::default_hook
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:228
  10:     0x7ff7a678d68c - std::panicking::rust_panic_with_hook
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:606
  11:     0x7ff7a678d54b - std::panicking::begin_panic_handler::closure$0
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:502
  12:     0x7ff7a678b7d7 - std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure$0,never$>
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\sys_common\backtrace.rs:139
  13:     0x7ff7a678d249 - std::panicking::begin_panic_handler
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:498
  14:     0x7ff7a67c6c10 - core::panicking::panic_fmt
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\core\src\panicking.rs:116
  15:     0x7ff7a67c6d23 - core::result::unwrap_failed
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\core\src\result.rs:1690
  16:     0x7ff7a663174d - enum$<core::result::Result<probe_rs::probe::Probe,enum$<probe_rs::probe::DebugProbeError> > >::unwrap<probe_rs::probe::Probe,enum$<probe_rs::probe::DebugProbeError> >
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\library\core\src\result.rs:1018
  17:     0x7ff7a66310d0 - probe::main
                               at D:\Ryan\Programming\esp32c3_experiments\probe\src\main.rs:7
  18:     0x7ff7a663156b - core::ops::function::FnOnce::call_once<void (*)(),tuple$<> >
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\library\core\src\ops\function.rs:227
  19:     0x7ff7a663164b - std::sys_common::backtrace::__rust_begin_short_backtrace<void (*)(),tuple$<> >
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\library\std\src\sys_common\backtrace.rs:123
  20:     0x7ff7a6631441 - std::rt::lang_start::closure$0<tuple$<> >
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\library\std\src\rt.rs:145
  21:     0x7ff7a678a6ef - core::ops::function::impls::impl$2::call_once
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\library\core\src\ops\function.rs:259
  22:     0x7ff7a678a6ef - std::panicking::try::do_call
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:406
  23:     0x7ff7a678a6ef - std::panicking::try
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:370
  24:     0x7ff7a678a6ef - std::panic::catch_unwind
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panic.rs:133
  25:     0x7ff7a678a6ef - std::rt::lang_start_internal::closure$2
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\rt.rs:128
  26:     0x7ff7a678a6ef - std::panicking::try::do_call
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:406
  27:     0x7ff7a678a6ef - std::panicking::try
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panicking.rs:370
  28:     0x7ff7a678a6ef - std::panic::catch_unwind
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\panic.rs:133
  29:     0x7ff7a678a6ef - std::rt::lang_start_internal
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\/library\std\src\rt.rs:128
  30:     0x7ff7a663140f - std::rt::lang_start<tuple$<> >
                               at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a\library\std\src\rt.rs:144
  31:     0x7ff7a6631136 - main
  32:     0x7ff7a67c5160 - invoke_main
                               at d:\a01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78
  33:     0x7ff7a67c5160 - __scrt_common_main_seh
                               at d:\a01\_work\12\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288
  34:     0x7ffaaf427034 - BaseThreadInitThunk
  35:     0x7ffaaf562651 - RtlUserThreadStart

See also
My conversation on the probe-rs Matrix group where I debugged probe.rs and determined that it was a driver issue with libusb.
My conversation on the esp-rs matrix group where I troubleshooted the espressif provided drivers.

Here is the error from openocd when I try to start it:
debug_level: 2

adapter speed: 20000 kHz

WARNING: boards/esp32-wrover.cfg is deprecated, and may be removed in a future release.
         If your board is ESP32-WROVER-KIT, use board/esp32-wrover-kit-1.8v.cfg instead.
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
❌ Error: no device found
❌ Error: unable to open ftdi device with vid 0403, pid 6010, description '*', serial '*' at bus location '*'
❌ Error: no device found
❌ Error: unable to open ftdi device with vid 0403, pid 6014, description '*', serial '*' at bus location '*'

Assertion failed!

Program: D:\Ryan\.espressif\tools\openocd-esp32\v0.11.0-esp32-20211220\openocd-esp32\bin\openocd.exe
File: ../src/jtag/core.c, Line 343

Expression: jtag_trst == 0
[Stopped] : OpenOCD Server

Hi. Have you used the Windows tool installer (https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/get-started/windows-setup.html#esp-idf-tools-installer)? It should be able to install all the necessary drivers. But before that, please remove all of the drivers you installed earlier.
As for openocd, you used the wrong cfg file. It should be board/esp32c3-builtin.cfg.
More information: https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/jtag-debugging/index.html

Is it okay if I move this issue into openocd-esp32 repository? Given that both openocd-esp32 and probe.rs fail, this is likely a hardware issue, and esp-idf codebase is likely not yet involved.

sure, feel free to move it @igrr.
@dobairoland, yes, I tried with every combination of esp windows installer, idf-env, and all four zadig driver options. I also made sure to uninstall drivers too when I tried new options. I tried every possible permutation for at least 3 hours :)


[FR] Return order for non-serializable (trackable) items

Please verify that this feature request has NOT been suggested before.

[x] I checked and didn't find a similar feature request

Problem statement
We are using InvenTree to manage our small non-profit book warehouse. So far it served us a lot and we love how nifty it is.
We are trying to register Return Orders for books that get returned from our sellers/book fairs.
Unfortunately Return Orders only allow serialized (trackable) parts to be returned.
We ship dozens of books weekly so it is not practical to serialize (track) them.
Suggested solution
Is there a way to return non-serialized (non trackable) parts?
Describe alternatives you've considered
Modify the code ourselves?
Is there a simple/non-destructive way to modify the code for behavior this to work?
We have invested in this system and it would be tedious to migrate.
Examples of other systems
No response
Do you want to develop this?

[x] I want to develop this.

Upvote & Fund

We're using Polar.sh so you can upvote and help fund this issue.
We receive the funding once the issue is completed & confirmed by you.
Thank you in advance for helping prioritize & fund our backlog.

The return order was focused on "serialized" items to allow full traceability of items. If you have a method of discriminating between individual stock items (other than the serial number) then I have no idealistic objection to removing this limitation
I would probably suggest controlling this via a configurable setting, so that the behaviour could be configured.
Would you be willing to contribute some funding to this issue? It should not take a significant amount of time to implement this.

Hey @SchrodingersGat , Thanks for quick response!

I'm not very familiar with InvenTree internals, but as a KISS suggestion - could it just return the item(s) to the stock without location set?
Ideally for our use-case it: would allow setting returned amount and destination location.
I agree on configurable setting. I see how a lot of users won't be comfortable with this loose returns tracking.
I'm helping a volunteer organisation to modernize their processes so this is entirely on me. How much $$$ would make a worthy contribution? And how long could it take to implement? (weeks? months?)

@SchrodingersGat
Had some time so I sat down and added this feature as a separate section. Could you please review?
P.S. Cudos for devcontainers. Deploying this locally was a Breeze.


Added Classes to LinkRenderer

I added a "Classes" property to BaseLinkModel which is then used in the LinkRenderer. This allow users to add a css class to the  element of a link

hello @snakex64 i need added style to link like image or control in size arrow can inform me how can i do this ?

Sorry mate, no idea!
After 5 months I'm still waiting for the simplest ever PR to be merged 😴. Slowly giving up

This is highly needed, and seeing that its not been merged after so long even though its such a simple addition doesn't leave one feeling very hopeful for this repository.

Hello, sorry that this took A LOT of time for me to check it, I was dealing with some stuff.
The "issue" I see in this PR is that I am trying not to put UI properties in the models (Core project) to separate the two, so Classes doesn't fit in BaseLinkModel because it's only UI related, not behavior related.
I'm not sure what to do in this case...

Hi everyone, I was looking for the exact same feature.
I need to conditionally add a class to a Link (the "g" tag) to change its color, animate it, etc.
The ideal approach, in my view, is to use a custom LinkRenderer. Is it possible to have my own CustomLinkRenderer.cs file being used?
How can I do that?

@zHaytam I apologize for my previous comment, it was insensitive and i will act better in the future.
I still really want this feature so that we are able to individually style links between nodes. Right now you are only able to style all links at the same time as far as i know (except color).
Perhaps its possible to add the "Classes" to the LinkModel instead, and then consume it in the LinkWidget , like we do with Color today? It would give us a way to target individual links for styling, or even behaviour with DOM manipulation.

Hello, sorry that this took A LOT of time for me to check it, I was dealing with some stuff.
The "issue" I see in this PR is that I am trying not to put UI properties in the models (Core project) to separate the two, so Classes doesn't fit in BaseLinkModel because it's only UI related, not behavior related.
I'm not sure what to do in this case...

Hey! Never got a notification that you replied on here. Kinda forgot about it, I have been using my own fork for a while now.
Do you have any idea how to allow modifying the look of the link renderer other than the proposed implementation ? Being able to change the look of the links is important in many cases.
Thanks for your help,

Hey,
The way I see it, LinkModel was an error in the first place OR it should've been in the Blazor package, where it could contain HTML/CSS properties without any problem.
But the base model, as I pictured them, are just base, they should be UI-agnostic. Granted, we only have Blazor right now, but the logic can apply to different frameworks and I wanted to make it possible without changing or cross-using stuff in the projects.
So I see 2 solutions:

Etzix's PR, where it's in LinkModel, not the base one
Move the non-base models that have framework-specific stuff (e.g. Classes in Blazor) to the Blazor project, but that would maybe make some people angry at me :(

What do you guys think?
Again, sorry for the delay, life has been shit lately but it's getting better and better.


fix: drop indices if all fragment ids are missing

Closes #2718

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

Project coverage is 79.26%. Comparing base (b9990d9) to head (2e18a5d).
Report is 4 commits behind head on main.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2720      +/-   ##
==========================================
- Coverage   79.42%   79.26%   -0.16%
==========================================
  Files         227      227
  Lines       66880    66804      -76
  Branches    66880    66804      -76
==========================================
- Hits        53122    52955     -167
- Misses      10630    10737     +107
+ Partials     3128     3112      -16

Flag
Coverage Δ

unittests
79.26% <100.00%> (-0.16%)
:arrow_down:

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

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


Determine Approach for tracking configuration of different LZ

Describe the issue
Configuration of Landing zones (ex: SCPs) is currently stored only in within the LZ themselves. This provides no mechanism to compare differences between LZ and it is cumbersome to access like this.
Which Sprint Goal is this issue related to?

Note: 'Milestone' is a ZenHub term that we use synonymously with 'Sprint'.

Additional context
Definition of done

1 or more private repositories containing the configuration artifacts related to each of our Landing zones.
Read me file indicating how and where these are to be used
time-boxed

All LZ config will be stored in the terragrunt overlay live repo
https://github.com/bcgov-c/aws-sea-bcgov-overlay-live/


[disasters] fix bug with leaf pages

We currently throw an error if there aren't any child place types to fetch (if we are on a leaf page according to the config), introduced in #2448
Also fixed a couple of strange sounding chart titles

thanks for the review!


'CUDAUFuncDispatcher' object has no attribute 'name'

Issue
This might be a simple oversight, but anyway, I stumbled across this while testing and benchmarking:
import numba as nb

@nb.vectorize('f8(f8)', target = 'cpu')
def foo(x):
    return x ** 2

@nb.vectorize('f8(f8)', target = 'cuda')
def bar(x):
    return x ** 2

assert foo.__name__ == 'foo'
assert bar.__name__ == 'bar'

The second assertion, i.e. the one for bar, fails, causing AttributeError: 'CUDAUFuncDispatcher' object has no attribute '__name__'. For foo, the assert passes as expected. The difference: foo is compiled for target cpu, bar is compiled for target cuda. Otherwise, everything is identical. It would be useful if numba was consistent here.
Context

CPython == 3.10.5 (Linux, x86_64)
numba == 0.55.2
llvmlite == 0.38.1

Workaround
Not sure how reliable this is, but the following appears to work:
def _name(func):
    try:
        return func.__name__
    except AttributeError:
        return list(func.functions.values())[0][1].py_func.__name__[13:]

assert _name(bar) == 'bar'

Thanks for the report. @testhound / @gmarkall please could you take a look at this as it's CUDA target, many thanks.

@stuartarchibald created a PR to address this issue: https://github.com/numba/numba/pull/8297


unattended_upgrades: Allow changing legacy_origin

This enables using Origins-Pattern on Ubuntu.

I'm going to need a example here. I don't see how this fixes anything.

Hi,
I want to use the APT configuration variable Unattended-Upgrade::Origins-Pattern to tune where unattended-upgrades should search for upgradable packages on Ubuntu. Currently the apt Puppet module only allows using the legacy variable Unattended-Upgrade::Allowed-Origins.
apt::unattended_upgrades inherits apt::params which sets the $legacy_origin variable to true if the operating system is Ubuntu. This variable is used in the template apt/50unattended-upgrades.erb to select which APT variable name is written in the configuration file.
This patch enables using Origins-Pattern on Ubuntu when the new apt::unattended_upgrades parameter legacy_origin is set to false. For example:
class { apt::unattended_upgrades:
  legacy_origin => false,
  origins => [
    'site=archive.ubuntu.com',
  ]
}

Aha. Now I see what you're getting at. Thank you!


dpkg packages can have . in their names

http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source

Thanks, Is there a corresponding ticket for this on http://tickets.Opscode.com?

There isn't.

See http://tickets.opscode.com/browse/CHEF-2488 resubmitted with wjessop's permission.


Replace {type_id} for releases with {release_tag}

Closes #94.

Codecov Report

Merging #97 (dd7be12) into master (0f13cf6) will decrease coverage by 26.99%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master      #97       +/-   ##
===========================================
- Coverage   67.92%   40.93%   -27.00%
===========================================
  Files           9        8        -1
  Lines         820      816        -4
  Branches      121      121
===========================================
- Hits          557      334      -223
- Misses        221      482      +261
+ Partials       42        0       -42

Impacted Files
Coverage Δ

src/tinuous/github.py
31.12% <ø> (-22.45%)
:arrow_down:

src/tinuous/__main__.py
0.00% <0.00%> (-58.65%)
:arrow_down:

src/tinuous/appveyor.py
33.33% <0.00%> (-46.92%)
:arrow_down:

src/tinuous/base.py
61.60% <0.00%> (-26.40%)
:arrow_down:

src/tinuous/config.py
77.21% <0.00%> (-13.93%)
:arrow_down:

src/tinuous/travis.py
28.97% <0.00%> (-8.42%)
:arrow_down:

src/tinuous/util.py
79.54% <0.00%> (-6.82%)
:arrow_down:

src/tinuous/_version.py

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 0f13cf6...dd7be12. Read the comment docs.


Feature Request: Add recommendations about Power BI PL connectivity

Describe the solution you'd like
Add guidance for Private Endpoint connectivity for Power BI: https://docs.microsoft.com/en-us/power-bi/admin/service-security-private-links

@daltondhcp as we have a milestone and backlog label, could you please choose priority & size and assign a team member or move this item to "new" status? Thank you


Added more GitHub metadata files.

This PR adds a new contribution guide and issue template for the Quantum Development Kit samples.

Incorrect link to Stack Overflow. It point to vscode tag, instead of qsharp


Fix Issue #191. Remove call of validateSuccessfulResponse from result<T: DataResponseSerializerProtocol> method. #trivial

I described my concern in https://github.com/RxSwiftCommunity/RxAlamofire/issues/191 issue. But just to be clear I see no reason to have validateSuccessfulResponse in result<T: DataResponseSerializerProtocol> function. Thanks!

rynecheow Hi, I requested review from you, cause I see you did a lot of work for this project. Thank you!
Could you please take a look at this issue. Have a nice day!

@rynecheow Thanks! 🤝


chore: bdd-gh-1593140433 to 0.0.1

chore: Promote bdd-gh-1593140433 to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


No key matching kid or alg found in signing keys.

After switching from "Test" IdentityServer configuration to EF Core storage and ASP.NET Core Identity configuration, on my JS client, I'm getting this error ("No key matching kid or alg found in signing keys").
jwks endpoint returns:
{
  "keys":
  [
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "ba583f56ce1a7a1e0a09236d7205fd78",
      "e": "AQAB",
      "n": "ykISgU8UZV4klvnBC_7jv8lcQyMdLxOOkV-73WueVb0MjBxTOfK0nYzBSs0-ouPC5gLtkC4TqL3kGGZQOIMV7AZV6G81BhRsA1y2Zy00NtlPRKwU7Y_VUGdH9aGtE4CwyVXmkENxKh8VpETsIaYuAjQdz75YQQoOjdVFyEeVoRMmaFzgx5wBinWpR4i8AKn554KW2vk6gIfcwUm18RimJiOA4lglbAJB-Ihw-zFzRzzbdVw90avvAPugqDA2pWKEeyl6CQVied7fIGUldCIkstMzZPM-Yg1a_GQOvtOZb1mVN_Y3QUJGmL9uRGVIwiILRbDYc0Q9JJPMgM2pI2tb3Q"
    }
  ]
}

We have also faced the same issue recently (using 1.3.0 version) without changing anything as far as we can tell.
From the error message, we suspected that the KID (key identifier) had changed in IdentityServer since the token was issued and therefore out-of-sync with the client. We were using the temp signing credentials (this is a DEV environment) and hosting in Azure App (free plan).
We just tried using dev signing credentials instead (which persists the key) and we have not seen the error since then. You may want to verify that you are not using a temp signing key.

Without changing anything, it works now, with or without temporary certificate. It must have been some browser cache, local storage information or anything. Weirdly, I tried to clear all those, but it didn't work. It started working now for no apparent reason.

It must have been indeed some cache issues. I faced similar issues when playing with different key signing implementation. What seemed to work was to clear local/session storage for both IDServer and application and clear the browser cache too...

Yes, we had caching on by default in IdSvr which we considered a bug and fixed recently.


Use --processor-module-path instead of -processorpath in JDK9+

Expected Behavior
If JDK version is 9 or above, it should use --processor-module-path instead of -processorpath when specifying an annotation processor.
Current Behavior
subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java uses -processorpath for all versions.
Context
Due to the removal of javax.xml.bind from JDK11 this prevents the use of hibernate-jpamodelgen.
This feature requires that JDK-8223942 is fixed first, or that SourcepathIgnoringProxy not be used, and just have the task always be invoked, instead of just when not up-to-date.

JDK-8223942 is now fixed for JDK 13 b25 and the upcoming JDK 14 LTS release, but they have decided not to apply the fix to the current LTS version JDK 11.

Is there any plans for this to be implemented, as it stands there is no way to define modular annotation processors as https://github.com/gradle/gradle/blob/45d830666efe92b35f750422d57f202e52ee3cac/platforms/jvm/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java#L214 will always add processors to the legacy processorpath.


src/cli.rs: Refactor to separate command processing function, have it write to a buffer.

Lots of changes, but does NOT change functionality; it is a pure refactor (modulo removing some extraneous >  prompt printings).
As a refactor you do not need to review it, you just need to run automated tests, but note that we have 0 automated tests.  In theory you could pull this pull request, compile, then just run it directly on lightning polar and see if it does not crash massively.
Note that because this massively changes the command processing, it causes us to effectively break from upstream, unless we also PR to upstream our changes here.

I ran a series of rather non-automated tests in Polar as suggested, and observed no crashes (massive or otherwise)


operator >> and operator >>> documentation

The documentation for operator >> and operator >>> reads very similar, and it's not at all clear from the documentation what the difference is.
Also, operator>>> claims not to be implemented, but is, at least in some of our compilers.

Where are you seeing documentation saying that >>> isn't implemented?
The >>> operator on int does not mention not being implemented. The documentation is:
  /// Shift the bits of this integer to the right by [shiftAmount].
  ///
  /// Shifting to the right makes the number smaller and drops the least
  /// significant bits, effectively doing an integer division by
  ///`pow(2, shiftIndex)`.
  ///
  /// It is an error if [shiftAmount] is negative.
  int operator >>(int shiftAmount);

  /// Bitwise unsigned right shift by [shiftAmount] bits.
  ///
  /// The least significant [shiftAmount] bits are dropped,
  /// the remaining bits (if any) are shifted down,
  /// and zero-bits are shifted in as the new most significant bits.
  ///
  /// The [shiftAmount] must be non-negative.
  int operator >>>(int shiftAmount);

The >> operator should probably say that it always retains the sign of the value, where any non-zero shift of >>> gives a non-negative result. If anything, >> should be more like >>> and say that the top bits are shifted down, and the most significant bit is used to fill the new top bits.

A link to the number semantics document might seem ephemeral, but if it is an acceptable kind of information in a system library DartDoc then it would probably be quite helpful for developers whose target platforms include the web.

Ah, the "not implemented yet" message is on the Flutter stable API docs, looks like that's been removed already.


app hangs, because JVM runs out of memory.

It's not clear what you mean here - that Sparrow has a memory leak? Or the JVM itself? If so please open an issue with evidence of this - I have done long running memory monitoring tests on all 3 platforms to test this, and have found no evidence of it.
Originally posted by @craigraw in https://github.com/sparrowwallet/sparrow/issues/538#issuecomment-1120726816

~$ tail -f /home/user/.sparrow/sparrow.log
2022-05-17 17:35:15,146 WARN [Thread-1873] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2022-05-17 17:42:14,444 WARN [Thread-1905] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2022-05-17 17:45:23,664 WARN [Thread-1917] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2022-05-17 17:52:39,432 WARN [JavaFX Application Thread] c.s.s.w.Whirlpool [null:-1] No UTXOs mixing, but mixingProperty is true
2022-05-17 17:59:10,267 WARN [JavaFX Application Thread] c.s.s.w.Whirlpool [null:-1] No UTXOs mixing, but mixingProperty is true
2022-05-17 18:03:49,037 WARN [JavaFX Application Thread] c.s.s.w.Whirlpool [null:-1] No UTXOs mixing, but mixingProperty is true
2022-05-17 18:42:27,968 WARN [Thread-2162] c.s.s.n.TcpTransport [null:-1] No response from server, setting read timeout to 34 secs
2022-05-17 18:49:32,615 WARN [JavaFX Application Thread] c.s.s.w.Whirlpool [null:-1] No UTXOs mixing, but mixingProperty is true
2022-05-17 18:51:36,176 ERROR [JavaFX Application Thread] c.s.s.MainApp [null:-1] Exception in thread "JavaFX Application Thread"
java.lang.OutOfMemoryError: Java heap space

If more memory becomes available, the app remains unresponsive.
CPU stays 80-90% for Sparrow, with RAM around 38%.

Thanks for the report. Does this happen after a period of time of inactivity on the wallet, or immediately on some action (for example, loading a deep wallet?)

Seems to happen randomly, when I am not watching it. It's usually mixing. So, there is usually activity when it happens. I doubt I have any deep wallets anywhere, and certainly not in sparrow.


AppiumLibrary

I am using appiumlibrary-robot framework in eclipse.
I am using my real device and have few queries as I stuck there.

While running my script in eclipse I am opening appium studio and then launch real device is that right practice else how to add and view real device interface in eclipse. In run configuration of eclipse I am not able to set my device under robot preference. any solution?
The app under test is opening properly with selected field for user name but keyboard is not displaying till I tab to password field. How to open keyboard and select the user id.
I dont want to Input Text directly.

Thanks
Adi

@Adi-2020 This is issue tracker for problems or enhancements, not for questions (like you already did on Slack).


capd workloadcluster prov. with argocd workflow trigger

/kind feature
Describe the solution you'd like
When we create a workload cluster ontop of the mgmt cluster, the workload cluster has to pull a lot of things in order to get fully ready.
As soon, as the control plane is ready - on mgmt-clusters perspective - the argocd workflow kicks in, and tries to run every thing.
The Script will fail, since the worker nodes and everything else is not yet fully ready and the part "Adding the workload cluster to argohub" will not work.
As a workaround, i set a high timer, so that the script will wait till everything will - eventually - be up and running.
Best solution would be:
Checking, that everything is up and running on the workload cluster. Maybe we should think about an event type, or using cloud events.
Anything else you would like to add:
This might be only an issue on local development, and might depend on your actual download speed from your internet provider.

With PR #74 I introduced the statuscheck package, which allows us to check for deployment states of whatever deployment you like.
With this package, we could implement a check to make sure, that everything is up and running, before we allow the script to run.
Whats happening:

a workload cluster is prov. against the mgmt cluster
the workload cluster installs everything needed via helmchartproxies
the script will start to run, as soon as the workload clusters state is ready (which is almost directly after provisioning.)


[Taxon Byteranges] Fix getter functions for fasta downloads

Going to put up another PR later with more fixes but this is the safest
First change is changing a pipeline_run.taxon_byteranges.find_by(taxid: taxid, hit_type: hit_type) to pipeline_run.taxon_byteranges.where(taxid: taxid, hit_type: hit_type).last because it appears we had pipeline runs inserting byteranges from the previous run and then the correct one being inserted later. This enables a "quick fix" by calling db_load_byteranges on all the pipeline runs again and then fetching the last correct one. Then we will clean up all the duplicates (saving the last one) and correct the unique index on (pipeline_run_id, taxid, hit_type) since there's a unique index (pipeline_run_id, taxid, hit_type, tax_level) that's useless.
Second is fixing an assumption in s3_file_for that was saying if pipeline_version and assembly-enabled, load the new path; else load this old file so the old file was being loaded when pipeline_version was not yet set in a new pipeline run. Add a log line in ResultMonitorLoader for pipeline version. Migrate s3_file_for to just use the new assembly paths to deprecate running < 3.1.
Will need some more test jobs in staging.

How to reproduce

Go to a sample on this broken list: https://jira.czi.team/browse/IDSEQ-881
Go to the console and run pipeline_run.db_load_byteranges
Call pipeline_run.taxon_byteranges.where(taxid: taxid, hit_type: hit_type) and notice that the last entry is the correct one. Example: => #<ActiveRecord::AssociationRelation [#<TaxonByterange id: 132270753, taxid: 12059, first_byte: 10670019, last_byte: 10900167, created_at: nil, updated_at: nil, hit_type: "NT", tax_level: nil, pipeline_run_id: 23682>, #<TaxonByterange id: 134558333, taxid: 12059, first_byte: 4675807, last_byte: 4839836, created_at: nil, updated_at: nil, hit_type: "NT", tax_level: nil, pipeline_run_id: 23682>]>
Grabbing the last byterange will result in a valid fasta download (or deleting all but the last one)

We discussed adding a comment about our assumption that pipeline_version > 3.1 in get_s3_file


Make the Tab component compatible with linkButton and containerElement

Problem Description
Using the syntax :
<Tab
        label="Demandes archivées"
        linkButton
        containerElement={<Link to="/recherche/demandes-archivees" />}
/>

The routing works as expected, but the tabs aren't displayed correctly anymore, here is a screenshot :

As you can see, the text is misplaced now.
Versions

Material-UI: v0.14.4
React: v0.14.7
Browser: Chrome Version 48.0.2564.116 (Windows)

EDIT : Also, on Firefox, the Tab need to be double clicked to activate the Link. xD

Sorry for the double post.
I updated to Material-UI 0.15.0-alpha.1, and it seems that now, the style property of the Tab component isn't passed down anymore.
I was able to modify the styles in v0.14.4 to make a quickfix (style={{ textAlign: "center", paddingTop: "18px" }}) but it doesn't work anymore.

@jgoux you asked about me closing this, was it not fixed?

The fixed part was just for the style passing. :smile:
But the main issue remains, ideally I wouldn't need to pass my own styles to fix the text-centering issue.

@jgoux : Was this issue fixed for you? Can this issue be closed?

@jgoux Do you have got the resolution for it ? I don't figure out how to combine the <Link /> with <Tab /> for routing... Can you share it in this issue? thank you~

@chengjianhua You can do something like this: <Tab label="Link" href="/link" />

Other choice :)
<Tabs onChange={this.changeTab} value={value}>    <Tab value={0} label="first" containerElement={<Link to="/first"/>} />    <Tab value={1} label="second" containerElement={<Link to="/second"/>}/>    <Tab value={2} label="third" containerElement={<Link to="/third"/>} />  </Tabs>
It is weird that I do not see this choice in documentation
Source: http://stackoverflow.com/questions/37843495/material-ui-adding-link-component-from-react-router


Print all subset lexicographically

Hey! @tarun26091999 sir I am GSSOC'21 Participant and I want to add this issue if you allow.
input : 1 2 3
Output :
{}
1
1 2
1 2 3
2
2 3
3
We will have all the subset in lexicographic order.

@IShahnawazShaikh do it in java and use backtracking only.

Hello, I am a gssoc21 participant and I would like to work on this issue in C++ and python.
Please assign it to me. @tarun26091999 @rudrakshi99

Hello, I can solve this in C++ and Java.
Please assign it to me. @tarun26091999 @rudrakshi99


Adding TableView/useTable/useTableState docs mdx

Closes https://github.com/adobe/react-spectrum/issues/1648 and #1913
✅ Pull Request Checklist:

[ ] Included link to corresponding React Spectrum GitHub Issue.
[ ] Added/updated unit tests and storybook for this change (for new code or code which already has tests).
[ ] Filled out test instructions.
[ ] Updated documentation (if it already exists for this component).
[ ] Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

To be merged after release


feat: add kind annotation to EC ITS

Fixes

Description
The auto-created Enterprise Contract IntegrationTestScenarios are now annotated with test.appstudio.openshift.io/kind: enterprise-contract annotation.
Type of change

[x] Feature

Screen shots / Gifs for design review

n/a
How to test or reproduce?
Create an Application, and check that the auto-generated Enterprise Contract IntegrationTestScenario has the test.appstudio.openshift.io/kind: enterprise-contract annotation.
Browser conformance:

This change should be browser independent, it only contains logic changes and doesn't touch the browser.

[ ] Chrome
[ ] Firefox
[ ] Safari
[ ] Edge

Checklist:

[x] Code follows the style guidelines
[x] Self-reviewed the code
[ ] Added comments in hard-to-understand areas
[ ] Made corresponding changes to the documentation
[x] Changes generate no new warnings
[x] Added tests that prove this fix is effective or that the feature works
[x] New and existing unit tests pass locally with new changes
[ ] Any dependent changes have been merged and published in downstream modules

Typo in PR title FYI: s/ annotatition / annotation /

/ok-to-test

/approve
/lgtm


Bug: sink syntax not consist with doc

Describe the bug
In our doc, it seems we already claim all sink already support FORMAT ... ENCODE ... syntax. We do this change in #12556, but acutally not all sink support it. For example our NATS doc, the example command is:
CREATE SINK [ IF NOT EXISTS ] sink_name
[FROM sink_from | AS select_query]
WITH (
   connector='nats',
   server_url='<your nats server>:<port>', [ <another_server_url_if_available>, ...]
   subject='<your subject>',

 -- optional parameters
   connect_mode=<connect_mode>
   username='<your user name>',
   password='<your password>'
   jwt=`<your jwt>`,
   nkey=`<your nkey>`
)
FORMAT PLAIN ENCODE JSON;

But when try locally in latest main, it will show:
dev=> create sink s1 as
dev-> select
dev->     *
dev-> from
dev->     person with (
dev(>         connector = 'nats',
dev(>         server_url = 'localhost:4222',
dev(>         subject = 'event1',
dev(>     ) format plain encode json;
ERROR:  Failed to run the query

Caused by:
  Bind error: connector nats is not supported by FORMAT ... ENCODE ... syntax
dev=>

I guess some other sink doc may also exist this problem.
Error message/log
No response
To Reproduce
Start nats locally nats-server -js
Then try following:
CREATE TABLE person (
    id integer,
    name varchar,
);

INSERT INTO person VALUES (1, 'Alice'), (2, 'Bob');
INSERT INTO person VALUES (3, 'Tom'), (4, 'Jerry');

FLUSH;

# this will fail
create sink s1 as
select
    *
from
    person with (
        connector = 'nats',
        server_url = 'localhost:4222',
        subject = 'event1',
    ) format plain encode json;

# this will sucess
create sink s1 as
select
    *
from
    person with (
        connector = 'nats',
server_url = '<IP_ADDRESS>:4222',
subject = 'event1',
type = 'append-only',
force_append_only = 'true',
connect_mode = 'plain'
    );

Expected behavior
No response
How did you deploy RisingWave?
No response
The version of RisingWave
No response
Additional context
No response

The documentation section of the aforementioned PR clearly states that only kafka/kinesis/pulsar has been migrated to the new syntax. But yes we shall migrate nats as well.

closed by changing docs https://github.com/risingwavelabs/risingwave-docs/pull/1921


Upon Next v6 upgrade, global styles got broken

Do you want to request a feature or report a bug?
I want to report a Bug
What is the current behavior?
When upgrading to Next v6.0.3, my global styles have stopped working displaying the message: "styles is not defined", I'm currently using styled-jsx with styled-jsx-css-loader
If the current behavior is a bug, please provide the steps to reproduce and possibly a minimal demo or testcase in the form of a Next.js app, CodeSandbox URL or similar

Upgrade application to Next 6.0.3
Follow the steps mentioned at the following link to update the Redux dependencies also: https://github.com/kirill-konshin/next-redux-wrapper#upgrade

Git repo with the use case in action, simple setup from scratch and it fails exactly the same:
https://github.com/voxmachina/nextjs-6-with-styled-jsx-demo
What is the expected behavior?
I would expect that the stylesheets would behave the same way as before and not break, note that only the "global" ones are failing, the others (scopped) are working ok as before.
Environment (include versions)

OS: macOS High Sierra (10.13.4)
Browser: Chrome 66.0.3359.181
styled-jsx (version): 2.2.6

Did this work in previous versions?
Yes, it did work before the upgrade

I have similar problem. https://github.com/zeit/next.js/issues/4239#issuecomment-392468298 has explained the correct way to config babel. But it can not solve when run with jest.
check out this. https://github.com/zeit/next.js/issues/4501 shows yarn dev and yarn build works correctly. but yarn test will break.
But I have no idea to address the problem.

Yap, thanks for the reference, just tried now @blackbing still the same error, doesn't solve it for me either :/

it might be an issue with Babel 7, I think that a temporary workaround is to use CommonJS exports instead of ES6:
module.exports = css`
  div { color: red }
`

Hi Everyone! I tried to figure out this issue. How said @giuseppeg there is problem with Babel 7 and  after 2 days I got it. So I just create "crutch". Here is my _document.js

Hi Everyone! I tried to figure out this issue. How said @giuseppeg there is problem with Babel 7 and after 2 days I got it. So I just create "crutch". Here is my _document.js
import React from 'react';
import Document, { Head, Main, NextScript } from 'next/document';
import JssProvider from 'react-jss/lib/JssProvider';
import flush from 'styled-jsx/server';
import getPageContext from '../src/getPageContext';
import baseStyles from '../styles/style.scss'

class MyDocument extends Document {
    render() {
        const { pageContext } = this.props;

        return (
            <html lang="en" dir="ltr" id="html">
            <Head>
                <title>InstaLazier</title>
                <meta charSet="utf-8" />
                {/* Use minimum-scale=1 to enable GPU rasterization */}
                <meta
                    name="viewport"
                    content={
                        'user-scalable=0, initial-scale=1, ' +
                        'minimum-scale=1, width=device-width, height=device-height'
                    }
                />
                {/* PWA primary color */}
                <meta name="theme-color" content={pageContext.theme.palette.primary.main} />
                <link
                    rel="stylesheet"
                    href="https://fonts.googleapis.com/css?family=Roboto:300,400,500"
                />

            </Head>
            <body>
            <Main />
            <NextScript />
            </body>
            </html>
        );
    }
}

MyDocument.getInitialProps = ctx => {
    // Resolution order
    //
    // On the server:
    // 1. page.getInitialProps
    // 2. document.getInitialProps
    // 3. page.render
    // 4. document.render
    //
    // On the server with error:
    // 2. document.getInitialProps
    // 3. page.render
    // 4. document.render
    //
    // On the client
    // 1. page.getInitialProps
    // 3. page.render

    // Get the context of the page to collected side effects.
    const pageContext = getPageContext();
    const page = ctx.renderPage(Component => props => (
        <JssProvider
            registry={pageContext.sheetsRegistry}
            generateClassName={pageContext.generateClassName}
        >
            <Component pageContext={pageContext} {...props} />
        </JssProvider>
    ));
   // const test = "<style>html{font-family:'Roboto',sans-serif;}body,h1,h2,h3,h4,h5,h6{font-size:15px;margin:0;line-height:24px;}body{margin:0;background-color:#FAFAFD;overflow-x:hidden;}body,html,#__next,#__next>div{display:-webkit-box;display:-webkit-flex;display:-ms-flexbox;display:flex;width:100%;overflow-y:auto;overflow-x:hidden;}#next{background-color:red;}#__next,#__next>div,body,html{height:100%;}a{color:transparent;-webkit-text-decoration:none;text-decoration:none;}a:hover{-webkit-text-decoration:underline;text-decoration:underline;}.b-icon{max-width:16px;width:100%;height:auto;}.b-icon--margin{margin-right:20px;}</style>"

    return {
        ...page,
        pageContext,
        styles: (
            <React.Fragment>
                <style
                    id="jss-server-side"
                    // eslint-disable-next-line react/no-danger
                    dangerouslySetInnerHTML={{ __html: pageContext.sheetsRegistry.toString() }}
                />
                <style
                    dangerouslySetInnerHTML={{ __html: baseStyles.toString() }}
                />
                {flush() || null}

            </React.Fragment>
        ),
    };
};

export default MyDocument;

So I just added manually second

And after that everything work nice on next 6.0.3.
I dont know how it will work in production but i guess babel will figure out this issue in the near future.

Probably we are re using AST nodes which instead we should clone.

this was fixed in #470


Problem with welds in 23 version [BUG]

Hi,
I have problem with CreateConProjFromIOM method and creating ideaCon file. The welds are in invalid places.
In 22 version everything was fine. Problem was occur in 23.

22:

23:

example.zip

Hi Nathan,
I sending you some example data in attachments…
Cheers
Witek
From: nathanlukeIDEA @.>
Sent: Tuesday, May 16, 2023 3:17 AM
To: idea-statica/ideastatica-public @.>
Cc: Witold Dryja @.>; Mention @.>
Subject: Re: [idea-statica/ideastatica-public] Problem with welds in 23 version [BUG] (Issue #285)
Hi @rewiteqhttps://github.com/rewiteq,
Can you please send me your IOM file? I just want to make sure we have fixed this now.
Cheers
Nathan
—
Reply to this email directly, view it on GitHubhttps://github.com/idea-statica/ideastatica-public/issues/285#issuecomment-1548828322, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A3TLDULRGKEIUJVJI6RM4Y3XGLIRVANCNFSM6AAAAAAX7SGO5A.
You are receiving this because you were mentioned.Message ID<EMAIL_ADDRESS>

@rewiteq I don't believe the attachments have come through. Are you able to attach it?

Ok, Sorry
exampleNew.zip

@rewiteq thanks for providing. This will be fixed in the next patch, due to be released next week. Please let me know if you are still having issues.


Make use of member function that already exists [phab:D1005]

Created by salguarnieri at 2016-08-11 23:38:46:
Remove code duplication.

zarko wrote at 2016-08-11 23:40:40:
Thanks!

zarko accepted this revision at 2016-08-11 23:40:40

salguarnieri closed via commit 795d5dc941325520480257a0d82bfa505e683824 at 2016-08-11 23:49:42


Rename is_mentor to is_faculty

We already have is_mentor, but if we want students to be able to mentor, we need another way to keep track of who is a student. Solution: is_faculty field on VerificationEmail.

faculty should not see students when they browse profiles
admin should be able to view and edit this field
New button on homepage for students browse student mentors

wording -> browse faculty profiles

New button for students "create peer mentor profile" on home page

Finished!

Great @Chronowork1! Could you make a pull request for your changes? When they’re merged in I’ll close this issue. Let me know if you need any further explanation.

I think I just pushed my changes to the staging branch of Weave.
Do you want me to make another branch and push my changes to Weave?
On Mon, Jun 15, 2020 at 9:34 AM Razzi Abuissa<EMAIL_ADDRESS>wrote:

Great @Chronowork1 https://github.com/Chronowork1! Could you make a
pull request for your changes? When they’re merged in I’ll close this
issue. Let me know if you need any further explanation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/razzius/weave/issues/150#issuecomment-644241006, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AF7N6UUJJZWEUNHJ3MVIHNLRWZEQJANCNFSM4KJMMQHA
.