On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: > > Hi David, Hi Release Manager, Hi All, > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: > > > > A 64-bit to 32-bit image converter would be a very good thing to have > > in our toolkit :-) > > I got this working this morning. See Cog-eem.398. So to use, > - clone or update an opensmalltalk-vm repository > - cd to the image directory and create a VMMaker image via either > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh > - run a converter, e.g. > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. > (produces trunk6-64.image & trunk6-64.changes) > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. > (produces trunk6-64-32.image & trunk6-64-32.changes) > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on > my 2.9GHz Core i9 MacBook Pro > > > So let's try releasing by converting the 64-bit image into a 32-bit one. > Bravo! I am away now but will try doing an image conversion as soon as I can tomorrow. Thanks Eliot, Dave |
I need some help on this, can someone please test the converted 32-bit image on Linux and/or Windows? I'm have problems with my 32-bit libraries (I think) and I don't have any time to follow up on it today. Thanks! The actual image conversion seems to work fine, and it's fast. But I don't have a 32-bit VM at the moment, probably due to Linux runtime library issues that I don't have time to sort out this morning. Thanks! Dave On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote: > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: > > > > Hi David, Hi Release Manager, Hi All, > > > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: > > > > > > A 64-bit to 32-bit image converter would be a very good thing to have > > > in our toolkit :-) > > > > I got this working this morning. See Cog-eem.398. So to use, > > - clone or update an opensmalltalk-vm repository > > - cd to the image directory and create a VMMaker image via either > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh > > - run a converter, e.g. > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. > > (produces trunk6-64.image & trunk6-64.changes) > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. > > (produces trunk6-64-32.image & trunk6-64-32.changes) > > > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on > > my 2.9GHz Core i9 MacBook Pro > > > > > > So let's try releasing by converting the 64-bit image into a 32-bit one. > > > > Bravo! I am away now but will try doing an image conversion as soon as > I can tomorrow. > > Thanks Eliot, > |
>> On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: >>> >>> >>> Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on >>> my 2.9GHz Core i9 MacBook Pro Once the conversion is known to work reliably I suggest it would be worth running it as part of the auto-build stuff, especially if it takes so little time. Finding out promptly if anything makes it fail would likely be valuable in the future. And of course a copy of the convertor image ought be available to download for local use. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Teflon brain -- nothing sticks. |
In reply to this post by David T. Lewis
This is mac's sandboxing/AppTranslocation. You must: a) unzip the zip (if it is one) or open the .dmg b) Move the App to somewhere that is _not_ the Downloads folder c) only _then_ open the .app Otherwise translocation will happen and you cannot do anything useful. -t > On 11.02.2020, at 18:12, Eliot Miranda <[hidden email]> wrote: > > Hi David, Hi Bert, Paul, Craig, Chris & Fabio (authors of the squeak start script), > > On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote: > Update - I resolved my library problem, and can run the traced image. > However, it opens with an empty black window (but no VM crash or error > messages). > > This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message: > > Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6 > > Please check you have write permission for this file. > > You won't be able to save this image correctly until you fix this. > > > So we can't (yet) lunch the release out-of-the-box on Mac. This launching things in a translocated folder is (bad) news to me. How are we supposed to establish write permission? If the image explicitly tries to change permissions it will transgress on valid attempt to make the changes file read-only. And anyway the files look readable when one uses ls to read permissions: > > $ ls -l /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/ > total 191096 > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 B3DAcceleratorPlugin.bundle > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CameraPlugin.bundle > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CroquetPlugin.bundle > drwxr-xr-x@ 5 eliot staff 160 Feb 11 2020 English.lproj > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Mpeg3Plugin.bundle > -rw-r--r--@ 1 eliot staff 334260 Feb 11 2020 Squeak.icns > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Squeak3D.bundle > -rw-r--r--@ 1 eliot staff 17502632 Feb 11 2020 Squeak5.3beta-19337-64bit.changes > -rw-r--r--@ 1 eliot staff 44108920 Feb 11 2020 Squeak5.3beta-19337-64bit.image > -rwxr-xr-x@ 1 eliot staff 55656 Feb 11 2020 SqueakChanges.icns > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakFFIPrims.bundle > -rwxr-xr-x@ 1 eliot staff 52976 Feb 11 2020 SqueakGeneric.icns > -rwxr-xr-x@ 1 eliot staff 334260 Feb 11 2020 SqueakImage.icns > -rwxr-xr-x@ 1 eliot staff 61719 Feb 11 2020 SqueakPlugin.icns > -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakProject.icns > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakSSL.bundle > -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakScript.icns > -rwxr-xr-x@ 1 eliot staff 55332 Feb 11 2020 SqueakSources.icns > -rw-r--r--@ 1 eliot staff 35184983 Feb 11 2020 SqueakV50.sources > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 UnixOSProcessPlugin.bundle > drwxr-xr-x@ 58 eliot staff 1856 Feb 11 2020 locale > drwxr-xr-x@ 9 eliot staff 288 Feb 11 2020 release-notes > > > > > The image that I converted was Squeak5.3beta-19335-64bit.image. I'll > try some others later. > > Meanwhile if anyone else can give this a try, please do :-) > > Dave > > > On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote: > > I need some help on this, can someone please test the converted 32-bit > > image on Linux and/or Windows? I'm have problems with my 32-bit libraries > > (I think) and I don't have any time to follow up on it today. Thanks! > > > > The actual image conversion seems to work fine, and it's fast. But I > > don't have a 32-bit VM at the moment, probably due to Linux runtime > > library issues that I don't have time to sort out this morning. > > > > Thanks! > > Dave > > > > On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote: > > > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: > > > > > > > > Hi David, Hi Release Manager, Hi All, > > > > > > > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: > > > > > > > > > > A 64-bit to 32-bit image converter would be a very good thing to have > > > > > in our toolkit :-) > > > > > > > > I got this working this morning. See Cog-eem.398. So to use, > > > > - clone or update an opensmalltalk-vm repository > > > > - cd to the image directory and create a VMMaker image via either > > > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh > > > > - run a converter, e.g. > > > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. > > > > (produces trunk6-64.image & trunk6-64.changes) > > > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. > > > > (produces trunk6-64-32.image & trunk6-64-32.changes) > > > > > > > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on > > > > my 2.9GHz Core i9 MacBook Pro > > > > > > > > > > > > So let's try releasing by converting the 64-bit image into a 32-bit one. > > > > > > > > > > Bravo! I am away now but will try doing an image conversion as soon as > > > I can tomorrow. > > > > > > Thanks Eliot, > > > > > > > > > > > > > > > > > |
Hi Tobias, On Tue, Feb 11, 2020 at 10:29 AM Tobias Pape <[hidden email]> wrote:
I had done just that. What I did (exactly) is: - downloaded Squeak5.3beta-19337-64bit-All-in-One.zip from http://files.squeak.org/trunk/Squeak5.3beta-19337-64bit/ (to my Downloads folder) - moved the app to my oscogvm/image folder (oscogvm is my working opensmalltalk-vm git repository) - issued the command via a terminal $ cd oscogvm/image $ open Squeak5.3beta-19337-64bit-All-in-One/Squeak5.3beta-19337-64bit-All-in-One.app/ And if launched like that it still gets run in the AppTranslocation SNAFU.
_,,,^..^,,,_ best, Eliot |
> On 11.02.2020, at 20:02, Eliot Miranda <[hidden email]> wrote: > > Hi Tobias, > > On Tue, Feb 11, 2020 at 10:29 AM Tobias Pape <[hidden email]> wrote: > > > This is mac's sandboxing/AppTranslocation. > > You must: > a) unzip the zip (if it is one) or open the .dmg > b) Move the App to somewhere that is _not_ the Downloads folder > c) only _then_ open the .app > > Otherwise translocation will happen and you cannot do anything useful. > > I had done just that. What I did (exactly) is: > > - downloaded Squeak5.3beta-19337-64bit-All-in-One.zip from http://files.squeak.org/trunk/Squeak5.3beta-19337-64bit/ (to my Downloads folder) > - moved the app to my oscogvm/image folder (oscogvm is my working opensmalltalk-vm git repository) > - issued the command via a terminal > $ cd oscogvm/image > $ open Squeak5.3beta-19337-64bit-All-in-One/Squeak5.3beta-19337-64bit-All-in-One.app/ > > And if launched like that it still gets run in the AppTranslocation SNAFU. Bummer, it used to work like that… Did you move the folder or the app? In any case some things seems to have changed with Mojave, in addition to Sierra's Translocation… It's jumped the shark by now, IMHO… Best regards -Tobias > > > -t > > > On 11.02.2020, at 18:12, Eliot Miranda <[hidden email]> wrote: > > > > Hi David, Hi Bert, Paul, Craig, Chris & Fabio (authors of the squeak start script), > > > > On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote: > > Update - I resolved my library problem, and can run the traced image. > > However, it opens with an empty black window (but no VM crash or error > > messages). > > > > This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message: > > > > Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6 > > > > > > Please check you have write permission for this file. > > > > You won't be able to save this image correctly until you fix this. > > > > > > So we can't (yet) lunch the release out-of-the-box on Mac. This launching things in a translocated folder is (bad) news to me. How are we supposed to establish write permission? If the image explicitly tries to change permissions it will transgress on valid attempt to make the changes file read-only. And anyway the files look readable when one uses ls to read permissions: > > > > $ ls -l /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/ > > total 191096 > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 B3DAcceleratorPlugin.bundle > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CameraPlugin.bundle > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CroquetPlugin.bundle > > drwxr-xr-x@ 5 eliot staff 160 Feb 11 2020 English.lproj > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Mpeg3Plugin.bundle > > -rw-r--r--@ 1 eliot staff 334260 Feb 11 2020 Squeak.icns > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Squeak3D.bundle > > -rw-r--r--@ 1 eliot staff 17502632 Feb 11 2020 Squeak5.3beta-19337-64bit.changes > > -rw-r--r--@ 1 eliot staff 44108920 Feb 11 2020 Squeak5.3beta-19337-64bit.image > > -rwxr-xr-x@ 1 eliot staff 55656 Feb 11 2020 SqueakChanges.icns > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakFFIPrims.bundle > > -rwxr-xr-x@ 1 eliot staff 52976 Feb 11 2020 SqueakGeneric.icns > > -rwxr-xr-x@ 1 eliot staff 334260 Feb 11 2020 SqueakImage.icns > > -rwxr-xr-x@ 1 eliot staff 61719 Feb 11 2020 SqueakPlugin.icns > > -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakProject.icns > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakSSL.bundle > > -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakScript.icns > > -rwxr-xr-x@ 1 eliot staff 55332 Feb 11 2020 SqueakSources.icns > > -rw-r--r--@ 1 eliot staff 35184983 Feb 11 2020 SqueakV50.sources > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 UnixOSProcessPlugin.bundle > > drwxr-xr-x@ 58 eliot staff 1856 Feb 11 2020 locale > > drwxr-xr-x@ 9 eliot staff 288 Feb 11 2020 release-notes > > > > > > > > > > The image that I converted was Squeak5.3beta-19335-64bit.image. I'll > > try some others later. > > > > Meanwhile if anyone else can give this a try, please do :-) > > > > Dave > > > > > > On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote: > > > I need some help on this, can someone please test the converted 32-bit > > > image on Linux and/or Windows? I'm have problems with my 32-bit libraries > > > (I think) and I don't have any time to follow up on it today. Thanks! > > > > > > The actual image conversion seems to work fine, and it's fast. But I > > > don't have a 32-bit VM at the moment, probably due to Linux runtime > > > library issues that I don't have time to sort out this morning. > > > > > > Thanks! > > > Dave > > > > > > On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote: > > > > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: > > > > > > > > > > Hi David, Hi Release Manager, Hi All, > > > > > > > > > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: > > > > > > > > > > > > A 64-bit to 32-bit image converter would be a very good thing to have > > > > > > in our toolkit :-) > > > > > > > > > > I got this working this morning. See Cog-eem.398. So to use, > > > > > - clone or update an opensmalltalk-vm repository > > > > > - cd to the image directory and create a VMMaker image via either > > > > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh > > > > > - run a converter, e.g. > > > > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. > > > > > (produces trunk6-64.image & trunk6-64.changes) > > > > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. > > > > > (produces trunk6-64-32.image & trunk6-64-32.changes) > > > > > > > > > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on > > > > > my 2.9GHz Core i9 MacBook Pro > > > > > > > > > > > > > > > So let's try releasing by converting the 64-bit image into a 32-bit one. > > > > > > > > > > > > > Bravo! I am away now but will try doing an image conversion as soon as > > > > I can tomorrow. > > > > > > > > Thanks Eliot, > > > > > > > > > > > > > > > > > > > > > > > > > |
Hi Tobias, On Tue, Feb 11, 2020 at 11:24 AM Tobias Pape <[hidden email]> wrote:
Ahhhh, good point. I moved the enclosing folder to preserve the squeak.bat and squeak.sh scripts. Moving it again makes no difference :-(
The shark is biting my ass :-(
_,,,^..^,,,_ best, Eliot |
> On 11.02.2020, at 20:34, Eliot Miranda <[hidden email]> wrote: > > Hi Tobias, > > On Tue, Feb 11, 2020 at 11:24 AM Tobias Pape <[hidden email]> wrote: > > > > On 11.02.2020, at 20:02, Eliot Miranda <[hidden email]> wrote: > > > > Hi Tobias, > > > > On Tue, Feb 11, 2020 at 10:29 AM Tobias Pape <[hidden email]> wrote: > > > > > > This is mac's sandboxing/AppTranslocation. > > > > You must: > > a) unzip the zip (if it is one) or open the .dmg > > b) Move the App to somewhere that is _not_ the Downloads folder > > c) only _then_ open the .app > > > > Otherwise translocation will happen and you cannot do anything useful. > > > > I had done just that. What I did (exactly) is: > > > > - downloaded Squeak5.3beta-19337-64bit-All-in-One.zip from http://files.squeak.org/trunk/Squeak5.3beta-19337-64bit/ (to my Downloads folder) > > - moved the app to my oscogvm/image folder (oscogvm is my working opensmalltalk-vm git repository) > > - issued the command via a terminal > > $ cd oscogvm/image > > $ open Squeak5.3beta-19337-64bit-All-in-One/Squeak5.3beta-19337-64bit-All-in-One.app/ > > > > And if launched like that it still gets run in the AppTranslocation SNAFU. > > Bummer, it used to work like that… > > Did you move the folder or the app? > > Ahhhh, good point. I moved the enclosing folder to preserve the squeak.bat and squeak.sh scripts. Moving it again makes no difference :-( Yes. It must be kind-of the first thing you do after extraction or so… But I don't know the "new" rules. Other idea: - Download - Extract - use xattr on the cmdline to recursively remove the quarantine attribute from everything below .app - move? - open But there my guessing ends… > > > In any case some things seems to have changed with Mojave, in addition to Sierra's Translocation… > > It's jumped the shark by now, IMHO… > > The shark is biting my ass :-( It's a sharknado at that point in time. Best regards -Tobias > > > Best regards > -Tobias > > > > > > > -t > > > > > On 11.02.2020, at 18:12, Eliot Miranda <[hidden email]> wrote: > > > > > > Hi David, Hi Bert, Paul, Craig, Chris & Fabio (authors of the squeak start script), > > > > > > On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote: > > > Update - I resolved my library problem, and can run the traced image. > > > However, it opens with an empty black window (but no VM crash or error > > > messages). > > > > > > This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message: > > > > > > Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6 > > > > > > > > > > Please check you have write permission for this file. > > > > > > You won't be able to save this image correctly until you fix this. > > > > > > > > > So we can't (yet) lunch the release out-of-the-box on Mac. This launching things in a translocated folder is (bad) news to me. How are we supposed to establish write permission? If the image explicitly tries to change permissions it will transgress on valid attempt to make the changes file read-only. And anyway the files look readable when one uses ls to read permissions: > > > > > > $ ls -l /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/ > > > total 191096 > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 B3DAcceleratorPlugin.bundle > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CameraPlugin.bundle > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CroquetPlugin.bundle > > > drwxr-xr-x@ 5 eliot staff 160 Feb 11 2020 English.lproj > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Mpeg3Plugin.bundle > > > -rw-r--r--@ 1 eliot staff 334260 Feb 11 2020 Squeak.icns > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Squeak3D.bundle > > > -rw-r--r--@ 1 eliot staff 17502632 Feb 11 2020 Squeak5.3beta-19337-64bit.changes > > > -rw-r--r--@ 1 eliot staff 44108920 Feb 11 2020 Squeak5.3beta-19337-64bit.image > > > -rwxr-xr-x@ 1 eliot staff 55656 Feb 11 2020 SqueakChanges.icns > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakFFIPrims.bundle > > > -rwxr-xr-x@ 1 eliot staff 52976 Feb 11 2020 SqueakGeneric.icns > > > -rwxr-xr-x@ 1 eliot staff 334260 Feb 11 2020 SqueakImage.icns > > > -rwxr-xr-x@ 1 eliot staff 61719 Feb 11 2020 SqueakPlugin.icns > > > -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakProject.icns > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakSSL.bundle > > > -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakScript.icns > > > -rwxr-xr-x@ 1 eliot staff 55332 Feb 11 2020 SqueakSources.icns > > > -rw-r--r--@ 1 eliot staff 35184983 Feb 11 2020 SqueakV50.sources > > > drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 UnixOSProcessPlugin.bundle > > > drwxr-xr-x@ 58 eliot staff 1856 Feb 11 2020 locale > > > drwxr-xr-x@ 9 eliot staff 288 Feb 11 2020 release-notes > > > > > > > > > > > > > > > The image that I converted was Squeak5.3beta-19335-64bit.image. I'll > > > try some others later. > > > > > > Meanwhile if anyone else can give this a try, please do :-) > > > > > > Dave > > > > > > > > > On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote: > > > > I need some help on this, can someone please test the converted 32-bit > > > > image on Linux and/or Windows? I'm have problems with my 32-bit libraries > > > > (I think) and I don't have any time to follow up on it today. Thanks! > > > > > > > > The actual image conversion seems to work fine, and it's fast. But I > > > > don't have a 32-bit VM at the moment, probably due to Linux runtime > > > > library issues that I don't have time to sort out this morning. > > > > > > > > Thanks! > > > > Dave > > > > > > > > On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote: > > > > > On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: > > > > > > > > > > > > Hi David, Hi Release Manager, Hi All, > > > > > > > > > > > > On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: > > > > > > > > > > > > > > A 64-bit to 32-bit image converter would be a very good thing to have > > > > > > > in our toolkit :-) > > > > > > > > > > > > I got this working this morning. See Cog-eem.398. So to use, > > > > > > - clone or update an opensmalltalk-vm repository > > > > > > - cd to the image directory and create a VMMaker image via either > > > > > > buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh > > > > > > - run a converter, e.g. > > > > > > Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. > > > > > > (produces trunk6-64.image & trunk6-64.changes) > > > > > > Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. > > > > > > (produces trunk6-64-32.image & trunk6-64-32.changes) > > > > > > > > > > > > Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on > > > > > > my 2.9GHz Core i9 MacBook Pro > > > > > > > > > > > > > > > > > > So let's try releasing by converting the 64-bit image into a 32-bit one. > > > > > > > > > > > > > > > > Bravo! I am away now but will try doing an image conversion as soon as > > > > > I can tomorrow. > > > > > > > > > > Thanks Eliot, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
> On Feb 11, 2020, at 12:30 PM, Tobias Pape <[hidden email]> wrote: > > > >> On 11.02.2020, at 20:34, Eliot Miranda <[hidden email]> wrote: >> >> Hi Tobias, >> >>> On Tue, Feb 11, 2020 at 11:24 AM Tobias Pape <[hidden email]> wrote: >>> >>> >>>> On 11.02.2020, at 20:02, Eliot Miranda <[hidden email]> wrote: >>> >>> Hi Tobias, >>> >>>> On Tue, Feb 11, 2020 at 10:29 AM Tobias Pape <[hidden email]> wrote: >>> >>> >>> This is mac's sandboxing/AppTranslocation. >>> >>> You must: >>> a) unzip the zip (if it is one) or open the .dmg >>> b) Move the App to somewhere that is _not_ the Downloads folder >>> c) only _then_ open the .app >>> >>> Otherwise translocation will happen and you cannot do anything useful. >>> >>> I had done just that. What I did (exactly) is: >>> >>> - downloaded Squeak5.3beta-19337-64bit-All-in-One.zip from http://files.squeak.org/trunk/Squeak5.3beta-19337-64bit/ (to my Downloads folder) >>> - moved the app to my oscogvm/image folder (oscogvm is my working opensmalltalk-vm git repository) >>> - issued the command via a terminal >>> $ cd oscogvm/image >>> $ open Squeak5.3beta-19337-64bit-All-in-One/Squeak5.3beta-19337-64bit-All-in-One.app/ >>> >>> And if launched like that it still gets run in the AppTranslocation SNAFU. >> >> Bummer, it used to work like that… >> >> Did you move the folder or the app? >> >> Ahhhh, good point. I moved the enclosing folder to preserve the squeak.bat and squeak.sh scripts. Moving it again makes no difference :-( > > Yes. It must be kind-of the first thing you do after extraction or so… > But I don't know the "new" rules. > Other idea: > - Download > - Extract > - use xattr on the cmdline to recursively remove the quarantine attribute from everything below .app > - move? > - open > > But there my guessing ends… My concern is that we present the user with the information before we present them with a dysfunctional app. So I would like us to release an image that is in a state that if the changes file is read only it explains to the user how to correctly install the release, rather than presenting them with gibberish only experts may understand. Of course once the image is configured that warning would go away (the image would no longer be in the “first launch after release” state). Does this make sense? > >> >> >> In any case some things seems to have changed with Mojave, in addition to Sierra's Translocation… >> >> It's jumped the shark by now, IMHO… >> >> The shark is biting my ass :-( > > It's a sharknado at that point in time. > > Best regards > -Tobias > >> >> >> Best regards >> -Tobias >> >>> >>> >>> -t >>> >>>> On 11.02.2020, at 18:12, Eliot Miranda <[hidden email]> wrote: >>>> >>>> Hi David, Hi Bert, Paul, Craig, Chris & Fabio (authors of the squeak start script), >>>> >>>> On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote: >>>> Update - I resolved my library problem, and can run the traced image. >>>> However, it opens with an empty black window (but no VM crash or error >>>> messages). >>>> >>>> This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message: >>>> >>>> Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6 >>>> >>> >>> >>>> Please check you have write permission for this file. >>>> >>>> You won't be able to save this image correctly until you fix this. >>>> >>>> >>>> So we can't (yet) lunch the release out-of-the-box on Mac. This launching things in a translocated folder is (bad) news to me. How are we supposed to establish write permission? If the image explicitly tries to change permissions it will transgress on valid attempt to make the changes file read-only. And anyway the files look readable when one uses ls to read permissions: >>>> >>>> $ ls -l /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/ >>>> total 191096 >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 B3DAcceleratorPlugin.bundle >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CameraPlugin.bundle >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CroquetPlugin.bundle >>>> drwxr-xr-x@ 5 eliot staff 160 Feb 11 2020 English.lproj >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Mpeg3Plugin.bundle >>>> -rw-r--r--@ 1 eliot staff 334260 Feb 11 2020 Squeak.icns >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Squeak3D.bundle >>>> -rw-r--r--@ 1 eliot staff 17502632 Feb 11 2020 Squeak5.3beta-19337-64bit.changes >>>> -rw-r--r--@ 1 eliot staff 44108920 Feb 11 2020 Squeak5.3beta-19337-64bit.image >>>> -rwxr-xr-x@ 1 eliot staff 55656 Feb 11 2020 SqueakChanges.icns >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakFFIPrims.bundle >>>> -rwxr-xr-x@ 1 eliot staff 52976 Feb 11 2020 SqueakGeneric.icns >>>> -rwxr-xr-x@ 1 eliot staff 334260 Feb 11 2020 SqueakImage.icns >>>> -rwxr-xr-x@ 1 eliot staff 61719 Feb 11 2020 SqueakPlugin.icns >>>> -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakProject.icns >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakSSL.bundle >>>> -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakScript.icns >>>> -rwxr-xr-x@ 1 eliot staff 55332 Feb 11 2020 SqueakSources.icns >>>> -rw-r--r--@ 1 eliot staff 35184983 Feb 11 2020 SqueakV50.sources >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 UnixOSProcessPlugin.bundle >>>> drwxr-xr-x@ 58 eliot staff 1856 Feb 11 2020 locale >>>> drwxr-xr-x@ 9 eliot staff 288 Feb 11 2020 release-notes >>>> >>>> >>>> >>>> >>>> The image that I converted was Squeak5.3beta-19335-64bit.image. I'll >>>> try some others later. >>>> >>>> Meanwhile if anyone else can give this a try, please do :-) >>>> >>>> Dave >>>> >>>> >>>> On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote: >>>>> I need some help on this, can someone please test the converted 32-bit >>>>> image on Linux and/or Windows? I'm have problems with my 32-bit libraries >>>>> (I think) and I don't have any time to follow up on it today. Thanks! >>>>> >>>>> The actual image conversion seems to work fine, and it's fast. But I >>>>> don't have a 32-bit VM at the moment, probably due to Linux runtime >>>>> library issues that I don't have time to sort out this morning. >>>>> >>>>> Thanks! >>>>> Dave >>>>> >>>>> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote: >>>>>> On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: >>>>>>> >>>>>>> Hi David, Hi Release Manager, Hi All, >>>>>>> >>>>>>> On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: >>>>>>>> >>>>>>>> A 64-bit to 32-bit image converter would be a very good thing to have >>>>>>>> in our toolkit :-) >>>>>>> >>>>>>> I got this working this morning. See Cog-eem.398. So to use, >>>>>>> - clone or update an opensmalltalk-vm repository >>>>>>> - cd to the image directory and create a VMMaker image via either >>>>>>> buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh >>>>>>> - run a converter, e.g. >>>>>>> Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. >>>>>>> (produces trunk6-64.image & trunk6-64.changes) >>>>>>> Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. >>>>>>> (produces trunk6-64-32.image & trunk6-64-32.changes) >>>>>>> >>>>>>> Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on >>>>>>> my 2.9GHz Core i9 MacBook Pro >>>>>>> >>>>>>> >>>>>>> So let's try releasing by converting the 64-bit image into a 32-bit one. >>>>>>> >>>>>> >>>>>> Bravo! I am away now but will try doing an image conversion as soon as >>>>>> I can tomorrow. >>>>>> >>>>>> Thanks Eliot, >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > > > |
In reply to this post by Tobias Pape
> On Feb 11, 2020, at 12:30 PM, Tobias Pape <[hidden email]> wrote: > > > >> On 11.02.2020, at 20:34, Eliot Miranda <[hidden email]> wrote: >> >> Hi Tobias, >> >>> On Tue, Feb 11, 2020 at 11:24 AM Tobias Pape <[hidden email]> wrote: >>> >>> >>>> On 11.02.2020, at 20:02, Eliot Miranda <[hidden email]> wrote: >>> >>> Hi Tobias, >>> >>>> On Tue, Feb 11, 2020 at 10:29 AM Tobias Pape <[hidden email]> wrote: >>> >>> >>> This is mac's sandboxing/AppTranslocation. >>> >>> You must: >>> a) unzip the zip (if it is one) or open the .dmg >>> b) Move the App to somewhere that is _not_ the Downloads folder >>> c) only _then_ open the .app >>> >>> Otherwise translocation will happen and you cannot do anything useful. >>> >>> I had done just that. What I did (exactly) is: >>> >>> - downloaded Squeak5.3beta-19337-64bit-All-in-One.zip from http://files.squeak.org/trunk/Squeak5.3beta-19337-64bit/ (to my Downloads folder) >>> - moved the app to my oscogvm/image folder (oscogvm is my working opensmalltalk-vm git repository) >>> - issued the command via a terminal >>> $ cd oscogvm/image >>> $ open Squeak5.3beta-19337-64bit-All-in-One/Squeak5.3beta-19337-64bit-All-in-One.app/ >>> >>> And if launched like that it still gets run in the AppTranslocation SNAFU. >> >> Bummer, it used to work like that… >> >> Did you move the folder or the app? >> >> Ahhhh, good point. I moved the enclosing folder to preserve the squeak.bat and squeak.sh scripts. Moving it again makes no difference :-( > > Yes. It must be kind-of the first thing you do after extraction or so… > But I don't know the "new" rules. > Other idea: > - Download > - Extract > - use xattr on the cmdline to recursively remove the quarantine attribute from everything below .app > - move? > - open > > But there my guessing ends… > >> >> >> In any case some things seems to have changed with Mojave, in addition to Sierra's Translocation… >> >> It's jumped the shark by now, IMHO… >> >> The shark is biting my ass :-( > > It's a sharknado at that point in time. :-) :-) :-) <3 > > Best regards > -Tobias > >> >> >> Best regards >> -Tobias >> >>> >>> >>> -t >>> >>>> On 11.02.2020, at 18:12, Eliot Miranda <[hidden email]> wrote: >>>> >>>> Hi David, Hi Bert, Paul, Craig, Chris & Fabio (authors of the squeak start script), >>>> >>>> On Tue, Feb 11, 2020 at 6:48 AM David T. Lewis <[hidden email]> wrote: >>>> Update - I resolved my library problem, and can run the traced image. >>>> However, it opens with an empty black window (but no VM crash or error >>>> messages). >>>> >>>> This is nothing to do with the conversion. It is just an inability to write to the changes, and in fact looks like a show stopper for the Mac. When I open the Mac .app bundle on macOS High Sierra 10.13.6 it gives this error message: >>>> >>>> Squeak cannot write to the changes file named /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/Squeak5.3beta-19337-6 >>>> >>> >>> >>>> Please check you have write permission for this file. >>>> >>>> You won't be able to save this image correctly until you fix this. >>>> >>>> >>>> So we can't (yet) lunch the release out-of-the-box on Mac. This launching things in a translocated folder is (bad) news to me. How are we supposed to establish write permission? If the image explicitly tries to change permissions it will transgress on valid attempt to make the changes file read-only. And anyway the files look readable when one uses ls to read permissions: >>>> >>>> $ ls -l /private/var/folders/1m/5bw4gx414j95y7gmn19bcrvc0000gn/T/AppTranslocation/AF936F9C-D399-44BA-A75D-2B6B530BE339/d/Squeak5.3beta-19337-64bit-All-in-One.app/Contents/Resources/ >>>> total 191096 >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 B3DAcceleratorPlugin.bundle >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CameraPlugin.bundle >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 CroquetPlugin.bundle >>>> drwxr-xr-x@ 5 eliot staff 160 Feb 11 2020 English.lproj >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Mpeg3Plugin.bundle >>>> -rw-r--r--@ 1 eliot staff 334260 Feb 11 2020 Squeak.icns >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 Squeak3D.bundle >>>> -rw-r--r--@ 1 eliot staff 17502632 Feb 11 2020 Squeak5.3beta-19337-64bit.changes >>>> -rw-r--r--@ 1 eliot staff 44108920 Feb 11 2020 Squeak5.3beta-19337-64bit.image >>>> -rwxr-xr-x@ 1 eliot staff 55656 Feb 11 2020 SqueakChanges.icns >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakFFIPrims.bundle >>>> -rwxr-xr-x@ 1 eliot staff 52976 Feb 11 2020 SqueakGeneric.icns >>>> -rwxr-xr-x@ 1 eliot staff 334260 Feb 11 2020 SqueakImage.icns >>>> -rwxr-xr-x@ 1 eliot staff 61719 Feb 11 2020 SqueakPlugin.icns >>>> -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakProject.icns >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 SqueakSSL.bundle >>>> -rwxr-xr-x@ 1 eliot staff 63636 Feb 11 2020 SqueakScript.icns >>>> -rwxr-xr-x@ 1 eliot staff 55332 Feb 11 2020 SqueakSources.icns >>>> -rw-r--r--@ 1 eliot staff 35184983 Feb 11 2020 SqueakV50.sources >>>> drwxr-xr-x@ 3 eliot staff 96 Feb 11 2020 UnixOSProcessPlugin.bundle >>>> drwxr-xr-x@ 58 eliot staff 1856 Feb 11 2020 locale >>>> drwxr-xr-x@ 9 eliot staff 288 Feb 11 2020 release-notes >>>> >>>> >>>> >>>> >>>> The image that I converted was Squeak5.3beta-19335-64bit.image. I'll >>>> try some others later. >>>> >>>> Meanwhile if anyone else can give this a try, please do :-) >>>> >>>> Dave >>>> >>>> >>>> On Tue, Feb 11, 2020 at 09:09:53AM -0500, David T. Lewis wrote: >>>>> I need some help on this, can someone please test the converted 32-bit >>>>> image on Linux and/or Windows? I'm have problems with my 32-bit libraries >>>>> (I think) and I don't have any time to follow up on it today. Thanks! >>>>> >>>>> The actual image conversion seems to work fine, and it's fast. But I >>>>> don't have a 32-bit VM at the moment, probably due to Linux runtime >>>>> library issues that I don't have time to sort out this morning. >>>>> >>>>> Thanks! >>>>> Dave >>>>> >>>>> On Mon, Feb 10, 2020 at 08:47:34PM -0500, David T. Lewis wrote: >>>>>> On Mon, Feb 10, 2020 at 08:48:49AM -0800, Eliot Miranda wrote: >>>>>>> >>>>>>> Hi David, Hi Release Manager, Hi All, >>>>>>> >>>>>>> On Thu, Feb 6, 2020 at 6:03 PM David T. Lewis <[hidden email]> wrote: >>>>>>>> >>>>>>>> A 64-bit to 32-bit image converter would be a very good thing to have >>>>>>>> in our toolkit :-) >>>>>>> >>>>>>> I got this working this morning. See Cog-eem.398. So to use, >>>>>>> - clone or update an opensmalltalk-vm repository >>>>>>> - cd to the image directory and create a VMMaker image via either >>>>>>> buildspurtrunkvmmaker64image.sh or buildspurtrunkvmmakerimage.sh >>>>>>> - run a converter, e.g. >>>>>>> Spur32to64BitImageConverter new bootstrapImage: 'trunk6'. >>>>>>> (produces trunk6-64.image & trunk6-64.changes) >>>>>>> Spur64to32BitImageConverter new bootstrapImage: 'trunk6-64'. >>>>>>> (produces trunk6-64-32.image & trunk6-64-32.changes) >>>>>>> >>>>>>> Converting a 28Mb 64-bit image into a 22Mb 32-bit image takes 9 seconds on >>>>>>> my 2.9GHz Core i9 MacBook Pro >>>>>>> >>>>>>> >>>>>>> So let's try releasing by converting the 64-bit image into a 32-bit one. >>>>>>> >>>>>> >>>>>> Bravo! I am away now but will try doing an image conversion as soon as >>>>>> I can tomorrow. >>>>>> >>>>>> Thanks Eliot, >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> > > > |
In reply to this post by Eliot Miranda-2
> On 2020-02-11, at 12:51 PM, Eliot Miranda <[hidden email]> wrote: > > My concern is that we present the user with the information before we present them with a dysfunctional app. So I would like us to release an image that is in a state that if the changes file is read only it explains to the user how to correctly install the release, rather than presenting them with gibberish only experts may understand. Of course once the image is configured that warning would go away (the image would no longer be in the “first launch after release” state). > > Does this make sense? I really think changing the launch scripts to copy the image/changes out of the deep pile of directories is the smart thing to do. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin |
> On 11.02.2020, at 22:04, tim Rowledge <[hidden email]> wrote: > > > > >> On 2020-02-11, at 12:51 PM, Eliot Miranda <[hidden email]> wrote: >> >> My concern is that we present the user with the information before we present them with a dysfunctional app. So I would like us to release an image that is in a state that if the changes file is read only it explains to the user how to correctly install the release, rather than presenting them with gibberish only experts may understand. Of course once the image is configured that warning would go away (the image would no longer be in the “first launch after release” state). >> >> Does this make sense? > > I really think changing the launch scripts to copy the image/changes out of the deep pile of directories is the smart thing to do. ACK. Also, my rambling was trying to troubleshoot, not a general guidance for the enduser. -t :) |
> On 2020-02-11, at 1:06 PM, Tobias Pape <[hidden email]> wrote: > >> On 11.02.2020, at 22:04, tim Rowledge <[hidden email]> wrote: >> >> I really think changing the launch scripts to copy the image/changes out of the deep pile of directories is the smart thing to do. > > ACK. Not sure if you're using ACK as in 'acknowledged, ok' or 'ack, split, barf, horrible' ? If you're agreeing with me, fine, let's do it . If not, what are your objections? tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Living proof that nature does not abhor a vacuum. |
> On 11.02.2020, at 22:13, tim Rowledge <[hidden email]> wrote: > > > > >> On 2020-02-11, at 1:06 PM, Tobias Pape <[hidden email]> wrote: >> >>> On 11.02.2020, at 22:04, tim Rowledge <[hidden email]> wrote: >>> >>> I really think changing the launch scripts to copy the image/changes out of the deep pile of directories is the smart thing to do. >> >> ACK. > > Not sure if you're using ACK as in 'acknowledged, ok' or 'ack, split, barf, horrible' ? > If you're agreeing with me, fine, let's do it . If not, what are your objections? in the sense of ACKnowledged :) |
In reply to this post by timrowledge
> On Feb 11, 2020, at 1:05 PM, tim Rowledge <[hidden email]> wrote: > > > > >> On 2020-02-11, at 12:51 PM, Eliot Miranda <[hidden email]> wrote: >> >> My concern is that we present the user with the information before we present them with a dysfunctional app. So I would like us to release an image that is in a state that if the changes file is read only it explains to the user how to correctly install the release, rather than presenting them with gibberish only experts may understand. Of course once the image is configured that warning would go away (the image would no longer be in the “first launch after release” state). >> >> Does this make sense? > > I really think changing the launch scripts to copy the image/changes out of the deep pile of directories is the smart thing to do. +1. Principle #1 it must work out of the box. Principle #2 it must be reasonably straightforward for a user to package an app that works out of the box. > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > "bOtHeR" said Pooh, mistaking the LSD tablet for aspirin > > |
In reply to this post by David T. Lewis
Hi Eliot, On Tue, Feb 11, 2020 at 11:31:47AM -0800, Eliot Miranda wrote: > > Hi David, > > On Tue, Feb 11, 2020 at 6:09 AM David T. Lewis <[hidden email]> wrote: > > > I need some help on this, can someone please test the converted 32-bit > > image on Linux and/or Windows? I'm have problems with my 32-bit libraries > > (I think) and I don't have any time to follow up on it today. Thanks! > > > > The actual image conversion seems to work fine, and it's fast. But I > > don't have a 32-bit VM at the moment, probably due to Linux runtime > > library issues that I don't have time to sort out this morning. > > > > I can confirm that using Cog-eem.400 to convert the 64-bit to 32-bit image > results in a functional result. > Confirming. Brilliant! The resulting image works fine, and I see no obvious problems with it. Let's use this. From the system reporter: Image ----- /home/lewis/squeak/git/opensmalltalk-vm/image/Squeak5.3beta-19335-64bit-32.image Squeak5.3beta latest update: #19335 Current Change Set: Unnamed1 Image format 6521 (32 bit) Virtual Machine --------------- /usr/local/lib/squeak/5.0-202002100903/squeak Open Smalltalk Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2704] Unix built on Feb 10 2020 09:07:27 Compiler: 5.4.0 20160609 platform sources revision VM: 202002100903 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Mon Feb 10 10:03:55 2020 CommitHash: ea79c51 Plugins: 202002100903 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2704 uuid: 882402f6-7412-42ed-8cb4-e490f533f8f3 Feb 10 2020 StackToRegisterMappingCogit VMMaker.oscog-eem.2705 uuid: 35875931-68e1-4c94-a7ec-9cf66d27743d Feb 10 2020 Dave p.s. Extra credit and worldwide acclaim if you do a 16-bit converter ... anything seems possible at this point ;-) |
On Tue, Feb 11, 2020 at 3:48 PM David T. Lewis <[hidden email]> wrote: Hi Eliot, ROTFL :-) Alas... | n | n := 1. objectMemory allObjectsDo: [:o| n := n + 1]. n 536502 So we're an order of magnitude too big these days (Dan did a 48k object stretch version back in the day). _,,,^..^,,,_ best, Eliot |
There is a way to untranslocate an application an access to content outside the read-only mount: https://objective-see.com/blog/blog_0x15.html El mar., 11 feb. 2020 a las 21:43, Eliot Miranda (<[hidden email]>) escribió:
|
In reply to this post by Tobias Pape
As mentioned previously, my claim is that we ought to make the release packages, including the all-in-one if we continue with it, work in such a way that a simple execution of the user-visible script or executable with no image file specified causes the default (preferably configured as read-only) image/changes files to be copied from the depths of the package out to a place more local to the user. The code working out the copy could also do useful things like deciding whether a 32 or 64 bit image ought to be used on those platforms that can handle both, or in the all-in-one - which of course ought to work for 32 or 64 bit in order to warrant that name. It's also the time to choose the newest version of the default image, so we can support reasonably easy updating of the system by installing new image directories. If an image name is passed to the script then clearly that image should be run, with a possible need to check that the image is not the write protected default image. Once an image is chosen we need to select the appropriate vm to run it. This would require using sometihng similar to Dave's imageformat etc logic along with detection of the platform's word size etc. Again, any package we call an all-in-one really ought to include a VM that can run pre-spur images and even pre-cog images. Again, thisis a time to select the newest version of the vm for the same reasons as the image version above. The script should also handle parameters being passed for those options like headless, the sound system to us on unix, debugging options, etc and importantly the startup project url/filename or do-it text. I'm pretty sure we actually have all this stuff scattered around and it is mostly a case of unifying things. And of course, the great joy of the inevitably massive debate about the directory structure required to produce a workable all-in-one . I am most definitely not bash-expert enough to make much progress on this, and I have no knowledge at all of how Windows might need to handle it. The ideal would be the ability to d-click/cli-run/whatever a single item that would start a clean default, up to date image, along with being able to d-click/cli-run/whatever any image and get a suitable system running. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim How do I set my laser printer on stun? |
Free forum by Nabble | Edit this page |