Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0005403 [Squeak] VM feature always 11-12-06 22:12 04-18-10 22:06
Reporter lewis View Status public  
Assigned To tim
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0005403: Allow VMMaker cross-generation of plugin source for platform-dependent plugins
Description A patch for VMMaker to enable cross-generation of plugin source for platform-dependent plugins.

For example, OSPP should generate the Win32 version of the plugin if VMMaker is set to generate plugins for 'win32' and Squeak is running on a Unix VM.

Note that platform name 'Win32' uses platforms directory name 'win32', so plugins should use a case-insensitive compare.
Additional Information
Attached Files  VMM-CrossGeneration-dtl.1.cs.gz [^] (604 bytes) 11-12-06 22:12
 VMMaker-tpr.77.mcz [^] (842,696 bytes) 05-29-08 03:14
 VMConstruction-Plugins-OSProcessPlugin-tpr.14.mcz [^] (75,339 bytes) 05-29-08 03:14

- Relationships

SYSTEM WARNING: Creating default object from empty value

related to 0003770closed tim [Enh] Improvement to cross-platform plugin generation 
child of 0006671closed tim Build VMMaker for 3.9 

- Notes
(0011139 - 679 - 727 - 727 - 727 - 727 - 727)
tim
09-18-07 02:28

I'm puzzled; so far as I can work out cross-platform codeg generation should work as-is. The platform specfic code is looked for in the platform specific subdirectory specified by the platform setting in the VMMakerTool and as an experiment I
ran VMMakerTool on my OSX machine
set platform to win32
tried to drag TestOSAPlugin to the internal list
- it refused
I added a TestsOSAPlugin subdir to platforms/win32/plugins
- it worked

Altering the #shouldBeTranslated stuff isn't really the right place anyway; that is for making sure we don't try to generate code for the abstract plugin classes. If anything does need changing I'd suggest #validatePlugin:in: and friends.
 
(0011140 - 63 - 63 - 63 - 63 - 63 - 63)
tim
09-18-07 02:29

Can you try this again Dave? I can't see how it is going wrong.
 
(0011144 - 347 - 347 - 347 - 347 - 347 - 347)
lewis
09-18-07 11:10

The purpose of the change is to permit e.g. a concrete subclass of OSProcessPlugin to be selected for translation. For example, I usually run on Linux but would like to generate the Win32OSProcessPlugin C source without rebooting my computer. The platform specific subdirectory is not involved (there is no platform support code for OSPP and kin).
 
(0011605 - 210 - 210 - 210 - 210 - 210 - 210)
tim
12-28-07 18:29

Ah, well I'd recommend having a platform directory then; it can be empty since it is simply checked for existence. And I'm startled that there is no platform code for the plugin since it supports win/mac/*nix !
 
(0011616 - 266 - 278 - 278 - 278 - 278 - 278)
lewis
12-29-07 14:45
edited on: 12-29-07 14:49

Please see the change set. It has nothing to do with the external platforms code, it's just a trivial change to allow a plugin class to say that it should be translated for a particular platform independent of what platform you happen to be running on at the time.

 
(0012202 - 492 - 492 - 492 - 492 - 492 - 492)
lewis
05-28-08 00:25

Just to be clear: There is nothing that can be done in the external file system that will cause the in-image VMMakerTool to deduce which subclass of OSProcessPlugin I want it to use to generate code for some arbitrary target platform. To the best of my knowledge, the attached patch is the only reasonable way to give a hint to VMMakerTool that I want to translate Win32OSProcessPlugin rather than UnixOSProcessPlugin, even if VMMakerTool happens to be running on RiscOS or a Mac at the time.
 
(0012215 - 627 - 651 - 651 - 651 - 651 - 651)
tim
05-29-08 03:12

OK, now that I finally have the OSPP code to look at I see the problem - I hadn't considered platform specific plugins with no external files.

We shouldn't conflate the #shouldBeTranslated stuff with this issue; all that will do is confuse me later. It is meant to keep 'junk' classes out of the list of available plugins, not to keep platform innapropriate plugins out.

I added a new test - #isSuitablePluginForPlatform: to perform the check. See InterpreterPlugin class and so on. I removed the various (ab)uses of #shouldBeTranslated from the OSPP package -tp4.14 and it needs to be tested along with VMMaker-tpr.77
 
(0012217 - 52 - 52 - 52 - 52 - 52 - 52)
tim
05-29-08 03:15

Try this version Dave; seems reasonably clean to me.
 
(0012218 - 72 - 72 - 72 - 72 - 72 - 72)
lewis
05-29-08 11:37

Thanks Tim, sounds reasonable and I will have a look at it this weekend.
 
(0012234 - 959 - 1121 - 1121 - 1121 - 1121 - 1121)
lewis
05-31-08 17:38

If I'm reading this correctly, it looks like you are going to do this:

- Find all plugins that #shouldBeTranslated
- For each of these plugins, check if it #isSuitablePluginForPlatform
  - ifTrue: default condition, plugin will be translated
  - ifFalse: diplay a warning dialog, and exclude the plugin from translation

Two issues come to mind:

- Every class that answers false to #isSuitablePluginForPlatform will result
  in a warning dialog. Answering false is perfectly normal, so the warning
  dialog should be eliminated (and the exception is probably pointless as well).
- I still will need to use #shouldBeTranslated to exclude the abstract plugin
  classes (e.g. class OSProcessPlugin). This is not a problem, but I want to point
  it out in case I am still misunderstanding the intent of #shouldBeTranslated.

As long as you get rid of the warning dialogs, this looks like a good way
to handle cross-platform translation. Thanks!
 
(0012310 - 46 - 46 - 46 - 46 - 46 - 46)
tim
06-24-08 05:07

VMMaker-tpr.77 includes the discussed changes.
 

- Issue History
Date Modified Username Field Change
11-12-06 22:12 lewis New Issue
11-12-06 22:12 lewis File Added: VMM-CrossGeneration-dtl.1.cs.gz
11-12-06 22:12 lewis Issue Monitored: lewis
09-12-07 00:37 tim Status new => assigned
09-12-07 00:37 tim Assigned To  => tim
09-14-07 00:00 tim Relationship added child of 0006671
09-18-07 02:28 tim Note Added: 0011139
09-18-07 02:29 tim Note Added: 0011140
09-18-07 02:29 tim Assigned To tim => lewis
09-18-07 02:29 tim Status assigned => feedback
09-18-07 11:10 lewis Note Added: 0011144
09-18-07 18:23 lewis Status feedback => assigned
09-18-07 18:23 lewis Assigned To lewis => tim
12-28-07 18:29 tim Note Added: 0011605
12-28-07 18:33 tim Assigned To tim => lewis
12-29-07 03:27 tim Relationship added related to 0003770
12-29-07 14:45 lewis Note Added: 0011616
12-29-07 14:49 lewis Note Edited: 0011616
05-28-08 00:25 lewis Note Added: 0012202
05-28-08 00:25 lewis Assigned To lewis => tim
05-29-08 03:12 tim Note Added: 0012215
05-29-08 03:14 tim File Added: VMMaker-tpr.77.mcz
05-29-08 03:14 tim File Added: VMConstruction-Plugins-OSProcessPlugin-tpr.14.mcz
05-29-08 03:15 tim Note Added: 0012217
05-29-08 03:15 tim Assigned To tim => lewis
05-29-08 03:15 tim Status assigned => feedback
05-29-08 11:37 lewis Note Added: 0012218
05-31-08 17:38 lewis Note Added: 0012234
06-01-08 04:31 lewis Status feedback => assigned
06-01-08 04:31 lewis Assigned To lewis => tim
06-24-08 05:07 tim Status assigned => resolved
06-24-08 05:07 tim Resolution open => fixed
06-24-08 05:07 tim Note Added: 0012310
04-18-10 22:06 andreas Status resolved => closed


Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
108 total queries executed.
55 unique queries executed.
Powered by Mantis Bugtracker