<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hi Hilaire, Thanks for your comments. One possible point is that the needs of end users using an app may not be the same those of developers using a Smalltalk system. In any case, I'm building the Cuis 6.2 release today. I hope everybody gets the chance to try it. May be many find it is a reasonable solution. More on this later today. Thanks, On 12/24/2023 3:03 PM, Hilaire Fernandes via Cuis-dev wrote: <blockquote cite="mid:2b14b1aa-55f6-4d80-9015-d647f72c8783@free.fr" type="cite"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> Hi Juan & al, I am just catching up. This is always a good idea to ease the start-up experience to new Cuis-Smalltalk users. I am sure it will have important impact. I tested on Ubuntu 23.10, it works smoothly. Regarding all-in-one application, I have been using it a lot in the past with Dr. Geo, then at some point stopped using it. I stopped for technical reasons, but then I realized there were also end user reasons to stop using it. Indeed, it adds complexity that does not serve the end user. For example, a Linux user will see VM, scripts for the Windows user. Will this Linux user uses this same folder structure to execute Cuis on a Windows machine? No, because he's using Linux. Then it does not scale very well. Will you add VM for Linux on Arm, on RiscV? Then we can argue the same with image, why both 64bits and 32bits, the end user will only use one variant of it. The truth about all-in-one application is it makes the life easier for the developers and people deploying end-user applications, like me with DrGeo. You just need to upload one package and that's it. In a such momentum, we should realize it is not a good sign, we are not serving the end-user first, but ourself. What will be make life easier for end user is an archive to download containing the VM and the image it needs. That's it. I will use your CuisExperiment as a base to automate the building of Cuis-Smalltalk distributions with various combination of VM binary and image (32|64 bits). You will have MacIntel, MacARM, Windows, LinuxIntel, LinuxArm, LinuxRiscV associated with appropriate image and VM. Does not Github offer service to automate packages built? I have just migrated DrGeo repository to Github, I will take a look to that (<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://github.com/hilaire/drgeo">https://github.com/hilaire/drgeo</a>). Then you will have a set up that could scale more easily to any additional needs like embedded system. And you will be free to arrange the distribution in a way that fit the host (Mac is a bit special) I feel it could also add visibility to Cuis-Smalltalk to have these different distributions, it will talk more specifically to the end user and will have a wow effect. Compare all-in-one and LinuxIntel64 names. The later one is crystal clear, not the former one. Regarding the current folder structure, I will try to hide the complexity a bit more. I will have only two top level folders. To illustrate, this is what a Linux user sees when entering the DrGeo app folder: DrGeo ├── ChangeLog ├── DrGeo.sh ├── License.txt ├── README ├── Resources ├── transcript.txt └── VM Even the VM should not be visible to be honest. It should be moved in the Resources folder. Nevertheless, all-in-one distribution will be already an important progress and of course my opinion can be completely discarded without harm. Have a nice day. Hilaire <div class="moz-cite-prefix">Le 24/12/2023 à 13:28, Juan Vuletich via Cuis-dev a écrit : </div> <blockquote type="cite" cite="mid:658823D9.2050006@cuis.st"> The upcoming 6.1 release will be the first of a new series of releases. We'll be doing a "stable release" that will later only include critical fixes, every six months. This will be done in addition to our usual rolling release, and it will follow the RedHat Linux release process. The stable releases are intended for: - People who don't want to deal with constant updates and breakage, and prefer to port their code to a new system from time to time. - Building End User Applications. - Casual users, who just want to take a look at Cuis. - People new to Smalltalk. - Students who will be using Smalltalk for a semester. For many of these use cases, I want to include only consistently high quality code. So every package included needs to be currently in use, tested, well maintained, etc. We'll need to work out a way to deal with additional packages, from Cuis-Smalltalk-Dev repo, other repos from Cuis-Smalltalk organization, and other repos outside of it. This is just an initial version. It will grow. Thanks, </blockquote> <pre class="moz-signature" cols="72">-- GNU Dr. Geo <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu.org/s/dr-geo/">http://gnu.org/s/dr-geo/</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://gnu-drgeo.blogspot.com/">http://gnu-drgeo.blogspot.com/</a></pre> </blockquote> <pre class="moz-signature" cols="72">-- 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</pre> </body> </html>