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

[Juan Vuletich]

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.

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

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

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

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

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

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

>
> Best Regards,
>
> Gerald

Thanks,

-- 
Juan Vuletich
cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich