Stop trying to write to address FFFFFFFFFFFFFFF8 #38
Conversation
Add a conditional check for the file 1100tags.txt. If it doesn't exist in the user defined data directory, then default to the Pgm_root/data directory.
An I2CS device will respond with a NACK if you try and control it with the PLM before it is linked as a responder. Add a note to the debug log regarding this.
Based on Marc Merlin's code, I confirmed that I received the same error. More issues with #28 still need to be solved.
These are likely causing some unnoticed error.
Clean up conflicts in AllLinkDatabase.pm. I had uded more concise languge, but verbose is likely easier to read. Conflicts: lib/Insteon/AllLinkDatabase.pm
The sub add_link expects get_first_empty_address to return 0 if no empty address is found. This will prevent trying to add an aldb record to the FFFFFFFFFFFFFFF8 address which clearly doesn't exist. Instead the user will now get a nice error advising them to scan the link table before trying to sync links.
|
Hi Robert, would it be possible for you to create a new branch for specific fixes? Now you're adding them all to the same branch and .this means I cannot easily pull a specific fix into the main repo. Kind regards, Op 17-jan.-2013, om 22:26 heeft krkeegan [email protected] het volgende geschreven:
|
|
I did put this most recent fix in a separate branch as you previously requested. The other commits I made part of my master branch before you asked me to make separate branches for each fix. Fix for #27 - you already committed. In all if you review the actual changes you will see there is no much changed. If you want me to roll back everything to try and separate all of the previous changes into separate branches, I can probably do that, it will just take a while. Kevin |
|
Hi Kevin, Sorry for the name confusion in my previous mail. I will merge your pull request first thing tomorrow. I need to figure out Kind regards,
|
|
I think the other commits are mentioned because of my misuse of git. For example, when Marc and I both fixed the same problem but used different code to do so, I merged Marc's changes over mine. Naively I thought this would cause my changes simply to be "ignored" for lack of a better word. I now see that my most recent pull request is basically asking you to put my version of the fix into the history of the file. I clearly didn't think this through. I need a little help on how I should be tracking your master branch. I don't think my system of merging in your master branch into my master branch is the appropriate way to go. Should I create a tracking branch in my repo and then rebase in your master branch whenever it changes? Thanks for any guidance you can offer. I figure at some point I will understand git. |
|
Hi Kevin, I see you have closed this pull request and that you have in the mean time created separate new pull requests. So I guess you solved your git workflow? Kind regards, |
|
Lieven, Yes, I fixed my pull requests. But I still have some questions about creating an git workflow. You seem I think I have two requirements:
Right now I have 3 Categories of branches in my repository: *master - Which is set to track your master branch. This way I can create *1 or more branches of "fixes" - These are branched from master. They each *running - This was originally branched from master, but has merged in the My main question is, what do I do with the running branch? I can see right Do I have to continually just abandon the running branch when the upstream I hope my questions are clear. I have been trying to read up on git, but I Kevin On Fri, Jan 18, 2013 at 12:47 AM, Lieven Hollevoet <[email protected]
|
|
Hi Kevin, Sorry for the late reply, I have been offline the last few days. I will be glad to help you further this weekend. Kind regards, Op 18-jan.-2013, om 18:39 heeft krkeegan [email protected] het volgende geschreven:
|
|
Hello Kevin, I don't know why you would need to keep your running branch different from your master branch. When you make a fix compared to master, you can safely merge that change in your own master. When I or one of the other developers then merges a pull request from one of your branches into hollie/master, then this will not show as a different commit to you when you merge hollie/master with your master to keep it up to date. As long as you create separate branches for separate fixes, all should be fine. Best regards, |
get_first_empty_address should return 0 if no address can be fount.
The sub add_link expects get_first_empty_address to return 0 if no empty address is found.
This will prevent trying to add an aldb record to the FFFFFFFFFFFFFFF8 address which clearly doesn't exist. Instead the user will now get a nice error advising them to scan the link table before trying to sync links.