Hey,
now entering the field of Metacello it seems, that somehow it's getting into a dark side of Smalltalk - and I am used to ENVY for more than 10 years ! I just would like to build a configuration saying. I'm a configuration for X (version 1) and I need a prerequisites of B (version 1) and C (version 2). Do I really have to read 47 pages of documentation to realize this simple wish ??????????? I do not ask for GUI support (though it would be nice). Any hint to get it faster ...... and yes: I'm using Jade. I actually would like to see Monticello/Metacello working before GLASS goes to github and there even more stuff is not working. And before I forget: Jade should support that ... -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Fri, Jun 6, 2014 at 10:12 AM, [hidden email] <[hidden email]> wrote: Hey, Hi Marten, Not sure if dark, but complex yeah. For me, managing, versioning, and releasing software, dependencies resolution, multi Smalltalk environment, etc, has always been a complex area. I think no matter which tool, I usually find this complex.
Now you have documentation and complain? Ohh boy, I guess you are used to have so much documentation. Lucky guy. Now seriously, I would read it if I were you. It does have some GUI support, but in Pharo. Check Versionner project. Best, Any hint to get it faster ...... and yes: I'm using Jade. Mariano http://marianopeck.wordpress.com _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by marten
There is a tutorial that you can run in a Pharo image (your GemTools image should work). It should give you enough information to be dangerous:) On Fri, Jun 6, 2014 at 6:12 AM, [hidden email] <[hidden email]> wrote: Hey, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Am 06.06.2014 16:00, schrieb Dale Henrichs:
> There is a tutorial that you can run in a Pharo image (your GemTools > image should work). It should give you enough information to be dangerous:) > Downloaded it, tried it - but -- well it does not work. Hmm, I actually I did not expect it to work out of the box - that's the reality of the squeak world (Hello Joachim :-))). That's all a very unstable (and serious bad) situation. We have GemTools, we have Jade - that the state of today. We have 3.2.0 and we should have a software base working on these platforms (actually we have that - the original delivered extend). When leaving this base it becomes an adventure. In one of the tuturials it is said: do a copy of the MetacelloTemplate class - even this simple sentence becomes a problem, if the tools do not support creating a copy of a class and if there is not a class with the same name as mentioned in the tutorial. That means for me: I stay away from all public repositories and keep/maintain my own packages (Zinc and Neo-JSON). I just use Monticello packages from my own http sources and write my own loading stuff - that's of course a disaster in terms of software reuse. A pretty angry, Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Jun 6, 2014, at 8:56 AM, [hidden email] wrote:
> Am 06.06.2014 16:00, schrieb Dale Henrichs: >> There is a tutorial that you can run in a Pharo image (your GemTools >> image should work). It should give you enough information to be dangerous:) >> > > Downloaded it, tried it - but -- well it does not work. > > Hmm, I actually I did not expect it to work out of the box - that's the > reality of the squeak world (Hello Joachim :-))). > > That's all a very unstable (and serious bad) situation. > > We have GemTools, we have Jade - that the state of today. We have 3.2.0 > and we should have a software base working on these platforms (actually > we have that - the original delivered extend). When leaving this base it > becomes an adventure. > > In one of the tuturials it is said: do a copy of the MetacelloTemplate > class - even this simple sentence becomes a problem, if the tools do not > support creating a copy of a class and if there is not a class with the > same name as mentioned in the tutorial. > > That means for me: I stay away from all public repositories and > keep/maintain my own packages (Zinc and Neo-JSON). I just use Monticello > packages from my own http sources and write my own loading stuff - > that's of course a disaster in terms of software reuse. > > > A pretty angry, > > > Marten Feldtmann As you note, GemStone/S does work quite well in its “native” environment—scripting command-line tools (shell and Topaz) and source code in text files (cvs, svn, git, …). The problems come when we want free Envy-like tools to work in multiple dialects (including free ones). The questions then become: (1) What should be done? (2) Who should do it? (3) Who should pay for it? Until someone comes up with a good answer to #3, I don’t see much change from the current (slow?) progress of improvement. James _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by marten
Did you use Squeak or Pharo - which version? I mentioned the GemTools image specifically because I am pretty certain that the infrastructure hasn't changed out from under the original tutorial. The tutorial that I expected you to use is browser based and you select the lesson1 method and perform doits ... there are Metacello tests that are supposed to ensure that the expressions in the lessons will run without errors ... I guess I neglected to add a test for "copy class" to my tutorial ... I also built a tutorial based on the Pharo Help Browser ... to my knowledge noone has ever used it and in the more recent versions of Pharo, I'm not even certain it works anymore ...
Frankly, the arc of my major open source smalltalk projects: Metacello, FileTree, git, github, tODE are all aimed at trying to address these types of issues ... Before Metacello it was not possible to load a project without sending email to the developer and asking them in what order the packages should be loaded and which other projects the packages depended upon, followed by another email to another developer on another mailing list...
Before FileTree it was not possible to store/share smalltalk code on disk. Once you can store/share smalltalk on disk you can use git. When you use git, you can store other artifacts like documentation, scripts, images, etc.
When you store code and documentation together, the code and documentation can be updated together. When you use git you can use github where you can easily share your code with other users and it is PRACTICAL for large numbers of developers to contribute to the project ...
When you use git, the job of Metacello is greatly simplified. I equate Monticello packages to RCS (where you can only manage the versions for a single file). I equate Metacello (without git) to CVS, where you manage collections of files using an external database ... your ConfiguratioOf... is a data base of versions where the specific package versions are associated together in a single version... with git it no longer becomes necessary to manage the collection of files from within Metacello ... git does that for you as well as a lot more ...
With git you only need to define a Metacello baseline: specification of package and project dependencies only...a much simpler job and much simpler to document. When you use git, you have to have git integrated into the development environment ...
Before tODE you had to do all of your git manipulation from a separate shell window ... So until I can get tODE out the door, I can't ask people to use git for their new projects. When tODE goes out the door, I can focus my efforts on shoring up the other pieces of the infrastructure ... WHICH WILL BE BUILT ON GIT AND GITHUB...
I released Metacello in 2009 so I've been on a 5 year crusade ... so at the end of the day, I would say that I felt your anger and frustration 5 years ago and have been working hard to solve the problems as they come up ...
I've just create the ServiceVM project on github[1]...it is still very raw as I have simply cobbled together the pieces of the project and brought them together in one spot: 1. documentation from google[2] into the ServiceVM project readme[3]. 2. scripts from here[4] and here[5] into the ServiceVM bin directory[6]. 3. copied 4 monticello packages ([7], [8], [9], [10]) from two different
monticello repositories into the project repository[11] 4. pulled in the tODE scripts that I've been using to work with the servicevm into the tode directory[12]. 5. if you look at the end of adaptors script[13] you will see that there is
a man page included in the script documenting the script api. There will be a couple more scripts before I am done ... 6. this is only the start ... I expect to include an install shell script that
will put the shell scripts in the right spot...and that install script will be initiated from within the tODE environment... So here's a very simple project that was spread out over 3 different web sites that should have been located in one location with all of the artifacts and supporting scripts avaialalbe in a single versioned location...
I'm close ... We're close ... Dale On Fri, Jun 6, 2014 at 8:56 AM, [hidden email] <[hidden email]> wrote: Am 06.06.2014 16:00, schrieb Dale Henrichs: _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by marten
On 06 Jun 2014, at 17:56, [hidden email] wrote: > That means for me: I stay away from all public repositories and > keep/maintain my own packages (Zinc and Neo-JSON). I just use Monticello > packages from my own http sources and write my own loading stuff - > that's of course a disaster in terms of software reuse. If we each stick to our own patches and solutions to open source projects, we can each experience the same frustrations individually. I'm looking forward to that. > A pretty angry, I think we all encounter these moments of frustration, but I'm pretty sure anger (or ranting, for that matter) has never brought me any solution, on the contrary. To me, and I guess many others, the balance is still very much on the positive side. Yes, there are headaches and frustrations, but they just don't outweigh all the benefits we can get in return. For all projects I'm involved in, Metacello solves more issues that it creates. Take a look at simple Metacello configurations to get started. The configuration of Zinc is pretty simple. Read the doc, ask questions, move forward. As a community, we can help each other move forward. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Administrator
|
In reply to this post by marten
Hi Marten, I have worked with ENVY since 1994. I understand your pain. Until recently, I considered ENVY to be the best version control system I had ever seen (bearing in mind the limitations on supported artefacts). But I have to say that I think Git now is superior in most respects. I can live without every edit to every method as a separate artefact. And I could make Git do that, if I wanted to bother. I have watched Dale's development of tODE over the last year and a half, and I can say that I am really excited by what I see. And, it's almost here! Learning from Dale, I understand how much Git and GitHub will simplify things for us in terms of sharing, versionning, and keeping track of everything. tODE and Git is going to be an amazing improvement. Montecello and Metacello work, for what they were designed to do. Since they only address a subset of our real requirements, there are "challenges" when using them. The sooner we can move to tools better designed to meet our requirements, the better off we will be. One thing you might try is to say what version of GS you have and ask the people on this list what configuration they have that works for that version. Perhaps there is someone who has already gone through all the hassles you are seeing and have already solved the problems. And of course, if there are specific tools beyond "GemStone" and "Seaside" you want to use, cite them in your request. Good luck! Richard |
Free forum by Nabble | Edit this page |