Software tasks to do after merging our branches (Done)

[PatrickW]

Hamish mentioned that he hadn't got his head around what I last said in this thread. I sent him some pseudocode by email in the hope of better-explaining myself. Re-reading this thread to remind myself what we've agreed, I realise I should probably post the pseudocode here.

(Syntax probably definitely not exactly Python.)

Code: Select all

# Control logic for some Pi
# This stays the same for all the usage examples below
somepi_control_logic():
    something
    something
    something
    if logictools.get_reading(site_ID,sensor_ID) is big:
        do something
    if logictools.get_reading(site_ID,sensor_ID) is alarming:
        do something else
    something something
    blah blah etc

Code: Select all

# Use it like this, maybe:

logictools.get_reading = DatabaseConnection.get_reading()

somepi_control_logic()
# logic uses DatabaseConnection.get_reading() to get readings

Code: Select all

# Or like this:

# A vastly oversimplified example function
get_reading_from_monitor(site_ID, sensor_ID):
    # The point of this example function is to show how we would adapt
    # from a source of readings that doesn't let you ask for a
    # specific reading into one that does.

    # Using this function means that neither the source of readings
    # nor the control logic has to bend to the other's will. This
    # means they can go on a date together without committing to
    # getting married and staying together for the rest of their
    # lives. They are loosely coupled. <3

    these words represent code that does whatever is necessary to
    update the logictools.readings dictionary so that it contains the
    latest readings from our source of readings

    # Return only the reading we got asked for
    # The rest of the readings will stick around for the next call of
    # the function
    return logictools.readings[site_ID, sensor_ID]

logictools.get_reading = get_reading_from_monitor()

somepi_control_logic()
# logic uses get_reading_from_monitor() to get readings

Code: Select all

# Or, how about:

# Maybe for some reason we need to get all the database readings at
# the start of the logic rather than throughout it.
somepi_gather_readings():
    ids = some list of IDs

    for each site, sensor in ids:
                logictools.readings[site, sensor] = \
                   DatabaseConnection.get_reading(site, sensor)


get_gathered_reading(site_ID, sensor_ID):
        return logictools.readings[site_ID, sensor_ID]

logictools.get_reading = get_gathered_reading()

# gather readings before running logic
somepi_gather_readings()
somepi_control_logic()
# logic uses get_gathered_reading() to get gathered readings

[hamishmb]

Unfortunately I seem to have misplaced your email Patrick, and somehow I can't find it. I think the psuedocode posting together with your previous post is enough though.

This makes a lot more sense to me, and I'm onboard with this idea. Do you have a logictools.py already in your branch, or should I make one? This might be another thing to do after The Dreaded Merge (TM) if you already have an equivalent file.

[PatrickW]

I don't currently have a Tools/logictools.py. I do have a Tools/statetools.py, though, and I was pondering whether to turn that into Tools/logictools.py or keep it separate.

This is the statetools module, which contains abstract classes
for implementing The State Pattern in control logic, initially
written for the Sump Pi control logic but intended to be useful
for other control logic too.

My own instinct is to keep it separate. It is certainly the easiest option and makes merging easier (both now and as a general principle), and the two files will contain logically distinct things. The only reason I thought they might need to be combined into just logictools.py is because I've developed an assumption that perhaps fewer, longer modules are preferred in this project.

I deferred making a decision, since it makes little difference until something that would go in the combined file actually gets written.

I haven't written any (non-pseudo) code that references logictools. It was only an example name.

If statetools and logictools are to be kept separate, and you can think of a more specific name than 'logictools', then that might be a better name, since "logictools" might imply it contains all of the logic-related tools (which it won't if it isn't combined with statetools).

[hamishmb]

Hmm, I can't think of a more specific name. Any ideas?

[PatrickW]

I couldn't think of any before, but how about generallogictools, misclogictools, corelogictools, mainlogictools, logicmisctools, logiccoretools, logicmaintools, to imply that it contains specifically those logic tools that are not found in a more specific module?

Of those, I think I like logiccoretools and logicmaintools the best.

Previously I was trying to think of names that implied it is meant to contain tools that support dependency injection into the logic and decoupling of the logic, but that seemed to be a dead end, because I found it hard to think of names that were neither ridiculously long nor of ambiguous meaning: generalisedlogictools, logicdecouplingtools, logicdependencytools, logicdependencydecouplingtools, logicinterfacetools, logicinterfacingtools etc.

Of those, I think I like logicinterfacetools the best.

I suppose the length of the module name is not hugely critical, since it can always be imported 'as' a shorter name, so that the logic does not have to constantly reference veryverboselynamedlogicdependencydecouplingtools.useful_function(), but it's nice to keep it short if we can.

[hamishmb]

I think I prefer logiccoretools if that's okay with you - it's concise and to the point.

[PatrickW]

Let's go with that then.

[hamishmb]

Okay, I have created Tools/logiccoretools.py in the use-database branch, and it contains the following interface functions:

• get_latest_reading
• get_n_latest_readings
• get_state
• attempt_to_control
• release_control
• log_event
• update_status
• store_reading

These all have the same signatures as the equivalents in coretools.DatabaseConnection.

No pressure at all, but where are you with your code now? I think it'd be easier for me to know how this is all going to mesh together if I could have a look at some of it.

[PatrickW]

I've had a bad time getting anything done this last couple of weeks. Last time I looked at my code, I was working out the best way to write the unit tests for it.

As far as I know, the logic is "done" (except for these changes to the way it will get readings), and it appears to function correctly in a VM, but I can't be sure until I have fully tested it.

I have not written a logic set-up function. (That should be fairly simple. It just needs to instantiate an object in the right place, then the logic function itself needs to be changed to use that one instance rather than creating a new one every time.)

I have not altered main.py to look in the config for a logic set-up function and run it. I think that might have to happen after the merge? Not sure.

I have not taken the Stage Pi logic out of coretools.py and into stagepilogic.py. I think it will probably simplify things if I do that before the merge.

I have not converted the logic to use these new interface functions. Do you envisage doing that before or after the merge?

I could push my branch onto GitLab. I would like to squash my commits though, because I started out using one email address and then decided I would rather not publish that address in a git repository and changed it to a different one, so I need to make sure that some of my earlier commits are not published. I'm a little bit unsteady on my feet when it comes to using git in a non-local manner, though, since I've not had much practice. (Can you advise me?)

[hamishmb]

I've had a bad time getting anything done this last couple of weeks. Last time I looked at my code, I was working out the best way to write the unit tests for it.

I understand, I've been the same. No pressure intended

As far as I know, the logic is "done" (except for these changes to the way it will get readings), and it appears to function correctly in a VM, but I can't be sure until I have fully tested it.

That's great! I'm nearly done with my stuff as well now, and the VPN server is almost ready to use as well, so perhaps this will all happen at the same time.

I have not altered main.py to look in the config for a logic set-up function and run it. I think that might have to happen after the merge? Not sure.

Yeah, there's a lot of stuff that I'll need to merge manually in config.py, so I'd much rather have any further changes done post-merge if that's okay with you. Shall I add it to the list?

I have not taken the Stage Pi logic out of coretools.py and into stagepilogic.py. I think it will probably simplify things if I do that before the merge.

Agreed.

I have not converted the logic to use these new interface functions. Do you envisage doing that before or after the merge?

It doesn't particularly matter to me. It also depends on the order that we merge things, but I'm going to make a new forum topic for that. You and Terry and I may need to have a call to discuss that - I have a feeling it'll be difficult to have that discussion on here.

I could push my branch onto GitLab. I would like to squash my commits though, because I started out using one email address and then decided I would rather not publish that address in a git repository and changed it to a different one, so I need to make sure that some of my earlier commits are not published. I'm a little bit unsteady on my feet when it comes to using git in a non-local manner, though, since I've not had much practice. (Can you advise me?)

Ah I see, that makes sense. I haven't got much experience squashing commits together, but we'll need to do that when we merge I guess, so I'll do some research. I usually work online - I worry that if I only have a local copy I'll somehow wind up losing it Supposedly pushing to a separate GitLab branch will be as simple as:

Code: Select all

git remote add origin [email protected]:wmtprojectsteam/rivercontrolsystem.git (if you haven't already done this)
git push origin <your-branch-name>

And then the new branch will appear online.

After this, new commits can be added with a simple:

Code: Select all

git push origin <your-branch-name>