[Cuis] Cuis
Locked
 
|
Hi Juan,
I have been looking for a viable kernel on which to build my future production images, and a friendly community in which to participate. We had tabled the idea of forming a "guild" of nice people and squeak/pharo package developers for those of us who develop packages that we would like to be available to all oss smalltalkers. The problem being that squeak/pharo cores are wildly shifting sands, intent on imposing the ideas of their creators upon us, and they aren't really kernels, nor are they progressing in that direction. However with Cuis being more minimal, the architecture has the potential to be better layered, into kernel, system and application layers. Discussions in irc, seemed to suggest that Cuis might be a viable option. I have lots of questions and ideas. My first question is, do you have a plan? And where would be the forum for discussing plans. Are you on irc? Do you have a process for contributions to the Cuis kernel? In irc #squeak we had an impromptu discussion about making MC1.6 loadable, and providing tools like Sake/Packages and Installer for Cuis. I think that the ethos of Cuis being simple enough to be understandable fits quite well. For example, Installer was originally designed, as a means to an end, to be 1 class, but the "Installer replacement" new kid on the block "Gopher" is 33, and Sake/Packages is 4ish classes but Metacello is 40 classes. By the time Pharo has MC, MC2, Gopher and metacello loaded you are looking at 400 classes in the image just for doing a #fileIn! In contrast Sake/Packages can potentially use a visitor to walk the dependency graph, in order to generate scripts. So "Bob the Builder" can potentially generate and apply a build script to an absolute minimal cuis image using #fileIn: I propose a way forward, to establish a number of initiatives, mini-projects, with the aim of contributing to the "kernel" of Cuis, and dividing up "System" to be a set of loadable modules to make "core/system" layer. I propose prefixing cuis discussions on squeak-dev with [Cuis] so we can filter out our discussions from squeak noise. Is there a cuis-dev list? So as an example, HTTPSocket/Network is conspicuous by its absence. Shall we estabish a project to work on this, or is it in hand? regards Keith |
|
|
2010/1/20 keith <[hidden email]>:
> Hi Juan, > I have been looking for a viable kernel on which to build my future > production images, and a friendly community in which to participate. > We had tabled the idea of forming a "guild" of nice people and squeak/pharo > package developers for those of us who develop packages that we would like > to be available to all oss smalltalkers. The problem being that squeak/pharo > cores are wildly shifting sands, intent on imposing the ideas of their > creators upon us, and they aren't really kernels, nor are they progressing > in that direction. > However with Cuis being more minimal, the architecture has the potential to > be better layered, into kernel, system and application layers. Discussions > in irc, seemed to suggest that Cuis might be a viable option. > I have lots of questions and ideas. > My first question is, do you have a plan? And where would be the forum for > discussing plans. Are you on irc? Do you have a process for contributions to > the Cuis kernel? > In irc #squeak we had an impromptu discussion about making MC1.6 loadable, > and providing tools like Sake/Packages and Installer for Cuis. I think that > the ethos of Cuis being simple enough to be understandable fits quite well. > For example, Installer was originally designed, as a means to an end, to be > 1 class, but the "Installer replacement" new kid on the block "Gopher" is > 33, and Sake/Packages is 4ish classes but Metacello is 40 classes. By the > time Pharo has MC, MC2, Gopher and metacello loaded you are looking at 400 > classes in the image just for doing a #fileIn! Maybe its because they want something more than just filein? > In contrast Sake/Packages can potentially use a visitor to walk the > dependency graph, in order to generate scripts. So "Bob the Builder" can > potentially generate and apply a build script to an absolute minimal cuis > image using #fileIn: > I propose a way forward, to establish a number of initiatives, > mini-projects, with the aim of contributing to the "kernel" of Cuis, and > dividing up "System" to be a set of loadable modules to make "core/system" > layer. I propose prefixing cuis discussions on squeak-dev with [Cuis] so we > can filter out our discussions from squeak noise. Is there a cuis-dev list? > > So as an example, HTTPSocket/Network is conspicuous by its absence. Shall we > estabish a project to work on this, or is it in hand? It would be cool to have an 'official' Network package, maintained separately, which could be used by all existing Squeak forks. Not just network, but it is good to start from. I was always behind the idea, that image should be splitted on multiple packages, and changes to them should not be privatized by a single fork. I am not sure, however, if squeak/pharo communities ready for such ideological shift. Your work on LPF proven that it is possible to create an artifact, which can be loaded and used on multiple Squeak versions and its forks. I think that we still lack of infrastructure, for making such things happen. I found, that GitHub (github.com) is a very interesting approach on how to tame a 'forking chaos' into something productive, where each party wins from cross-pollineation. > regards > Keith > -- Best regards, Igor Stasenko AKA sig. |
|
|
Sorry Igor, don't be ridiculous. Stop talking sense, I warn you, you are wasting your time. If you cant get a simple package like SUnit, or an essential package like MC to be adopted in common across forks by the decision makers, even when you are doing all the work for them, you have no hope whatsoever.
That ship sailed, at the end of the day the best kernel, and I mean kernel, that can migrate to spoon, providing remote development of my seaside based servers, will win for me. All I am looking for is a home for my codebase, and neither squak, not pharo is it.
there is a squeak community? where? (...and other rude comments deleted...)
Apparently not valued by "the community" enough to use it.
Really, you don't say, and I spent 3 years working on this infrastructure for what? No one wants to use it.
Keith |
|
|
In reply to this post by keith1y
Hi Keith,
keith wrote: > Hi Juan, > > I have been looking for a viable kernel on which to build my future > production images, and a friendly community in which to participate. > > We had tabled the idea of forming a "guild" of nice people and > squeak/pharo package developers for those of us who develop packages > that we would like to be available to all oss smalltalkers. The > problem being that squeak/pharo cores are wildly shifting sands, > intent on imposing the ideas of their creators upon us, and they > aren't really kernels, nor are they progressing in that direction. > > However with Cuis being more minimal, the architecture has the > potential to be better layered, into kernel, system and application > layers. Discussions in irc, seemed to suggest that Cuis might be a > viable option. Good! > I have lots of questions and ideas. > > My first question is, do you have a plan? Not really. But I'll keep developing Cuis along the ideas described in http://www.jvuletich.org/Cuis/Index.html . > And where would be the forum for discussing plans. So far, it is here. > Are you on irc? No. > Do you have a process for contributions to the Cuis kernel? There have been few contributions to Cuis so far. The current process is: you send them to me, I review them, and if I like them, I load them. Before spending a significant amount of time doing something you'll like to see included, please ask me. This will reduce the risk of frustration for not seeing your stuff included. > In irc #squeak we had an impromptu discussion about making MC1.6 > loadable, and providing tools like Sake/Packages and Installer for > Cuis. I think that the ethos of Cuis being simple enough to be > understandable fits quite well. For example, Installer was originally > designed, as a means to an end, to be 1 class, but the "Installer > replacement" new kid on the block "Gopher" is 33, and Sake/Packages is > 4ish classes but Metacello is 40 classes. By the time Pharo has MC, > MC2, Gopher and metacello loaded you are looking at 400 classes in the > image just for doing a #fileIn! > > In contrast Sake/Packages can potentially use a visitor to walk the > dependency graph, in order to generate scripts. So "Bob the Builder" > can potentially generate and apply a build script to an absolute > minimal cuis image using #fileIn: Personally I'm not really interested in automatic building of images. But I understand others might be, and I welcome your initiative. > I propose a way forward, to establish a number of initiatives, > mini-projects, with the aim of contributing to the "kernel" of Cuis, > and dividing up "System" to be a set of loadable modules to make > "core/system" layer. So far I'm quite happy with the base image being monolithic. I'd like loadable packages to be used for optional stuff. What would be the benefit of splitting the base system that way? How long would it take to have a usable system again? > I propose prefixing cuis discussions on squeak-dev with [Cuis] so we > can filter out our discussions from squeak noise. Is there a cuis-dev > list? There is not a Cuis specific mail list. A [Cuis] prefix is a good idea. > > So as an example, HTTPSocket/Network is conspicuous by its absence. > Shall we estabish a project to work on this, or is it in hand? For a project I'm working in, I have SWHttp, Yaxo, a very reduced version of OSProcess, UnixDomainClientSockets and UriFramework. I'll make them available soon. UriFramework is especially nice, handling downloads, local cache, up to date verification, etc. > > regards > > Keith > Cheers, Juan Vuletich |
|
|
I wasn't thinking of making the image non-monolithic, merely defining some useful architectural boundaries tidying it up a bit. In this thought I am suggesting that a monolithic image that contains packages which can be removed or improved, can be functionally equivalent to a kernel image that you need to load things into to be useful. The monolithic image is far easier to distribute and discuss. I thought you would approve on the basis that System has a lot of optional stuff. If we had a package management system (I have christened it Simplercello in anticipation) then tools such as the Transcript, Workspace etc, would be candidates for management in an external package. My first project is to implement the "multiple update streams" concept envisaged by gorans DeltaStreams initiative. This will be released as a standalone class SystemUpdates, in the category/package System-Updates , and it is intended to complement the use of the bzr repository as a basis for sharing work. Keith |
|
|
keith wrote:
> > ... > > I thought you would approve on the basis that System has a lot of > optional stuff. If we had a package management system (I have > christened it Simplercello in anticipation) then tools such as the > Transcript, Workspace etc, would be candidates for management in an > external package. I don't see an advantage in having Transcript and Workspace as external packages. So I ask again: What would be the benefit of splitting the base system that way? How long would it take to have a usable system again? > > My first project is to implement the "multiple update streams" concept > envisaged by gorans DeltaStreams initiative. This will be released as > a standalone class SystemUpdates, in the category/package > System-Updates , and it is intended to complement the use of the bzr > repository as a basis for sharing work. > > Keith Sounds interesting. But please note that I'm not ready to leave the building of the Cuis release to an automated tool. And I'm also not willing to leave the model where I can check for quality any code to be included for one where there is no central (human) control. Cheers, Juan Vuletich |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |