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

[Gerald Klix]

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 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.
>
>> 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

"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.


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.

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.

Packages:
For reason of consistency it should read CuisPackages, again all
of these packages are Cuis specific.


Best Regards,

Gerald