I've got an extremely preliminary, completely untested, totally not ready for more than a cursory glance, probably introduces more problems than it solves, set of changes that removes the response object in favour of using the exceptions.
I will need to go get another PCM before I can test the vast majority of this because I can't be toying with the one in my truck right now, but I think I'm heading in the right direction. If anyone cares to have a look at the changes and either tell me I'm headed in the wrong direction or point out things that could be problems, I would appreciate the input. The changes can be seen here: https://github.com/patrickmcquay/PcmHac ... exceptions
A lot of the changes involve removing cases where failure is checked for after calling something, in favour of just letting exceptions from the called thing pass through to be logged in the frontend. This will change how the messaging for errors happens, so making sure that still makes sense will have to be a step in testing. That said this does remove about 1000 lines of code, so things will get at least a bit simpler.
Logger improvements
Re: Logger improvements
Last edited by pmcquay on Wed Jun 26, 2024 12:47 am, edited 1 time in total.
Re: Logger improvements
I do see another thing that can be optimized a bit as well, I think. There are a _lot_ of cases of hand coded retry loops that could be refactored into helpers that take lambdas. Some of these cases are multiple loops deep as well. I'm not entirely sure that that sort of thing is needed, but my point isn't to say those should be removed. My point is that this logic happens a lot, so IMO it should be centralized and standardized. There is a lot of good commentary and examples in this thread: https://stackoverflow.com/questions/156 ... etry-logic (also a lot of people saying don't do it, which tells me they've never worked with flaky serial connections before...)
- antus
- Site Admin
- Posts: 9009
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: Logger improvements
From a quick skim I can see a lot more code coming out than going in, which is usually a sign you are on the right path.
Just watch out for the fact that I plan to merge antus/p08 branch in to develop as soon as I hear back from NSFW and he is able to approve the merge. I havnt seen Gampy for a while and so I need him to approve the merge which does not exist yet.
i wonder if it'd be possible for you to rebase off antus/p08 before you get too far ahead?
Just watch out for the fact that I plan to merge antus/p08 branch in to develop as soon as I hear back from NSFW and he is able to approve the merge. I havnt seen Gampy for a while and so I need him to approve the merge which does not exist yet.
i wonder if it'd be possible for you to rebase off antus/p08 before you get too far ahead?
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: Logger improvements
From what I can see this will not be terrible to rebase. I have a lot on the go for the next week or two, so its no big deal for my work here to wait for yours to merge.
- antus
- Site Admin
- Posts: 9009
- Joined: Sat Feb 28, 2009 8:34 pm
- cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B - Contact:
Re: Logger improvements
OK Cool. I did a rebase off develop at some stage so there want too much divergence. It might not be a big deal but there are still some heavy changes, which are mostly PCM data and some usability improvements pending.
If your git foo is strong you can probably compare the branches and see if were going to have merge hell or not. Quite possibly not if your mostly in the comms libraries etc whereas I touched the UI logic starting operations and PCM Info/Types.
If your git foo is strong you can probably compare the branches and see if were going to have merge hell or not. Quite possibly not if your mostly in the comms libraries etc whereas I touched the UI logic starting operations and PCM Info/Types.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
Re: Logger improvements
I mean, most of my work is nearly guesswork at this point. I think that the main part of the merge conflicts here is going to be mainform.cs, and I don't think its going to be a big problem. I'll just wait for your work to be merged, and if it hasn't in a couple weeks, then I'll see about rebasing.