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

[Gerald Klix]

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