Hi fellas!
Ok, I have just gotten a "go" on building a pilot for a specialized issue tracker for a customer. I am going to use Seaside+Magma and wonder:
1. Which base Squeak is "best"? 3.7 or 3.8? What combo do you use?
2. I was aiming for 3.8+Seaside2.6+latest Magma - reasonable? I also am aware of Brent's combo-page on the wiki - will try starting using that I think.
Well, don't have much questions at this point, but will get back to you. It will be real fun using Magma and Seaside.
regards, Göran
On 12/22/05, goran@krampe.se goran@krampe.se wrote:
Ok, I have just gotten a "go" on building a pilot for a specialized issue tracker for a customer.
Congrats :)
- Which base Squeak is "best"? 3.7 or 3.8? What combo do you use?
I´ve been using 3.8 for most of the year. It works well.
- I was aiming for 3.8+Seaside2.6+latest Magma - reasonable?
Is 2.6 already "official"? I´m still on 2.5 but I'm known to be sloppy tracking versions :)
I think using latest Magma is safe (although I'd really like some release management around Magma... MCC anyone?)
- Which base Squeak is "best"? 3.7 or 3.8? What combo do you use?
3.8
- I was aiming for 3.8+Seaside2.6+latest Magma - reasonable?
We use the latest 2.6alpha
I think using latest Magma is safe (although I'd really like some release management around Magma... MCC anyone?)
Mm, We have used Seaside + Magma for a production system. Works liek a charm.
Please have a look at this page:
http://minnow.cc.gatech.edu/squeak/5817
Feel free to ask for help
Brent
On 12/22/05, Brent Pinkney brent.pinkney@aircom.co.za wrote:
Mm, We have used Seaside + Magma for a production system. Works liek a charm.
Yes, but I would like to see a sort of snapshot point that says "this is stable, base your production work on this". So that newer versions may implement more advanced/experimental stuff, etcetera. At the moment, we just have to grab the latest version and hope that nothing experimental is in there which might interfere with production. This also puts a burden on development for precisely the same reason - because people grab the latest, it's hard to add more experimental stuff to the repository.
On Thursday 22 December 2005 14:14, Cees De Groot wrote:
Yes, but I would like to see a sort of snapshot point that says "this is stable, base your production work on this".
Is there a way to do this with Monticello and SqueakSource - I see there is a tab for releases which is not used.
Chris has blessed me as a co-developer of Magma, but I am not overly familiar with Monticello.
It would be appreciated it you could suggest a light-weight mechanism you would like to use for this.
Brent
On 12/22/05, Brent Pinkney brent.pinkney@aircom.co.za wrote:
It would be appreciated it you could suggest a light-weight mechanism you would like to use for this.
The lightest-weight mechanism I know of is MonticelloConfigurations. But I'm not sure whether kilana.unibe.ch has already been updated to accept .mcm files.
.mcm files are simply a listing of repositories and .mcz names that comprise a overall configuration. Once you get the concept, they're very easy to work with (check my introduction recently on squeak-dev for details).
Hi guys!
Cees De Groot cdegroot@gmail.com wrote:
On 12/22/05, Brent Pinkney brent.pinkney@aircom.co.za wrote:
It would be appreciated it you could suggest a light-weight mechanism you would like to use for this.
The lightest-weight mechanism I know of is MonticelloConfigurations. But I'm not sure whether kilana.unibe.ch has already been updated to accept .mcm files.
.mcm files are simply a listing of repositories and .mcz names that comprise a overall configuration. Once you get the concept, they're very easy to work with (check my introduction recently on squeak-dev for details).
Right, I agree. But it would also be nice if SM could hold the latest stable release too, you can show that using:
1. Categories. There is the "stable", "alpha", "beta" etc. 2. "published" - the checkbox on a release to show that it can be "trusted" to not go away.
Hmmmm, I notice the "Magma server" and "Magma client" SM packages seem odd - the release in there seems to have a faulty Seasidish URL in it instead of a proper ref to a specific .mcz.
And by the way - I should add support for .mcm files in SM.
regards, Göran
The lightest-weight mechanism I know of is MonticelloConfigurations. But I'm not sure whether kilana.unibe.ch has already been updated to accept .mcm files.
Sorry, not yet, but it will be by the beginning of the next year when we move to a brand new server.
- I was aiming for 3.8+Seaside2.6+latest Magma - reasonable?
Is 2.6 already "official"? I´m still on 2.5 but I'm known to be sloppy tracking versions :)
I am always using the latest 2.6 versions. Of course there are a couple of things that are still experimental, but when having problems these are the version that are fixed the quickest as well. I know that Avi (DabbleDB) and myself (Magritte, Pier, and a few applications at netstyle.ch) are using the latest 2.6 versions without problems in productive applications.
Lukas
Hi Lukas!
Lukas Renggli renggli@gmail.com wrote:
- I was aiming for 3.8+Seaside2.6+latest Magma - reasonable?
Is 2.6 already "official"? IŽm still on 2.5 but I'm known to be sloppy tracking versions :)
I am always using the latest 2.6 versions. Of course there are a
Ok, will do too.
couple of things that are still experimental, but when having problems these are the version that are fixed the quickest as well. I know that Avi (DabbleDB) and myself (Magritte, Pier, and a few applications at netstyle.ch) are using the latest 2.6 versions without problems in productive applications.
Lukas
Sounds good. Any other Seaside "addons" I should pick up from the beginning? Scriptaculous? Shore components might be useful I guess.
regards, Göran
couple of things that are still experimental, but when having problems these are the version that are fixed the quickest as well. I know that Avi (DabbleDB) and myself (Magritte, Pier, and a few applications at netstyle.ch) are using the latest 2.6 versions without problems in productive applications.
Lukas
Sounds good. Any other Seaside "addons" I should pick up from the beginning? Scriptaculous? Shore components might be useful I guess.
Yeah, Scriptaculous is the way to go for AJAX applications, however this requires that you are using the new canvas framework for rendering. Shore components are useful if you want to use a ready-made design and some more sophisticated standard components.
Mewa or Magritte might be interesting for you too, if you plan to do a lot with forms and dialogs. Both frameworks help to build and validate forms automatically. Since Magritte is described with its own meta-framework, it is even possible to let the users customize and build their own forms from the web.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
Hi Lukas!
Lukas Renggli renggli@gmail.com wrote:
couple of things that are still experimental, but when having problems these are the version that are fixed the quickest as well. I know that Avi (DabbleDB) and myself (Magritte, Pier, and a few applications at netstyle.ch) are using the latest 2.6 versions without problems in productive applications.
Lukas
Sounds good. Any other Seaside "addons" I should pick up from the beginning? Scriptaculous? Shore components might be useful I guess.
Yeah, Scriptaculous is the way to go for AJAX applications, however this requires that you are using the new canvas framework for rendering. Shore components are useful if you want to use a ready-made design and some more sophisticated standard components.
Right. I have looked around at the AJAX-techs (Mochikit, Dojo etc) to try to get a sense of what projects have momentum etc. Lots of different opinions. Scriptaculous/Prototype seems to get a bit of critique since it is a bit... "incompatible" with other packages (IIRC). Dojo seems to get a lot of positive remarks about the base architecture/design - but it is not really available yet. But I did find the demos quite impressive (you need to dig a bit to find them). Also read a bit about Mochikit etc.
Anyway, I don't know much about all these - and since Avi and others have been putting work into Scriptaculous that is probably what I will go with.
Mewa or Magritte might be interesting for you too, if you plan to do a lot with forms and dialogs. Both frameworks help to build and validate forms automatically. Since Magritte is described with its own meta-framework, it is even possible to let the users customize and build their own forms from the web.
In fact - this is exactly what we want to be able to do among other things. Or at least have forms dynamically built from a model of "Form" and "Field" objects.
If you have pointers to something to read I would appreciate it - or I will just take a look at it myself.
regards, Göran
Anyway, I don't know much about all these - and since Avi and others have been putting work into Scriptaculous that is probably what I will go with.
Well, I don't know much about the internals of all these JavaScript frameworks, however I think Avi choose Scriptaculous because it has a consistent object interface that can be nicely interfaced with Smalltalk. By using the Scriptaculous Seaside library you don't need to write a single line of JavaScript, and that is certainly a big advantage.
Mewa or Magritte might be interesting for you too, if you plan to do a lot with forms and dialogs. Both frameworks help to build and validate forms automatically. Since Magritte is described with its own meta-framework, it is even possible to let the users customize and build their own forms from the web.
In fact - this is exactly what we want to be able to do among other things. Or at least have forms dynamically built from a model of "Form" and "Field" objects.
* Adrian Lienhard, "Mewa: Meta-level Architecture for Generic Web-Application Construction," Technical Report, University of Bern, November 2003, Informatikprojekt (http://www.iam.unibe.ch/~scg/Archive/Projects/Lien03a.pdf)
* Stéphane Ducasse, Lukas Renggli and Roel Wuyts, "SmallWiki — A Meta-Described Collaborative Content Management System," International Symposium on Wikis (WikiSym'05), ACM Computer Society, 2005, To appear.
The second paper has got a chapter on Magritte, despite very few class comments this is the only written documentation right now. Unfortunately I cannot give you a link to the paper as it wasn't published yet, but I will send a copy to your personal e-mail. And there is hope for more documentation, I am currently writing a paper covering Magritte in deep ... Magritte is available on SqueakMap, the package automatically pulls in everything it needs.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
On Thu, Dec 22, 2005 at 01:39:30PM +0100, Cees De Groot wrote:
On 12/22/05, Brent Pinkney brent.pinkney@aircom.co.za wrote:
It would be appreciated it you could suggest a light-weight mechanism you would like to use for this.
The lightest-weight mechanism I know of is MonticelloConfigurations. But I'm not sure whether kilana.unibe.ch has already been updated to accept .mcm files.
It might be too obvious to mention, but for a package such as Magma that is maintained independently outside of the main image, a simple version label can also be quite helpful. For example, in the OSProcess package, there is a class called OSProcess with this class-side method:
versionString "OSProcess versionString" ^'4.0.1'
Just use some version numbering convention that makes sense to you, and make sure you update it in your development image right after you publish a new release on Squeak Map. Use Montecello etc for the real version control, and keep the release names on Squeak Map in sync with your versionString.
Along with keeping track of versions, this is helpful if you are maintaining a lot of unit tests, and you want other people to run them and report results back to you. For example, if you run "OSProcess allTestResults", the versionString for several packages and plugins are collected along with the test results (also the operating system, machine word size, etc).
Note that class VersionNumber does some useful things (but I still maintain a version string so I can have e.g. '4.2alpha').
Dave
Hi, I have also been thinking about this. While there is a #magmaVersion which returns simply an Integer, this is used primarily to check against legacy files. i.e., if there is no format change for a new release, I don't increment it.
It would seem useful to have another human-consumable versionString. To this end I have considered
"1.0" to be the functionality included right now "1.1" (real soon now) which interfaces to the security module and "1.2" (vaporware) to be the one which includes security AND the import/export replication feature
It would be real great if these could be file-compatible with each other but I don't know whether that will be possible yet.
Also, as incremental enhancements/bug fixes, each of these would be suffixed with "r1", "r2", etc.
Whew, lots o' work to do..
Thanks, Chris
--- "David T. Lewis" lewis@mail.msen.com wrote:
On Thu, Dec 22, 2005 at 01:39:30PM +0100, Cees De Groot wrote:
On 12/22/05, Brent Pinkney
brent.pinkney@aircom.co.za wrote:
It would be appreciated it you could suggest a
light-weight
mechanism you would like to use for this.
The lightest-weight mechanism I know of is
MonticelloConfigurations.
But I'm not sure whether kilana.unibe.ch has
already been updated to
accept .mcm files.
It might be too obvious to mention, but for a package such as Magma that is maintained independently outside of the main image, a simple version label can also be quite helpful. For example, in the OSProcess package, there is a class called OSProcess with this class-side method:
versionString "OSProcess versionString" ^'4.0.1'
Just use some version numbering convention that makes sense to you, and make sure you update it in your development image right after you publish a new release on Squeak Map. Use Montecello etc for the real version control, and keep the release names on Squeak Map in sync with your versionString.
Along with keeping track of versions, this is helpful if you are maintaining a lot of unit tests, and you want other people to run them and report results back to you. For example, if you run "OSProcess allTestResults", the versionString for several packages and plugins are collected along with the test results (also the operating system, machine word size, etc).
Note that class VersionNumber does some useful things (but I still maintain a version string so I can have e.g. '4.2alpha').
Dave
Talk about Magma features...
Correct me if I'm wrong, but in the client-server version, the code for all objects needs to be present in the server - at least that is my experience.
Maybe something that removes that requirement or lessens its impact (code transport between client and server)?
Talk about Magma features...
Correct me if I'm wrong, but in the client-server version, the code for all objects needs to be present in the server - at least that is my experience.
No, the server does not require any of your domain classes stored in the repository to be present in the server image.
However, if you have defined a custom index type, it *does* require that in the server image.
Maybe something that removes that requirement or lessens its impact (code transport between client and server)?
There is a mechanism for clients to obtain the necessary code directly from the server. Perhaps you have already seen this:
http://minnow.cc.gatech.edu/squeak/5603
and
On 12/22/05, Chris Muller chris@funkyobjects.org wrote:
However, if you have defined a custom index type, it *does* require that in the server image.
Ah - maybe it went wrong there and I jumped to conclusions.
There is a mechanism for clients to obtain the necessary code directly from the server. Perhaps you have already seen this:
Yup. But that's the other way around :). My idea is to have a Magma server running as an NT service, fire and forget, and all my dev images just to connect to the server when they need persistence.
So I'll need to come up with something for the custom index types, then. Shouldn't be too hard - if clients can obtain code from the server, they certainly can push it to the server and the server should be able to fetch it from its repository...
On Thu, Dec 22, 2005 at 11:26:40AM -0800, Chris Muller wrote:
Hi, I have also been thinking about this. While there is a #magmaVersion which returns simply an Integer, this is used primarily to check against legacy files. i.e., if there is no format change for a new release, I don't increment it.
It would seem useful to have another human-consumable versionString. To this end I have considered
"1.0" to be the functionality included right now "1.1" (real soon now) which interfaces to the security module and "1.2" (vaporware) to be the one which includes security AND the import/export replication feature
It would be real great if these could be file-compatible with each other but I don't know whether that will be possible yet.
Also, as incremental enhancements/bug fixes, each of these would be suffixed with "r1", "r2", etc.
If you want to get fancy about it, Craig Latta's naming convention for versions is worth a read. It seems sensible to me, and has held up well over time.
http://netjam.org/smalltalk/versions.html
Dave
Yes, but I would like to see a sort of snapshot point that says "this is stable, base your production work on this". So that newer versions may implement more advanced/experimental stuff, etcetera. At the moment, we just have to grab the latest version and hope that nothing experimental is in there which might interfere with production. This also puts a burden on development for precisely the same reason - because people grab the latest, it's hard to add more experimental stuff to the repository.
I was *just* thinking about this very thing last night. You have apparently read my mind..
For now, just know that the top version of "MagmaClientLoader", "MagmaServerLoader" and "MagmaTesterLoader" are the stable versions.
I am also considering adding a new package, "MagmaDev" or "MagmaAlpha" or something, that is a "configuration" (just standard flat-list prereqs, in the vein of the "Loader" packages) which would load the alpha versions of all the packages.
So far, the simple flat-list-of-dependencies seems to be working fine and actually easier to save than MCC's.
The difference seems to be that MCC's allow and require me to specify exact versions of all the dependencies; the loaded versions are the ones I want anyway. The regular flat-list-of-dependencies work off the loaded versions so that works out fine.
Assuming there was full support for MCC's (I require able to save to a "directory" repository), what do they buy me over the flat list of regular dependencies?
Thanks, Chris
On 12/22/05, Chris Muller chris@funkyobjects.org wrote:
Assuming there was full support for MCC's (I require able to save to a "directory" repository), what do they buy me over the flat list of regular dependencies?
You can save MCC's to any kind of repository. However, SqueakSource interprets what it receives and it misinterpreted .mcm files. That's been solved, I hear :)
Well, as long as all the packages are strictly yours and you can keep a flat hierarchy, MCC doesn't buy you a whole lot apart from probably load order (I'm not sure that MC's guarantees w.r.t. load order are, but in any case it's a bit of a pain to maintain). It starts to shine if you need to pull in third-party stuff, in a certain order. That's hard to do with MC without publishing new versions of such packages with prereqs to satisfy a certain load order, with MCC it's just natural.
magma@lists.squeakfoundation.org
-
Brent Pinkney -
Cees De Groot -
Chris Muller -
David T. Lewis -
goran＠krampe.se -
Lukas Renggli