Squirrel

Thanks.

I merged your changes into trunk.
The largest change between your branch and the merged trunk is
the unified implementation of function call handlers for GCC_INLINE_WORKAROUND.
Please test https://sqplus.svn.sourceforge.net/svnroot/sqplus/trunk .

Regards,
K. Kawachi

I ran SVN trunc for my project and had one problem, in SqPlusConst.h. Submitted fix to SVN for that.

Good change with moving Push/Get/Match protos inside a separate header.

I've added a new feature to SqPlus, the ability to embed a global function as an 'adaptor' to a member function. In essence, it's a global function, but SqPlus injects 'this' as a first argument to the function.

I use it to adapt the signature of member functions, when I cannot edit the classes directly to do that.

The test suite has a new member test_GlobalAsMember.cpp that illustrates the idea.

I submit this as an update to trunk. It shouldn't break anything. Tests work fine for me.

I noticed in the Dispatch functions, there is a bit of shared code, specially inside #ifdef SQ_USE_CLASS_INHERITANCE. I didn't do anything about it.

I also noted that the new file test_MemberVariableTypes.cpp is not yet in SVN.

Regards
// ATS

Thanks for your comments and contributions.

> The test suite has a new member test_GlobalAsMember.cpp that illustrates the idea.

Please add it to trunk!

> I noticed in the Dispatch functions, there is a bit of shared code, specially
> inside #ifdef SQ_USE_CLASS_INHERITANCE. I didn't do anything about it.

Would you point where it is?  I suppose I did something wrong when I merged
your branch and m0pey's smart pointer codes on trunk...

> test_MemberVariableTypes.cpp is not yet in SVN.

Commited.

Regards,
K. Kawachi

I thought I did all the commits yesterday, but obviously missed the last bit.

Anyway, added test_GlobalAsMember.cpp and updated sqplus.h now.

In class DirectCallInstanceMemberFunction, DirectCallInstanceGlobalFunction and DirectCallInstanceMemberFunctionVarArgs there is a chunk that repeats itself the same way (around line 1400).

That's all.

Thanks
// Arne S.

> Anyway, added test_GlobalAsMember.cpp and updated sqplus.h now.

Great.  I added the test to Makefile and vcproj.

> In class DirectCallInstanceMemberFunction, DirectCallInstanceGlobalFunction
> and DirectCallInstanceMemberFunctionVarArgs

I see.
I will make a new snapshot from trunk after fixing up the repetition.

Thanks again for your numerous contributions.

K. Kawachi

One more update:

I came on this while enabling several VM:s in my project.

The whole design around SquirrelVM and SquirrelObject is a bit dubious.

For example, in CreateNativeClassInstance we pass a SQVM as an arg. It's the one we're operating on. Then, from the same function, SquirrelObject queries SquirrelVM for a SQVM pointer (before PopulateAncestry).  And, it can very well be a different SQVM pointer. Unsafe.

So I did a small fix there and commited.

I also updated SquirrelVM a bit. It wants to keep a SquirrelObject around holding a pointer to the root table. When switching between two VM:s it had to re-create this SquirrelObject, even if not used. Changed so that it's only created on demand. But (IMHO) it's not a good design.

It would probably be safe to give SquirrelObject a pointer to the current VM in the constructor (or NULL if use the default one).

I expect the same problem will popup in more places, but I'll wait for that.

Enough mumbling... OK for now.

Regards
// ATS

Great.

So may I make a branch for you VMs code (trunk:r109) ?
I'd like to make a snapshot release of sqplus from trunk:r107 first.

I suppose handling multiple VMs is one of the biggest issues of sqplus.
There were some posts for this problem in the forum, and they were
not merged yet.  Though I don't know why, the problem must be
much harder than I think.  I believe your work on trunk will be the clue
for this difficulty.

Regards,
K.Kawachi

Go ahead with the branch, no problem for me.

Handling several VM:s, I don't think it's so difficult. Squirrel is well prepared for it (although I had some trouble setting it up until the brain clicked). There could be a bit backward compatibility to think about here.

Getting it right in SqPlus is a bit more work, but there's nothing impossible about it. It's good to do as a separate step.

OK
// ATS.

Hi

I've made a branch named branches/arst-severalVMs, and
the snapshot of trunk is released as SQUIRREL2_1_1_sqplus_snapshot_20070927.

As for multiple VMs, I misunderstood the problem.  You're right.
I didn't distinguish switching several VMs from managing concurrent (multithreaded) VMs.
There had been a patched version of sqplus for multithreading, but
I can't find the page now.

Regards,
K. Kawachi

Squirrel VM objects: http://www.tactile3d.com/bucket/squirrel/squirrel.php

Thank you!

Hi,
I'm trying to merge your severalVMs branch into trunk.

One question:

> I also updated SquirrelVM a bit. It wants to keep a SquirrelObject around
> holding a pointer to the root table. When switching between two VM:s it had
> to re-create this SquirrelObject, even if not used. Changed so that it's only
> created on demand. But (IMHO) it's not a good design.

Does this problem still occur if GetVMSys() and SetVMSys() are used
to alter VMs?

I guess SquirrelVM::SetVMSys(s) and SquirrelVM::Init(v) (v != NULL)
do similar things in different ways.  As you pointed out, the latter in trunk
has some problems.

K. Kawachi

Hello,

For class SquirrelVM, the sitiation is a bit unclear. Since it has static variables, it's mostly a placeholder for a SQVM pointer (preferably the one being run currently).

I can see compelling reasons to put all sorts of functionality and convenience into it, but, it becomes burdensome when used in slightly other ways than the author did.

I think that creating VM:s automatically, starting to initialize libraries, well in general users of probably SqPlus will prefer to control that sort of thing themselves.

When swapping between VM:s and SquirrelVM itself has created a VM, then who has the ownership for the VM being swapped out? Maybe better to do an assert(v!=NULL) in SquirrelVM::Init.

When it comes to SetVMSys, are some issues:
1 - A VM already always has a root table associated with it internally. Passing it around as a separate object leaves questions open. Who owns the object?
2 - In SetVMSys, the current state is just being overwritten, with no release or consideration for what was there before.

We come in the situation where _root is sometimes created by SquirrelVM and sometimes externally.


I think it's best to know what SquirrelVM is supposed to do and not try to pack all sorts of 'possibly convenient' things in there.

IMHO it's best to drop SquirrelVMSys. Internally one can create a SquirrelObject representing the root, if this gives performance improvement, but the it must be properly deleted whenever the VM is swapped out of context.

Maybe best to check if someone is really dependent on SquirrelVMSys?


BTW: I could complete a rewrite along these lines. However, if you've nearly done it I shouldn't. And, it's probably best to have some test cases for VM swapping also.

For the other big change - Unicode(char/wchar_t), I'm almost ready to commit now.

Regards
// ATS.

Thank you for your desciption.
I agree with you on the point that there are some issues in SquirrelVM
when we control VMs and root tables externally.

Because I implicitly assume that SqPlus users will not do such external
operation on VMs and root tables, so I suppose the function SquirrelVM::Init(v)
should be changed to SquirrelVM::Init(void).

Your solution (dropping SquirrelVMSys) is also logically consistent, but
I think this is the design issue of SqPlus.
I'd like to wait for comments from John Schults.

Regards,
K. Kawachi

P.S. Actually I do nothing on the branch of several VMs except for making a
small test named test_MultipleVMS.cpp.  As for Unicode, please commit your
modifications.

Hi.

I guess I'm actually asking to ats who seems to have solved some problems similar to mine.

In fact, I recently upgraded my Ubuntu to the latest and my project using Ogre and Squirrel with SqPlus didn't compile anymore. Checking the website I saw the new version and downloaded it. I had a bunch of problems related to undefined references when linking ; my gcc reports version "gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
" so I thought the inline workaround should do it. It seems to help but doesn't seem to be enough.

[EDIT]
Just to inform you that I just tested the latest SVN version and the same problem arises.
[/EDIT]

In my projetc, I modified the following defines from their default value: SQPLUS_CONST_OPT, SQPLUS_SUPPORT_STD_STRING and GCC_INLINE_WORKAROUND. The version of Squirrel/SqPlus is SQUIRREL2_1_1_sqplus_snapshot_20071014.

The last problem reported by the linker:
game.so: undefined reference to `void SqPlus::Push<Ogre::Quaternion const>(SQVM*, Ogre::Quaternion const&)'
game.so: undefined reference to `void SqPlus::Push<Ogre::Vector3 const>(SQVM*, Ogre::Vector3 const&)'
collect2: ld a retourné 1 code d'état d'exécution

They look like the errors which happened without the gcc inline workaround so I guess something is not completely right with it but I don't know what. I would guess it has to do with one of my defines (SQPLUS_CONST_OPT ?) but everything that I tried failed...

Note that I declare the Ogre classes the same way I do for mine:
DECLARE_INSTANCE_TYPE_NAME(Game::Camera, Camera)
DECLARE_INSTANCE_TYPE_NAME(Ogre::Vector3, Vector3)
DECLARE_INSTANCE_TYPE_NAME(Ogre::Quaternion, Quaternion)

Any idea ?

Thanks forward,
Seb