Hello all,
I am starting to move files back and forth between Windows and Linux. On Windows, I do this using an evolved version of a command line program I wrote in the win3.1 days, and is now a GUI app written in Dolphin. I now need to create a Squeak version of it to idiot proof my copying to and from Linux. My question is in two parts. First, is there any trick to the modification times on Linux vs. Windows. I vaguely recall hearing that a forgotten difference in behavior of the two systems lead Sun to cause some trouble in the early days of Java. Cautions will be gladly researched. Ubunutu at least seems to do what I expect when I copy "manually." The second question is what is the best way to copy files in/from Squeak, given that I care about preserving modification times? I thought to load OS Process, but Squeak exited silently (sadly, I did not think to look for an error until after the log was overwritten by a subsequent error). I tried again and it loaded normally; is OSProcess stable? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
On Sun, Mar 02, 2008 at 12:31:55PM -0500, Bill Schwab wrote:
> I thought to load OS Process, but Squeak exited silently (sadly, I did > not think to look for an error until after the log was overwritten by a > subsequent error). I tried again and it loaded normally; is OSProcess > stable? Bill, OSProcess should be stable on Unix/Linux, and I think that most of its functions work on OS/X. It's not much use on Windows. If you encounter this problem again on a Linux system, I would be grateful for any details you can provide. I'm not sure that I understand what you are trying to do, but if you mean to move or copy files using unix commands driven by Squeak, then the combination of OSProcess and CommandShell will help, but this would be a platform-specific solution. Note also that Squeak has the FileCopyPlugin (you may need to build it yourself with VMMaker if it's not in your VM, I'm not sure). This is attempt to provide some of the file copy behavior that you are trying to achieve, and it should work on multiple platforms, so possibly that would be of some help. See FileList>>primitiveCopyFileNamed:to: which uses the FileCopyPlugin. Dave |
In reply to this post by Schwab,Wilhelm K
Dave,
Thanks for the read on OSProces; I will try it a few more times and see what happens. As an aside, I have long thought that the error log should append vs. truncate by default; this is by no means the first time I have lost data due to the current behavior. Whenever I have a stubborn problem, I alter the logging code, but it is often too late for something (hopefully) transient like this. Back to my immediate goal, a Linux-specific solutoin is perfectly adequate, as I already have a working solution on Windows. The exchanges occur between a "floppy" (now typically a flash drive) and the local file system. So, I can get Windows to copy to the stick, and then have Squeak copy from the stick to the file system and back. The copy plugin appears not to be in my VM. To be safe though, how would I test that? So far, all I have found is to call a function in the plugin, which could fail for various reasons besides the code not being present. Thanks, Bill ============================ "David T. Lewis" <lewis@...> lewis@... wote: On Sun, Mar 02, 2008 at 12:31:55PM -0500, Bill Schwab wrote: > I thought to load OS Process, but Squeak exited silently (sadly, I did > not think to look for an error until after the log was overwritten by a > subsequent error). I tried again and it loaded normally; is OSProcess > stable? Bill, OSProcess should be stable on Unix/Linux, and I think that most of its functions work on OS/X. It's not much use on Windows. If you encounter this problem again on a Linux system, I would be grateful for any details you can provide. I'm not sure that I understand what you are trying to do, but if you mean to move or copy files using unix commands driven by Squeak, then the combination of OSProcess and CommandShell will help, but this would be a platform-specific solution. Note also that Squeak has the FileCopyPlugin (you may need to build it yourself with VMMaker if it's not in your VM, I'm not sure). This is attempt to provide some of the file copy behavior that you are trying to achieve, and it should work on multiple platforms, so possibly that would be of some help. See FileList>>primitiveCopyFileNamed:to: which uses the FileCopyPlugin. Dave Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
On Sun, Mar 02, 2008 at 05:49:54PM -0500, Bill Schwab wrote:
> > The copy plugin appears not to be in my VM. To be safe though, how > would I test that? So far, all I have found is to call a function in > the plugin, which could fail for various reasons besides the code not > being present. Bill, If you call the file copy primitive, it will try to load the plugin. The #listLoadedModules method will show you the loaded plugins, hence: FileList new primitiveCopyFileNamed: 'foo' to: 'bar'. SmalltalkImage current listLoadedModules detect: [:plugin | 'FileCopyPlugin*' match: plugin] ifNone: ['the FileCopyPlugin is not installed'] Dave |
On Mar 3, 2008, at 3:37 , David T. Lewis wrote:
> On Sun, Mar 02, 2008 at 05:49:54PM -0500, Bill Schwab wrote: >> >> The copy plugin appears not to be in my VM. To be safe though, how >> would I test that? So far, all I have found is to call a function in >> the plugin, which could fail for various reasons besides the code not >> being present. > > Bill, > > If you call the file copy primitive, it will try to load the plugin. > The #listLoadedModules method will show you the loaded plugins, hence: > > FileList new primitiveCopyFileNamed: 'foo' to: 'bar'. > SmalltalkImage current listLoadedModules > detect: [:plugin | 'FileCopyPlugin*' match: plugin] > ifNone: ['the FileCopyPlugin is not installed'] > Also, #listBuiltinModules will list the plugins compiled into the VM. There is no similar call for external plugins, but these you can see in the files system yourself. - Bert - |
In reply to this post by Schwab,Wilhelm K
Bert,
My image reports its #vmPath as: /usr/local/lib/squeak/3.9-8/ and looking there, I see the vm and some plugins. Is being in that directory enough, or is there something else I have to do to get it to see and/or report a plugin's existence? Are they loaded at startup, only on demand, etc.? >From my feeble experiments, I'm guessing that it is on demand. I became curious over the DES plugin, which I now appear to have working. To get there, I grabbed the plugin from http://wiki.squeak.org/squeak/2410 and then saved it as both /usr/local/lib/squeak/3.9-8/DESPlugin /usr/local/lib/squeak/3.9-8/DESPrims.so Not quite knowing what I was doing (make that being completely clueless), I am not sure which one made it work. Any ideas? The DESPlugin class comment includes: You should build this plugin with the module name 'DESPrims'. and adding the .so seemed like might be a good idea. Does the plugin load code try/ignore that extension? Thanks, Bill ========================== Bert Freudenberg <bert@...>bert@... wrote: Also, #listBuiltinModules will list the plugins compiled into the VM. There is no similar call for external plugins, but these you can see in the files system yourself. - Bert - Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [hidden email] Tel: (352) 846-1285 FAX: (352) 392-7029 |
On 3-Mar-08, at 8:01 PM, Bill Schwab wrote: > > and looking there, I see the vm and some plugins. Is being in that > directory enough, or is there something else I have to do to get it to > see and/or report a plugin's existence? Are they loaded at startup, > only on demand, etc.? The best place for plugins to live is somewhat platform dependent, unfortunately. I'm fairly sure that having a plugin file in the same place as the vm will usually be ok though. External plugins load on demand and get bound to the vm. Internal plugins are sort of pre- loaded but they are connected up internally on demand just like the externals. This is part of making it possible to have an external (for updating etc) copy of a plugin that is also internal. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Fractured Idiom:- FELIX NAVIDAD - Our cat has a boat |
The last time I looked at the file plugin on the macintosh (a decade
ago?) sure feels like it. Tim was trying to get it to work as some way to copy files between a master directory and the build directory for the first revision of VMMaker.. Yes? Anyway Apple didn't actually offer a way to copy files between locations until mmm os-x 10.4 came out, shamed into it I think. Certainly the OS-9 code ran to a hundred pages, aliases, HFS+ servers, server aliases, etc etc. Folder/File. However 10.4 (was it 10.3?) they introduced access control list meta- data on files and muttered about an API you could use that would invoke the same logic as the Finder uses to copy an object from one place to another. We use that in Sophie, so the bits go, and so do the multiple dates, permissions, meta-data, endless list... Files simple, Yah that would be CP/M Likely once you did into it the file plugin on unix is *mostly* there, but really a better solution would be to use FFI, or OSProcess and invoke the right shell command. On Mar 3, 2008, at 10:12 PM, tim Rowledge wrote: > > On 3-Mar-08, at 8:01 PM, Bill Schwab wrote: >> >> and looking there, I see the vm and some plugins. Is being in that >> directory enough, or is there something else I have to do to get it >> to >> see and/or report a plugin's existence? Are they loaded at startup, >> only on demand, etc.? > The best place for plugins to live is somewhat platform dependent, > unfortunately. I'm fairly sure that having a plugin file in the same > place as the vm will usually be ok though. External plugins load on > demand and get bound to the vm. Internal plugins are sort of pre- > loaded but they are connected up internally on demand just like the > externals. This is part of making it possible to have an external > (for updating etc) copy of a plugin that is also internal. > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Fractured Idiom:- FELIX NAVIDAD - Our cat has a boat > > > -- = = = ======================================================================== John M. McIntosh <[hidden email]> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== |
In reply to this post by Schwab,Wilhelm K
On Mar 4, 2008, at 5:01 , Bill Schwab wrote: > Bert, > > My image reports its #vmPath as: > > /usr/local/lib/squeak/3.9-8/ > > and looking there, I see the vm and some plugins. Is being in that > directory enough, or is there something else I have to do to get it to > see and/or report a plugin's existence? Are they loaded at startup, > only on demand, etc.? On demand. >> From my feeble experiments, I'm guessing that it is on demand. I >> became > curious over the DES plugin, which I now appear to have working. > To get > there, I grabbed the plugin from > > http://wiki.squeak.org/squeak/2410 > > and then saved it as both > > /usr/local/lib/squeak/3.9-8/DESPlugin > /usr/local/lib/squeak/3.9-8/DESPrims.so > > Not quite knowing what I was doing (make that being completely > clueless), I am not sure which one made it work. Any ideas? The > DESPlugin class comment includes: > > You should build this plugin with the module name 'DESPrims'. > > and adding the .so seemed like might be a good idea. Does the plugin > load code try/ignore that extension? You have to look in the image where the primitive is called, you'll have a line like <primitive: 'primitiveName' module: 'PluginName'> That module name is used to find the plugin, see See http://squeakvm.org/svn/squeak/trunk/platforms/unix/vm/ sqUnixExternalPrims.c It tries to load the name as given, or with a "lib" prefix and ".so" suffix" (and ".dylib" for MacOS X). Also it tries to find it in "./", $SQUEAK_PLUGIN_PATH, "/usr/local/ lib/squeak/3.9-8/", $LD_LIBRARY_PATH, and the system standard library directories ("/usr/lib" etc.). If all that fails, it looks if this is an internal module. - Bert - |
Free forum by Nabble | Edit this page |