resolveImage

[LCMark]

The aim is to make it so that you can build/run/debug LiveCode entirely from within the cloned repository - all the files are there to do so, its just we need to do a bit more work to make it so this works out of the box.

In the mean time, the best thing to do is to make symlinks (on Mac / Linux at least) from your My LiveCode/Runtime folder to the built components i n _build/debug/<platform>. You'll need to ensure the folder structure is the same within Runtime, and ensure the names are the same (for example, RevDb -> _build/mac/debug/revdb.bundle) but that should mean when you run the IDE it will use those resources rather than the ones inside the app bundle.

Actually running a built (IDE) engine with the IDE is easy. The IDE engine first looks at REV_TOOLS_PATH to find the path to the root folder of the IDE, then looks in the current working directory. Thus the easiest way (in Xcode) to get this to work is to modify the initial working directory of the LiveCode executable - Get Info on it and its on the first tab - set it to <repo dir>/ide. With this done, when you click Run/Debug in Xcode it will build and launch the IDE engine and load in the IDE thats inside the repository.

[LCMark]

Just reading through your previous post...

When the IDE engine starts up it looks for a stack 'home.rev' - so you can point the working dir (or set the env var REV_TOOLS_PATH) to anything containing such a stack and have that do whatever you want.

The standalone engines are similar in debug mode - they look for the stack specified by the env var TEST_STACK and run that.

My questions about resolveImage are mainly about trying to work out where the most appropriate place it is that it should go at the moment. A more generalized version could well be a generally useful feature within and without the IDE, however given its specific purpose at the moment I'd recommend it be integrated as an _internal command.

The _internal command is a pragmatic compromise. It is for specific functionality that aids the IDE in performing its function and has allowed us to hook in things we need without having to worry about future compatibility - i.e. they only have to work with the Toolset the engine ships with. It also stops any bloating of standalone engines with functionality that they would never need / use. [ After refactoring and open language, of course, the problem solves itself - this functionality gets moved into its own loadable module with nicer syntax ].

I'm not sure I understand what you mean by a 'pre-compiler' flag - I'm certainly up for changing _internal to 'ide' so you'd do something like:

Code: Select all

ide deploy ...

rather than

Code: Select all

_internal deploy

( The deploy command is the bit that builds the standalones ).

The suggestion for generalizing resolveImage results from the fact that whilst the 'resolveimage()' is specific to images, it needn't be. It encodes a specific search order relative to an object - there's no reason that it should just be able to filter for images, but could filter for any control type that you choose. Of course, whether this is useful or not is entirely down to whether there are any use-cases for it. If not, its not worth the generalization and adds further weight to the fact it should probably live in the IDE world only (as support for VCS and the IDE editing tools).

So, my suggestion would be that for now resolveImage be a part of _internal. Indeed you could make the syntax something like:

Code: Select all

_internal resolve image [ id ] <id_or_name> relative to <object>

[monte]

In the mean time, the best thing to do is to make symlinks (on Mac / Linux at least) from your My LiveCode/Runtime folder to the built components i n _build/debug/<platform>. You'll need to ensure the folder structure is the same within Runtime, and ensure the names are the same (for example, RevDb -> _build/mac/debug/revdb.bundle) but that should mean when you run the IDE it will use those resources rather than the ones inside the app bundle.

Excellent... after seeing your mention of the extensions folder I played with it... thought this was only for externals... do you think we could have a separate runtime folder for commercial and community so we can use the same extensions folder and not risk getting these things messed up... when you build apps with commercial.

Actually running a built (IDE) engine with the IDE is easy. The IDE engine first looks at REV_TOOLS_PATH to find the path to the root folder of the IDE, then looks in the current working directory. Thus the easiest way (in Xcode) to get this to work is to modify the initial working directory of the LiveCode executable - Get Info on it and its on the first tab - set it to <repo dir>/ide. With this done, when you click Run/Debug in Xcode it will build and launch the IDE engine and load in the IDE thats inside the repository.

That does sound easy... when I manage to get the desktop to build I'll give it a shot

I'm not sure I understand what you mean by a 'pre-compiler' flag

I meant a predefined macro sorry.. so you can just include this stuff as regular functions/commands that are only available in the IDE...

Code: Select all

#ifdef __IDE
    // MG-2013-4-11: [[ ResolveImage ]] New function for resolving an image id in the context of an object
    case F_RESOLVE_IMAGE:
        return new MCResolveImage;
#endif

The suggestion for generalizing resolveImage results from the fact that whilst the 'resolveimage()' is specific to images, it needn't be. It encodes a specific search order relative to an object - there's no reason that it should just be able to filter for images, but could filter for any control type that you choose. Of course, whether this is useful or not is entirely down to whether there are any use-cases for it. If not, its not worth the generalization and adds further weight to the fact it should probably live in the IDE world only (as support for VCS and the IDE editing tools).

I can't think of why we would want to find other objects this way if the engine doesn't do the same and like I said I think it could be a problem changing the engine to do the same for anything but stack names. Really I see a shot term use for this for VCS until we resolve the ID issue and a long term use for it for the icon picker... that's about it. Definitely only IDE only.

Code: Select all

_internal resolve image [ id ] <id_or_name> relative to <object>

OK, I'll look into _internal some more and see if I can work it out

[monte]

so... it looks like I add an element to the verb info:

Code: Select all

	{ "resolve", "image", class_factory<MCIdeResolveImage> },

Then add the MCIdeResolveImage class to that file which seems to parse and exec the same way as the functions.

[LCMark]

There are 'MODE_*' flags which get defined for the different types of engine (MODE_DEVELOPMENT, MODE_STANDALONE, MODE_INSTALLER), however these cannot be used for files in 'libkernel'. This is because the kernel static library must remain identical for these three engine types. Mode specific code sits in the LiveCode, standalone and installer targets.

However, '_internal' is already designed to have different namespaces for the different modes since the implementations and table are defined at the engine target level (LiveCode, standalone and installer).

In regards to parsing then the "_internal" command takes care of the 'resolve image' prefix - you just need to parse the rest of the clause. Something like:

Code: Select all

// Parse the optional 'id' token
if (t_stat == PS_NORMAL && sp . skip_token(SP_FACTOR, TT_PROPERTY, P_ID) == PS_NORMAL)
  m_is_id = true;
// Parse the id_or_name expression
if (t_stat == PS_NORMAL)
  t_stat = sp . parseexp(False, True, &m_id_or_name);
// Parse the 'relative to' tokens
if (t_stat == PS_NORMAL)
  t_stat = sp . skip_token(SP_FACTOR, TT_TO, PT_RELATIVE) == PS_NORMAL && sp . skip_token(SP_FACTOR, TT_TO, PT_TO) == PS_NORMAL;
// Parse the target object clause
if (t_stat == PS_NORMAL)
{
  m_target = new MCChunk(false);
  t_stat = m_target -> parse(sp, False);
}

[monte]

excellent, hopefully I'll send my first pull request sometime this weekend

[monte]

OK, so got it to compile after having to jump through some sdk hoops.. symlinked 10.6 then had to perform liposuction on stdlib...

Now I'm a bit stuck here. You make it sound really easy so I must be missing something.

Actually running a built (IDE) engine with the IDE is easy. The IDE engine first looks at REV_TOOLS_PATH to find the path to the root folder of the IDE, then looks in the current working directory. Thus the easiest way (in Xcode) to get this to work is to modify the initial working directory of the LiveCode executable - Get Info on it and its on the first tab - set it to <repo dir>/ide. With this done, when you click Run/Debug in Xcode it will build and launch the IDE engine and load in the IDE thats inside the repository.

I can't see any Get Info in Xcode.. maybe you are talking Xcode 3.2.6? I'm using 4.6.1. There's obviously the finder get info on the executable but that doesn't help me. There's the target info but I can't see a working directory option there.

Anyway... I can see it's trying and failing to look for _build/mac/Debug/Toolset/home.rev from the console so I've just copied the IDE files there for now... tried symlinking and it failed.

[monte]

So... Basically ready for a pull request now on this. Worked out how to set it and everything... Anyway, what kind of docs do you want as _internal stuff seems to currently be word of mouth... Probably should all be documented in some kind of IDE developer document now I guess.

[monte]

I came up with another use case for this too. I'm guessing the standalone builder still searches for images to include from the image libraries???

For the icon picker I think the way to use it is to check that the image your trying to reference will be displayed correctly in context and if not then you need to copy the image rather than set the icon.

If you accept the pull request do I then submit enhancement requests for tr IDE team?

[monte]

OK, pull request sent

[LCMark]

Cool - thanks Monte. I'll probably not get around to looking at it this weekend, but will hopefully be able to on Monday

[mwieder]

If you accept the pull request do I then submit enhancement requests for tr IDE team?

I see the IDE Contributors forum is still locked. That makes coordinating engine pull requests and corresponding IDE enhancement requests a bit difficult.

[monte]

I see the IDE Contributors forum is still locked. That makes coordinating engine pull requests and corresponding IDE enhancement requests a bit difficult.

It does. I was going to submit via bugzilla because I think that's the only sane way to deal with the IDE until they decide to give lcVCS a shot

[LCMark]

The IDE contributors forum is locked because the open-source LiveCode IDE project isn't up and running yet; and we aren't accepting pull requests to the IDE components at the moment (due to problems with integration due to lack of VCS...).

Submitting enhancement requests is the way to go - indeed, bugs and enhancements should be submitted for all work that is going to result in branches that might be merged in. We're are going to use the associated numbers as the branch names and so we can track what's going on.

[monte]

indeed, bugs and enhancements should be submitted for all work that is going to result in branches that might be merged in

Hmm... so if we want to implement a feature we need to submit an enhancement request, talk about it here, talk about it on the engine mailing list, implement it then talk about it on github??? seems a bit fragmented...