resolveImage

[monte]

Hi Folks

I posted this to the dev list but I guess this is the spot to discuss it...

Seeing as there's no docs yet perhaps we can nut this out together. I've found a method of MCObject that I want to expose to speed up something in lcVCS. It's called resolveimage and it takes the id of an image and returns the MCImage according to the context of the MCObject it's called on.

I'm thinking I want a LiveCode function resolveImage(objectRef,imageID)

Here's what I think I need to do:
- add to enum Functions in parsedef.h

Code: Select all

	F_RESOLVE_IMAGE 

- add to LT factor_table in lextable.cpp

Code: Select all

	 {"resolveimage", TT_FUNCTION, F_RESOLVE_IMAGE},

- add to newobj.cpp

Code: Select all

	case F_RESOLVE_IMAGE:
		return new MCResolveImage;

- add to enum Parse_errors in parseerrors.h

Code: Select all

// {PE-0524} resolveImage: bad parameters
	PE_RESOLVE_IMAGE_BADPARAM,

-add to funcs.h

Code: Select all

class MCResolveImage : public MCFunction
{
	MCChunk *object;
	MCChunk *image_id;
public:
	MCResolveImage()
	{
		object = image_id  = NULL;
	}
	virtual ~ MCResolveImage();
	virtual Parse_stat parse(MCScriptPoint &, Boolean the);
	virtual Exec_stat eval(MCExecPoint &);
};

- add to funcs.cpp

Code: Select all

MCResolveImage::~ MCResolveImage()
{
	delete object;
	delete image_id;
}

Parse_stat MCResolveImage::parse(MCScriptPoint &sp, Boolean the)
{
	if (get2params(sp, & object, & image_id) != PS_NORMAL)
	{
		MCperror->add
		(PE_RESOLVE_IMAGE_BADPARAM, sp);
		return PS_ERROR;
	}
	return PS_NORMAL;
}

Exec_stat MCResolveImage::eval(MCExecPoint &ep)
{
	MCObject *optr;
	MCImage *imageptr;
	uint4 parid;
	uint4 img_id;
	MCerrorlock++;
	if (object->getobj(ep, optr, parid, True) == ES_NORMAL) {
		if (image_id->eval(ep)  == ES_NORMAL) {
			if (MCU_stoi4(ep . getsvalue(),img_id) {
				imageptr = optr ->resolveimage(nil,img_id);
				return imageptr->getprop(0, P_LONG_ID, ep, False);
			}
		}
	}
	MCerrorlock--;
	return ES_NORMAL;
}

I think that's it... probably want to throw some more errors in the eval method by am I on the right track here?

[mwieder]

Looks OK to me, but yes, more thrown errors in eval would be good. And you might want to valid object and image_id before deleting them in the destructor.
Not sure whether the MCFunction parent class throws errors.

[monte]

OK, I might give it a shot then if I can get a snow leopard machine to build LC desktop on as it requires Xcode 3.2.6... I think I need to post this to the engine list too (which seems impossible to access) is that right? It's all a bit convoluted...

Because object and image_id are initialised to NULL they can be deleted safely without checking if they are valid. Seems to be what's done elsewhere so that's why I did it that way...

[mwieder]

Glad I've hung onto my Snow Leopard machine.

I've requested access to the engine list, but haven't heard anything back. Never actually got a confirmation, so I don't know if it's something I did (or didn't do) or if it's just taking time for the team to catch their breath after the sprint.

Good point about the NULL initialization. Yes, that should take care of it.

[monte]

How did you manage to request it. Whenever I email quality@runrev.com it bounces with a message saying you can't email it and it's only for notifying us of bug status.

[mwieder]

Hmmm. Yeah, you're right. I must have been thinking about the contributors agreement. I clicked the button a couple of times, but I'm not sure if that actually did anything. But the link for the listserv seems nonfunctional.

[monte]

Had to change the eval method quite a bit but I got it to compile for iOS (still downloading Xcode 3.2.6... ) but now I'm not sure what to do... heaps of files in the build folder but none of them look much like what's in the Runtime folder...

[monte]

Am I meant to be running a script after the build to do something? What I'm doing is building and then copying the binary from standalone-mobile.app into the right runtime folder of a copy of 5.5.4. But the simulator isn't opening. Checked out master again just to make sure it wasn't resolveImage stuffing things up but seems to be the same issue there... Also my binary is nearly 2.5MB bigger than the one I'm replacing...

--

Edit... think the binary size was armv7s.. building on the command line now only for armv7 brings the file size down

[monte]

More info... It logs Startup error: then crashes on thread 6

Thread 6 Crashed:
0 libsystem_kernel.dylib 0x97dd1a6a __pthread_kill + 10
1 libsystem_c.dylib 0x98c7cacf pthread_kill + 101
2 libsystem_sim_c.dylib 0x02cfb57b abort + 140
3 Untitled 1 0x00106d35 MCIPhoneDoDidBecomeActive + 581 (mbliphonedc.mm:1304)
4 Untitled 1 0x001931f3 MCFiberDispatch + 67 (fiber.cpp:65)
5 Untitled 1 0x00193371 MCFiberOwnedThreadRoutine + 17 (fiber.cpp:125)
6 libsystem_c.dylib 0x98c7b557 _pthread_start + 344
7 libsystem_c.dylib 0x98c65cee thread_start + 34

[LCMark]

Looks like you've figured out how to add functions

Stepping back a bit there's a couple of things to consider here:

1) Are there any use-cases beyond lcVCS that make resolveImage() useful?
3) Is the usefulness of this function restricted to actions the IDE takes (e.g. for VCS integration), or are some of the use-cases applicable to standalones?
2) It seems to me that this function isn't just about images, but exposing the id/name search order the engine uses to fetch resources. It generalizes as resolveObject(target, object-type, name/id) - does this wider function have any greater use?
4) With this generalization in mind and thinking forward to non-function syntax (which is somewhat ugly) would something like this work: image id tId relative to button 3

In terms of implementation, then it looks like you have the right of it. The target object resolution should throw an error if its not found (i.e. don't use errorlock), and (as Mark said) resolveimage() can return NULL if its not found.

[LCMark]

We do need to make testing out standalone changes a bit easier - we can tweak the SB to do this (so it picks up the binaries from the _build folder within the repo, overriding My LiveCode or the IDE Runtime folder). In the meantime though a couple of things:

1) You can't use standalone engines built out of the community source tree with Commercial versions, you need to use Community.
2) The binary you need for device builds is the standalone-mobile-lib.lcext - this is a partially linked object file which is combined with externals and such and linked by the SB. [ The binary the .app bundle is an executable ].

[ Btw, the reason for the partially linked object file is that iOS apps on the device can't load shared libraries, so the only way to do externals is to link them into the built executable - thus device builds for iOS are partially linked object files for both engine and externals ].

[monte]

Thanks for the heads up... for some reason I thought I could get away without downloading community... so downloading now... It would be nice if there were a build target that would launch the IDE with a stackfile located at a certain spot. Any builds (IDE, device, simulator) would be copied in to the right spots before the launch... the stackfile could end up becoming some automated test case for the feature being developed.

As for the utility of resolveImage you might be right that it's only useful in the IDE in a VCS context and also perhaps to work out where an image is that's being used as an icon so you can easily replace the image or something or if it's not resolving the way you think it should... Actually the function could be used to good effect fixing the long standing issue with the icon picker where id conflicts end up showing the wrong image in the picker.

Would it be possible to use a pre-compiler flag rather than _internal for IDE only functions? I think that would be a cleaner solution if it's possible.

I'm not sure where you're going with object resolution because images are currently the only objects that resolve like that.... although if you look bug 1061 I've recommend that stack names resolve the same way so perhaps there could be an upgrade to the way all object references resolve.. mind you it concerns me that a spelling mistake might mean button "whatever" resolves to some object on a stack in memory that you didn't intend and you wouldn't get a runtime error... so... come to think of it I can only think of a use for a name resolver for image and stack and id resolver for image...

At the moment this is just an exercise in working out how to do it rather than why. I guess if I manage to test my code I'll eventually send a pull request and you can work out if you're interested in it... At the end of the day if we do the uuid stuff I won't even need this function for lcVCS...

[mwieder]

1) You can't use standalone engines built out of the community source tree with Commercial versions, you need to use Community.

Doh! That one bit me too.
Now that I can compile the engine I need a framework for it to run in.
I'm off to download the Community edition as well.

[monte]

I think we need a package script... surely the repo has all the required files once you've built...

[monte]

overriding My LiveCode

Ah.. I missed this part in my first reading. Can we put runtime engines in the user extensions runtime folders (like we can for externals) and they override the ones in the Tools folder? That helps. Still need an easy way to load the IDE with a specific engine for post build tests. Or even just run a stackfile on an engine after a desktop build.