[Cuis-dev] [Ann] First sketch of Cuis 6.1 release - Please REVIEW and TEST!

[Luciano Notarfrancesco]

Juan, thanks for doing this, it will make it much easier for people to try
Cuis or any of our projects in Cuis. I didn’t test the experiments yet,
I’ll test it today and see if I have any comments. Right now I just want to
agree with Gerald that UserPrefs.txt seems to need some more thought. The
name of the file could be better, but I’m not even sure we really need a
configuration file, perhaps we could use a startup script for forcing
preferences on any image loaded instead of a configuration file.

On Fri, Dec 22, 2023 at 16:44 Gerald Klix via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi Juan,
>
> still one hour left to answer your mail.
>
> I discovered that Cuis now automatically creates a UserPrefs.txt
> file. I am not sure whether this is really clever.
> I faintly remember some support cases, where you directed
> users to delete that file, because their changes where not persisted
> in their images. Now it is persistent, but all images use the same
> settings.
> Users accustomed to the old behavior will be baffled.
>
> Please don't get me wrong, personally I can live with that change,
> but it's just another feature that needs to be documented, explained
> and supported (by answering questions).
>
> Please see below for my answers.
>
>
> On 12/21/23 10:22 PM, Juan Vuletich wrote:
> > Hi Gerald
> >
> > (inline)
> >
> > On 12/21/2023 5:20 PM, Gerald Klix via Cuis-dev wrote:
> >> Hi Juan,
> >>
> >> please see below.
> >>
> >> On 12/21/23 3:03 PM, Juan Vuletich wrote:
> >>> Hi Gerald,
> >>>
> >>> On 12/21/2023 9:04 AM, Gerald Klix via Cuis-dev wrote:
> >>>>
> >>>> Hi Juan,
> >>>>
> >>>> works nicely as long as one does not want to pass arguments
> >>>> to the image itself. Obviously the RunCuisOnLinux.sh script does
> >>>> not account for this case.
> >>>
> >>> With this new folder structure and included VMs, the goal is to ease
> >>> the experience for new and casual users, while giving experienced
> >>> users the flexibility they need to set up the environment(s) that
> >>> works best for them.
> >>>
> >>> The Linux script (copied from Squeak) is already complex enough...
> >>> Advanced users will be happy to cook their own, I hope.
> >> Fair enough. The script needs bash and sudo; it should be replaced by
> >> something simpler.
> >> Maybe a simple image, like your hello world demo, that starts the
> >> actual image is better.
> >> This approach would be a clear case of eat your own dog-food ;-}
> >> (
> https://lists.cuis.st/mailman/archives/cuis-dev/2023-October/008099.html)
> >>
> >
> > I don't see the need for an "official" way to do that. Expert users
> > can set up their environment as they prefer. In other words, that's a
> > nice idea, but doesn't need to be part of the Cuis core. More like a
> > community developed optional feature / workflow. We'd need to be sure
> > that Base Cuis supports those developments, by making them possible.
> IHMO it will make sense for non version controlled Cuis distributions,
> like CuisUniversity or Haver.
> >
> >>
> >>>
> >>>> I suggest that something like this:
> >>>> ./RunCuisOnLinux.sh -- -r
> >>>> ~/smallworks/cuis/Environments/HaverOnCuis/haver/Haverize.pck.st
> >>>> should do the job. Other solutions will lead to the incorporation
> >>>> of knowledge about the valid image option names into
> >>>> the script.
> >>>>
> >>>> I still have problems creating a Haver image with Cuis 6.1, but
> >>>> this might
> >>>> be due to the fact, that I did not adopt Haver to your latest
> >>>> Cuis 6.0 changes.
> >>>>
> >>>> Where in your structure should other Cuis packages and third-party
> >>>> packages be stored?
> >>>
> >>> They should go (as usual) in directories that are siblings of the
> >>> main Cuis directory and repo, and subdirectories of a main Project
> >>> directory, like we suggest in the GettingStarted.md file.
> >> I would love to have the Cuis checkout separated from my project.
> >> Additionally It should
> >> be possible to reuse the checkout for more than one project.
> >
> > Some people already asked for handling more than one Cuis folders
> > (including image, etc) for one project. Others, like you want the
> > opposite: use a single Cuis folder for several projects. So we need a
> > way to support these different scenarios. (see below)
> For Unix, it should be easy to distribute a shell script that creates
> symlinks to all of the repos
> in an the current directory. I don't see a portable solution for windows.
> >
> >>>
> >>>> I suggest a solution similar to the directory structure of an
> >>>> unpacked Haver release zip file.
> >>>> For reference purposes I attached a directory listing
> >>>> of an unpacked Haver distribution. Please note
> >>>> that this distribution is machine/OS and byte-size specific.
> >>>>
> >>>>
> >>>> Keep up the good work and Best Regards,
> >>>>
> >>>> Gerald
> >>>
> >>> I'm not sure about the advantages over what we've been suggesting
> >>> users to do, in GettingStarted.md. Could you elaborate?
> >> The main advantage is that all packages that are loadable are beneath
> >> on sub-directory;
> >> easy to search, easy to find for new users and easy to fill with some
> >> scripted git clone invocations.
> >> With this scheme there is need to climb up the directory hierarchy
> >> while searching for packages.
> >> Especially the caveat from the getting started document
> >
> > One point to have in mind is that inside the Cuis repo directory, no
> > files from other repos should be stored. The reason is that most users
> > would no longer know what is part of the Cuis distribution and what is
> > not.
> I forgot about that point, because I created a bunch of symlinks to the
> git repos in the parent directory
> of Haver's development directory.
>
> I also became aware, that I am looking at this layout from a different
> perspective:
> I am thinking of distribution contained in a ZIP-file, without any
> version controlled files.
> So yes, If you want to distribute this using git, not polluting the repo
> with user files
> makes perfect sense.
> >
> >>
> >> "Note: Please do create a new folder, and don't use an existing one.
> >> Cuis looks for packages to load in sibling folders to
> >> Cuis-Smalltalk-Dev, and using an existing folder could mean trying to
> >> load conflicting, outdated versions of packages. Keeping each Cuis
> >> project in a separate folder is an easy way to avoid such problems."
> >>
> >> would be mote. IHMO this change will simplify the users' and your life.
> >> BTW: AFAIR the package downloader already uses a single directory for
> >> downloaded packages.
> >>
> >
> > What follows is very new, and not yet documented:
> >
> > #userBaseDirectory: Directory for user generated files.
> > #cuisBaseDirectory: Usually repo. Common parent of
> > #smalltalkImageDirectory, CoreUpdates/ and Packages/.
> > #projectBaseDirectory: #cuisBaseDirectory parent.
> >
> > #userBaseDirectory is configurable via commandline:
> >
> > No additional argument
> > DirectoryEntry userBaseDirectory.
> > /Users/juanvuletich/Cuis-Smalltalk/Cuis-Smalltalk-Dev-UserFiles .
> >
> > -udIsBase
> > DirectoryEntry userBaseDirectory.
> > /Users/juanvuletich/Cuis-Smalltalk/Cuis-Smalltalk-Dev .
> >
> > -ud ZZZZ
> > DirectoryEntry userBaseDirectory.
> > /Users/juanvuletich/Cuis-Smalltalk/Cuis-Smalltalk-Dev/ZZZZ .
> >
> > -ud ../ZZZZ
> > DirectoryEntry userBaseDirectory.
> > /Users/juanvuletich/Cuis-Smalltalk/ZZZZ .
> >
> > -ud /Users/juanvuletich/ZZZZ
> > DirectoryEntry userBaseDirectory. /Users/juanvuletich/ZZZZ .
> >
> > Packages are looked for in the #projectBaseDirectory. Perhaps we could
> > make this configurable via cmdline argument too.
> I have seen some of these changes in Cuis 6.0, AFAIR I had to adapt
> Haver's image saving code to it.
> I will look into this after my holiday.
> I should adapt Haver's persistent stuff, like persistent workspaces, to
> use DirectoryEntry>>#userBaseDirectory for it's OODB files.
>
> One side issue: Is there any way to move UnicodeData.txt away from the
> image directory?
> Users may be tempted to clean up their image directory and delete non
> image/changes stuff,
> with rather disastrous results. (After some hair-tearing I created a
> symlink to this file in Cuis' repo,
> to make Cuis work again in Haver's project directory)
>
> >
> >>
> >> While I am already nitpicking:
> >> Some of the directory names you choose are not ideal (from a Linux
> >> standpoint)
> >>
> >> CoreUpdates:
> >> Should be CuisCoreUpdates; it's highly Cuis specific. I am aware that
> >> this directory is hard-coded in the image.
> >
> > Everything inside the Cuis repo == #cuisBaseDirectory is highly
> > specific! I don't think we'd prefix every Cuis file with 'Cuis'. What
> > do others think?
> Yes of course. Haver's distribution does not use prefixes. That is OK
> for me (as I said, this is nitpicking (on a high level))
> >
> >>
> >> CuisVM.app:
> >> Should be OpenSmalltalkVM.app. I am aware that that a shorter
> >> MacOS application name is beneficial. Nevertheless this VM will also
> >> run squeak images.
> >
> > That is true, but this is intended to be a Cuis distribution. For
> > instance, I integrated both the Mac ARM and the Mac Intel into a
> > single .app file, that in its Info.plist file points to
> > CuisImage/Cuis6.1.image. I also integrated LinuxX64 and WindowsX64 VMs
> > in there. And I have only tested all this with Cuis. So, if people
> > wants to use parts for something else, they are more than welcome to
> > do so, under their own responsibility.
> >
> > Additionally, this is the file Mac users will start. The three startup
> > files, 'CuisVM.app', 'RunCuisInLinux.sh' and 'RunCuisInWindows' are
> > the only three that really need 'Cuis' as part of the name, as we want
> > novice users to easily know that they need to run one of them
> Now that I have slept over this, I think it comes in handy
> for Haver. As mentioned in various mails, I modified OSVM's Linux version
> to handle additional mouse-buttons and some other things.
>
> I will distribute my VM version as HaverVM.app, using
> the MacOS APP directory layout.
> > .
> >
> >>
> >> Packages:
> >> For reason of consistency it should read CuisPackages, again all
> >> of these packages are Cuis specific.
> >
> > Same as CoreUpdates. Do others see an issue here?
> Not me.
>
>
> Best Regards,
>
> Gerald
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20231222/06fe1af5/attachment.htm>