[squeak-dev] The Inbox: System-mt.1161.mcz

Marcel Taeumel marcel.taeumel at hpi.de
Wed May 27 06:25:53 UTC 2020


> Please have a look at Pharo's OSPlatform class Marcel.

I will. Current goal is to refactor FFIExternalSharedPoolPlatform from FFI-Pools. One step at a time. :-)

> HostPlatform gets my vote. System is a much abused word :-)

Think about HostWindowPlugin, this might work. Eliot suggested FFIPlatformDescription; and to keep it in the FFI package for now, I suppose. See: http://forum.world.st/FFI-FFIExternalSharedPoolPlatform-ExternalPlatform-or-FFIPlatform-or-tp5117240p5117255.html [http://forum.world.st/FFI-FFIExternalSharedPoolPlatform-ExternalPlatform-or-FFIPlatform-or-tp5117240p5117255.html]

> Checking for platform change across every snapshot would be an overkill.

This inbox submission does only inform about platform changes on such "cold starts", which is reflected in the "resuming" (somtimes called "afresh") argument in #startUp:.

> I prefer HostPlatform to be an abstract class with UnixHostPlatform or MacHostPlatform subclasses like in OSProcess.

Hmm.... -1 :-) This would encourage to put more stuff into those subclasses. I think that a simple #isUnix etc. check should suffice in most cases. From there, you can employ any host-platform specific class that you application (or framework or library) has prepared for such a domain. No need to put it too much bloat in such a lightweight mechanism for the base system.

Best,
Marcel
Am 27.05.2020 08:10:44 schrieb Jakob Reschke <forums.jakob at resfarm.de>:
Please have a look at Pharo's OSPlatform class Marcel. If some if its interface and purpose fit, we should make it easier to port code.

K K Subbu <kksubbu.ml at gmail.com [mailto:kksubbu.ml at gmail.com]> schrieb am Di., 26. Mai 2020, 19:31:

On 26/05/20 9:13 pm, Marcel Taeumel wrote:
> 1) Is "SystemPlatform" a fitting name? Alternatives: ExternalPlatform,
> HostPlatform, ...

HostPlatform gets my vote. System is a much abused word :-).

> 2) Is it useful to document the known platform shorthands via
> #isWindows, #isARM, etc.?

I prefer HostPlatform to be an abstract class with UnixHostPlatform or
MacHostPlatform subclasses like in OSProcess. Having such concrete
classes also makes it easy to create OS-specific code without having to
use statements like 'name asLowercase ....' all over the image.

> 3) Is it necessary to access the last platform and the current platform
> in that #systemPlatformChangedFrom:to: callback? Would
> #systemPlatformChanged be sufficient?

The host platform changes only during cold start. why not name it
coldStartOn: and pass the concrete class as an argument? Checking for
platform change across every snapshot would be an overkill.

>
> 4) What are your thoughts on #isCompatibleWith: and #isMoreSpecificThan:?

Not sure if they are really needed at this time.

> 5) Is it too specific to FFI to be in the "System" package? Can you
> think of VM plugins that would benefit from such a detection? Not sure
> about FileDirectory ... because those instances become invalid after
> startup anyway.
No. Being able to reflect on host platform's properties will help
platform-specific code degrade gracefully on unsupported hosts. While
multiplatform capability is a good feature during development, I suppose
most apps would run on the same host for years together.

Regards .. Subbu


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200527/2bc9d998/attachment.html>


More information about the Squeak-dev mailing list