Can plugins add libraries to unix vm?

On 28-Dec-05, at 6:53 PM, Andreas Raab wrote:

> I say, let's kick the macro then and give that function a proper  
> prototype. The way it is right now is really not all that useful.
Sigh. It seems it isn't as simple as one would like here. It's -  
again - OSX causing trouble with its demented approach to aliases.  
Apparently we need to be able to specify whether the aliases  
potentially in the filepath get resolved or not; when opening a file  
we do, for renaming or deleting we don't. So far as I can tell only  
OSX has to do this but it means that any code hoping to work across  
platforms has to know when to do 'filenameMungerWithOpen'  as opposed  
to plain 'filenameMunger' if it hopes to run properly on OSX.

Right now all I can think of is either
a) making a a proxy function with 4 args - say  
ioFilenamefromStringofLengthresolveAlias(char* cBuffer,  
char*filename, sqInt fnSize, sqInt resolveFlag) - and two macros
b) or two proxy calls - ioFilenamefromStringofLength &  
ioFilenameOpenfromStringofLength

Ugly! Ugly! Clearer thoughts needed!

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: L: Lie!

On Thu, Dec 29, 2005 at 01:00:05PM -0800, Andreas Raab wrote:
Thanks,

I have not changed compilers, so that's probably not it. But I have
seen this kind of symptom before, so I might just be making some dumb
mistake.  I'll report back when I figure it out.

Dave

I vote for a) - I doubt anybody would ever bother to remember that there
are two variants (I sure wouldn't ;-) And there might be reasons to
request alias resolution for other purposes too.

Cheers,
   - Andreas

tim Rowledge wrote:

On 29-Dec-05, at 1:37 PM, Andreas Raab wrote:

> I vote for a) - I doubt anybody would ever bother to remember that  
> there are two variants (I sure wouldn't ;-) And there might be  
> reasons to request alias resolution for other purposes too.

Problem is that you *have* to remember there are two variants in any  
hopefully-portable code. Stupid, eh? Actually if we had the 4-arg  
function it would serve as a constant reminder of that so perhaps  
doing that and no reality-hiding-convenience macros would be best.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
People who deal with bits should expect to get bitten.

On Thu, Dec 29, 2005 at 12:55:03PM -0800, tim Rowledge wrote:
According to the comment in sqMemoryAccess.h:

#ifdef INLINING_WORKS_FOR_SMALL_ACCESSORS
/* use these if static inline produces efficient code for such small accessor
 * functions. It doesn't on RISC OS and OSX as of may 2005 */

So the macros are there to accomodate the RiscOS and OSX compilers.
But for some reason, configure ends up telling my Linux system to use
the macros, even though it does not need to do so. The missing macros
are apparently used only in the vm-display-X11 module, which of course
is not needed for RiscOS but I suppose might be of interest on OSX.

In any case, I get the same results whether using the macros or the
inline functions.

Dave

If you compile for unix on any PowerPC based platform or RISC  you  
*will* need the INLINING_WORKS_FOR_SMALL_ACCESSORS logic on or off,  
which ever. The wrong
choice will cause the some versions of the GCC compiler to generate  
most interesting confused PowerPC and RISC code leading to abysmal VM  
performance.

The macros are used throughout the interp.c when using the 32bit/
64bit vmmaker.


On 29-Dec-05, at 2:22 PM, David T. Lewis wrote:

--
========================================================================
===
John M. McIntosh <[hidden email]> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
========================================================================
===

On Thu, Dec 29, 2005 at 12:55:03PM -0800, tim Rowledge wrote:
Well, there was not much you could have done to help me short of
offering a brain transplant. I just had my plugin path screwed
up and was accidentally loading a 32 bit display module with a
64 bit VM. Sorry about that.

So, back to the matter at hand. I've tested the new VMM with no
problems on:

- 32 bit Intel, Linux, 32 bit VM
- 32 bit Intel, Linux, 64 bit VM
- 64 bit AMD Turion, 64 bit Linux, 64 bit VM
- 64 bit AMD Turion, 64 bit Linux, 32 bit VM

The tests were done with VMMaker-tpr.39, SVN 1282, and the patches
that I attached to my earlier message.

I did spot one issue that I had not previously noticed. With the
combination of 64 bit machine and 32 bit VM, the memory access
inline functions in sqMemoryAccess.h work fine, but the macros
do not work. This is not related to my patch for sqMemoryAccess.h,
since I tried building with the original version and running with
no display, and still fail in a longAtput() macro.

Dave

On 30-Dec-05, at 9:59 AM, David T. Lewis wrote:
>
> Well, there was not much you could have done to help me short of
> offering a brain transplant.
Well, I know a guy who knows a guy... Good news. I'll soon release some new code to break all that ;-)

>
> I did spot one issue that I had not previously noticed. With the
> combination of 64 bit machine and 32 bit VM, the memory access
> inline functions in sqMemoryAccess.h work fine, but the macros
> do not work. This is not related to my patch for sqMemoryAccess.h,
> since I tried building with the original version and running with
> no display, and still fail in a longAtput() macro.
I don't feel very surprised about that to be honest. With no 64 bit  
machine to test on and no very strong interest in messing with it it  
would be very plausible that I didn't write them adequately for a  
real 64bit machine. The possibility of the 'baseOffset' coming into  
play leaps to my currently addled brain for example.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Dreams are free, but you get soaked on the connect time.

Hokay,
After taking Andreas' suggestion to dump the tacky old  
sqFilenameFromString macro to heart, SM has a new release 11 -  
3.8b5-64B and SVN has level 1284 for you to play with. Read the SM  
page comments.  It may well break things but I think it gets the  
basic facility cleaner. I also cleaned out some ugly arg-typing  
floobs while I was at it.

Note that it looks to me as if AsynchFilePlugin and DeflatePlugin  
could do with some looking at wrt 64bit cleanliness.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Last one out, turn off the computer!

On Fri, Dec 30, 2005 at 05:14:06PM -0800, tim Rowledge wrote:
> Hokay,
> After taking Andreas' suggestion to dump the tacky old  
> sqFilenameFromString macro to heart, SM has a new release 11 -  
> 3.8b5-64B and SVN has level 1284 for you to play with. Read the SM  
> page comments.  It may well break things but I think it gets the  
> basic facility cleaner. I also cleaned out some ugly arg-typing  
> floobs while I was at it.

There is a cut'n'paste typo in one of the arg-type defloobifications,
fix attached.

I've built a unix VM from the new VMM/svn sources, but I'm
getting problems opening the sources and changes files.
Something has changed that affects the operation of
"FileDirectory default oldFileNamed: 'squeak.changes'".
I'm getting a nil from that, while "FileStream oldFileNamed: 'squeak.changes'"
still works as expected.

I have not spotted the source of the problem yet...

Dave

On 2-Jan-06, at 9:16 AM, David T. Lewis wrote:
Ta. Mpeg3Plugin is one I don't/can't compile anyway so it doesn't get  
checked in a ny way but visual inspection at my end.
RISC OS uses its own equivalent ofthe Cross/plugins/FilePlugin/
sqFilePluginBasicPrims.c and so again it doesn't get used by my  
system. Most likely another typo since I didn't make any structural  
changes.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: FA: Failsafe Armed

On Mon, Jan 02, 2006 at 12:16:58PM -0500, David T. Lewis wrote:
>
> I've built a unix VM from the new VMM/svn sources, but I'm
> getting problems opening the sources and changes files.
> Something has changed that affects the operation of
> "FileDirectory default oldFileNamed: 'squeak.changes'".
> I'm getting a nil from that, while "FileStream oldFileNamed: 'squeak.changes'"
> still works as expected.

Sorry, FileDirectory>>oldFileNamed: is fine, I must have
mistyped something. I'm not sure what is causing the problem
opening the sources and changes files. I'll report back when
I find it (but maybe not today).

Dave

There was a bit of discussion about removing the caching of the  
filesize from the file prims last week. I see Andreas has checked in  
a win32 file package that made the change and John & I were just  
discussing it as well. The bit that has always puzzled me is why it  
was there in the first place and I think I know the answer now. The  
original basic file access code was written to use only the ansi C  
lib calls and that doesn't inclide a file size function. You *can* do  
an fseek to EOF and an ftell when you get there, which is pretty much  
what is done. Once you step outside the ansilib room you can just  
find the actual file size and drop the caching.

We could of course change the Cross/plugins/FilePlugin file to be  
posix 'portable' and allow an fstat call to replace the caching. Or  
we could make a 'getFileSize()' that has to be platform supplied just  
like all the directory calls. Or we could leave the Cross file and  
note that just about any non-trivial-embedded/experimental platform  
will likely benefit from a more specific file access code and see the  
various examples in the svn tree. Unix and Mac would then need to  
implement such, presumably as posix calls.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BA: Branch Approximate

On Mon, Jan 02, 2006 at 09:41:55AM -0800, tim Rowledge wrote:
Mea culpa. The sqGetFileNameFromString() function needs to null-terminate
the file name string after copying it, and I had not done that.

The new VMM/SVN works fine on Intel 32 bit Linux for both a 32 bit
and 64 bit VM. I'll check AMD-64 when I get a chance, but I don't
think there will be any problems there.

The sqGetFileNameFromString() function I used is just this:

sqInt sqGetFilenameFromString(char *aCharBuffer, char *aFilenameString, sqInt filenameLength, sqInt aBoolean)
{
  strncpy(aCharBuffer, aFilenameString, filenameLength);
  aCharBuffer[filenameLength] = 0;
}

BTW, the Mpeg3Plugin is working fine on 32 bit Linux, so the rest
of the cut'n'pasting must have been OK.

Dave

On 2-Jan-06, at 3:23 PM, David T. Lewis wrote:
>
> Mea culpa. The sqGetFileNameFromString() function needs to null-
> terminate
> the file name string after copying it, and I had not done that.
>
That would cause interesting problems, certainly.
I think Ian had some quite extensive charset converting code attached  
to the old macro? Ah, yes see sqUnixCharConv.c RISC OS uses the OS  
call to canonicalize the path  and make sure it is fully qualified.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LB: connect Line-voltage to BITNET

On Mon, Jan 02, 2006 at 04:38:54PM -0800, tim Rowledge wrote:
I built VMs on AMD 64, no problems. All looks well for:

Intel 32 bit Linux 32 bit VM
Intel 32 bit Linux 64 bit VM
AMD 64 bit Linux 32 bit VM
AMD 64 bit Linux 64 bit VM

The previously mentioned patches still apply, including requirement
for inlined memory access functions rather than macros for 32 bit
VM on 64 bit AMD Linux.



I'll have a look. Should have no effect on the VMM release, which
looks fine as near as I can tell.

Dave

On 29-Dec-05, at 12:00 PM, David T. Lewis wrote:
>
> Attachments (in zip file):
>
> platforms-win32-plugins-FilePlugin-sqWin32FilePrims.c.diff - Change  
> Win32
>     FilePlugin to use session ID from the interpreter rather than  
> generate its
>     own value (for consistency, and also so as not to break OSPP  
> for Win32).
OK, that is up to andreas - I couldn't commit it if I wanted to.
>
> platforms-Cross-vm-sqMemoryAccess.h.diff - Add missing memory  
> access macros
>     (the inline functions are complete, but some of the  
> corresponding macros
>     are missing).
OK, made the changes. Am I hallucinating or should we really make the
#define oopForPointer(ptr) ((sqInt)(ptr))
read
#define oopForPointer(ptr) ((sqInt)(ptr-sqMemoryBase))
instead?


>
> platforms-unix-vm-sqUnixExternalPrims.c.diff - Provide meaningful  
> console
>     error message if an external module (e.g. vm-display-X11) fails  
> to load.
That's one for Ian. Well, maybe it should.  I suppose if it is used by two or more  
platforms it makes a reasonable candidate for Cross. It is another  
posixy rather than ansi-ish file though.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Never write software that anthropomorphizes the machine. They hate that.

tim Rowledge wrote:
Now that's interesting. I can fix that easy enough but I'm curious as to
the reason for having a "global" session ID instead of a local one. I
always found it advantageous that (in all likelyhood) you couldn't use
the session ID for a file interchangeably with the session ID of a
socket. And I must say that I find the idea of exposing what essentially
amounts to a "VM secret" to other plugins quite peculiar.

Can somebody remind what the intent of that change was? I'm sure there
must've been some reason for it but I think I've missed the discussion
of that feature.

Cheers,
   - Andreas

On Tue, Jan 03, 2006 at 01:34:35PM -0800, tim Rowledge wrote:
Looks like another of those annoying cut-n-paste errors.  Apparently
that particular macro has not not been getting a lot of heavy use.

Dave

On Tue, Jan 03, 2006 at 02:21:29PM -0800, Andreas Raab wrote:
There are are probably lots of reasons why you might want to identify
the current "squeak session" for some particular image. My specific
reason for wanting to do this was that, in WindowsOSProcessAccessor, I
want to associate the squeak session identifier with the Win32 HANDLE
of the input/output/error console streams. There is no point in asking
the FilePlugin for its current session identifier if the Interpreter
can provide it.

The fileID is an opaque value that just happens to correspond to some
data structure that we are not supposed to know about, but it is easier
to handle the issue in the Win32OSProcessPlugin that to try to design a
platform independent solution that can be incorporated into FilePlugin for
all supported platforms. The same argument applies to UnixOSProcessPlugin,
and of course to RiscOSProcessPlugin, although the former is at a somewhat
more advanced stage of implementation.

Thus in WindowsOSProcessAccessor>>primGetStdOutputForSession,

primGetStdOutputForSession: sessionIdentifierByteArray
    "Answer a two element array containing the sqFile data structure representing
    standard output stream for my OS process, and a flag (true or false) to indicate
    whether the sqFile data structure contains a valid HANDLE. If no standard output
    stream is available for this OS process, the sqFile data structure will contain an
    invalid HANDLE value, which will result in failures on subsequent accesses."

    "OSProcess accessor primGetStdOutput"

    <primitive: 'primitiveGetStdOutput' module: 'Win32OSProcessPlugin'>
    ^ nil