I just saw Trevor's pull request for MCRedrawUnlockScreen(), and that's against the develop branch. Should I be issuing pull requests against develop and just assume they'll be merged into refactor? That would solve my problem if so, but I just assumed from the earlier discussion here that it wasn't a good idea to issue PRs against develop.

@mwieder: Well Trevor's is a bug-fix for a regression introduced in 6.7 which is why it's against develop.

Your pull request is for a new feature, and as we at RC in both 6.7 and 7.0 we generally try and avoid adding features during this phase (as we want to get to stable as soon as possible). So ideally, all new feature's should be done against 'refactor' with a view to them being merged in for a '7.1' after 7.0 goes GM (6.7 and 7.0 will GM at the same time).

I had intended to re-review your one for ceiling and floor as well as @monte's (he submitted one for metadata of image property) this week to see if it would be okay to slide them into 6.7 at this stage (it does depend on how long the RC period still has to run). Doing this does have a time impact on merging into 7.0 since this has changed how execution, syntax and property definition works to a good degree. Our time has been a bit stretched this week with getting iOS 8 support working so I haven't had a chance to do this, however.

Anyway, we'll be reviewing where we are with the RC's early next week, so perhaps hang-fire for the moment and I'll let you know - if we have a small amount of 'spare' engineering time to allow this then I'd prefer to see them in sooner rather than later.

EDIT: I should perhaps say that we are in a bit of a 'grey' area at the moment insomuch as refactor (7.0) is significantly different from develop (6.7) - things will become a great deal clearer after 7.0 goes gm because 'develop' will then be the new architecture we've introduced (i.e. 'refactor' gets merged into 'develop').

Thanks - I don't think the floor() and ceil() additions are at all urgent.
My concern is just that I can't compile the refactor branch, or rather can't generate the prebuilt artifacts, but I *can* compile the develop branch. For my pull request here, I think it would be better to go against the refactor branch, since I know Ali has done some similar refactoring work on the math classes, and it would be nice not to have two different approaches to subclassing for the two branches.
I seems to be at a standstill, but I've got other things to fill my time right now until this can get resolved, so no worries.

It's getting to the point where I think I'm the only one who attempts to build off different branches. To wit:

I can build off the master branch.
I can build off the refactor branch.
But not both. I have to have two separate repositories to do this.

Switching to the develop branch from the master branch and building results in
./src/core/Sk64.cpp:1:0: error: CPU you selected does not support x86-64 instruction set

After the 30 September submodule tweak to the prebuilt submodule ("update prebuilt submodule pointer"), attempting to switch from master to refactor results in
error: The following untracked working tree files would be overwritten by checkout:
<followed by a list of many prebuilt files>
I'm not sure this is much of a step forward from the previous situation, where attempting to checkout refactor gave
warning: unable to rmdir prebuilt: Directory not empty

Right.
Now I could use some guidance as to where to submit pull requests.
It seems that the refactor branch is no longer the LC7 main trunk. Nothing much has happened there lately and the release-7.0 and release-7.0.1 branches are getting new love from many different branches.

Previously, the master branch was being used to build the 6.6 series, the develop branch was for ongoing work on the 6.7 series, and the refactor branch was for the 7.x series.

I see lots of notifications about new features and bugfixes, but I pulled the refactor branch for the first time in a week and there's nothing new there.

So what branch should new branches be based on, and where should pull requests be issued against?
I also asked this question last week on the develop list but got not answer.

We're currently in the middle of re-jigging our git branches and haven't quite finalised the scheme yet. I'll follow up to this post with details of how we're managing things once we know ourselves... one thing that we're (fairly) certain of is that "refactor" will no longer exist - it has served its purpose and is no longer required.

We'll be posting (and updating) docs related to our branch policy over the next few days. However, essentially we have now restructured the main LiveCode repo (submodules still to do) in the following way:

'master' has gone, being replaced by 'master-6.7' and 'master-7.0'. The latter two branches track stable point releases of those two major versions.

'develop-6.7' and 'develop-7.0' have been added. These two branches are the frontier of development for maintenance releases for these two major versions.

'develop' is, as it always was, the frontier of development for the next major version.

If you want to add a feature, it should be done against 'develop' (unless there is a case for, and it has been agreed that, it should be back-ported to an existing major version).

If you want to fix a bug that has been introduced in 'develop', it should be done against 'develop'.

If you want to fix a bug that is present in 6.7, it should be done against 'develop-6.7'.

If you want to fix a bug that is present in 7.0 but not in 6.7, it should be done against 'develop-7.0'.

The main reason for these changes is to make it easier to maintain more than one existing major versions through the point release updates we have been doing; and so we can move to a merge-early-and-often strategy with pull requests. i.e. We'll merge into the relevant develop branches as soon as they have been reviewed, rather than bunching them up at the points we do a 'dp' or 'rc'.

PS: Apologies for any pull requests that were inadvertently closed - that was github being 'clever', and wasn't intentional. Please resubmit any relevant ones against the appropriate branch outlined above.

still trying to get the develop branch to compile.
valgrind is now on the list of prerequisites.
Not a big problem, but it's something new that was added.
So after apt-getting valgrind in the mix I end up with

In file included from ./src/cairo-analysis-surface.c:37:0:
./src/cairoint.h:2827:22: fatal error: memcheck.h: No such file or directory
#include <memcheck.h>

...so I see that memcheck.h is at
~/livecode/thirdparty/headers/linux/include/valgrind/memcheck.h
/usr/include/valgrind/memcheck.h

but neither of those is in my include search path.

So I bit the bullet and cloned yet again a new local git repository from runrev/livecode.
And ran a make all.

Now, I have memcheck.h in two places:
livecode/thirdparty/headers/linux/include/valgrind/memcheck.h
/usr/include/valgrind/memcheck.h

so I added headers/linux/include/valgrind to rules/common.linux.makefile and I can compile again.
I'll submit a pull request for this, but I don't see how this ever compiled without it. Do the build machines just have this in the path by default?

still trying to get the develop branch to compile.
valgrind is now on the list of prerequisites.
Not a big problem, but it's something new that was added.
So after apt-getting valgrind in the mix I end up with

valgrind is *not* a prerequisite of develop. develop should compile without having valgrind installed, even in debug mode. If it doesn't, please file a bug.

I have no idea why cairo thinks that it should be able to use the memcheck headers if they're not even on its search path. Is there a option that can be passed to its configure script to turn it off?

If you uninstall valgrind and try compiling, do things start working again?