Squeak-dev June 2008

squeak-dev@lists.squeakfoundation.org

130 participants
143 discussions

Re: [squeak-dev] Monticello Version Numbers (minor update)
by Benoit St-Jean 30 Jun '08

30 Jun '08

My wishlist... To somehow paraphrase Stéphane Ducasse: "I want to load any package, from any repository into any Squeak image". *** BUT *** 1) I need to be warned when prerequisites are missing, I want to be warned of undeclared/missing classes/pools/methods/etc ; 2) I want a good integrated diff tool 3) I want a good merge tool 4) I want an integrated CVS 5) I want a one-click load 6) I want a one-click "publish" 7) I want a user-friendly searchable web interface to the public repository with good browsing capabilities to locate code/packages by category, class name, author, publish date, package name, etc. 8) I want one "tool suite" to do all that, not parts of it with Universes, other stuff with Squeakmap, the rest with Monticello, some with standard fileIn/FileOut, 10 formats of import/export... In other words, I want simplicity of use to handle complexity of code. ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

1 0

{Q} When we lost TextEditorYellowButtonMenu ? We still need it ?
by Edgar J. De Cleene 30 Jun '08

30 Jun '08

Folks: I polishing SqueakLightII (unofficial 3.11) and found in undeclared TextEditorYellowButtonMenu Still is in source text and last image having is 3.8 in ParagraphEditor class variables. So is still needed ? Google bring me some to think we should have, but is not on 3.9 or 3.10. Any help or hints ? Edgar

2 2

Re: [squeak-dev] namespaces, version control, package loading and image release compatibility
by Michael van der Gulik 30 Jun '08

30 Jun '08

On Sun, Jun 29, 2008 at 5:58 AM, Ken G. Brown <kbrown(a)mac.com> wrote: > > I'm thinking a significant part of the problem of namespaces, version > control, package loading and image release compatibility is that many > versions of methods and classes can exist in the wild but the names do not > include any information about their uniqueness. So when you load something > it may stomp on methods that are still required in their previous > incarnation for something else to work. > My Package/Namespaces architecture was designed to solve the problems of namespaces, version control, atomic package loading, and package interdependence. In theory at least, a loaded package will run in exactly the same environment it was written and tested in, even to the extent of automatically loading that environment into the image if need be. These are unstructured braindumps of what I've been working on: http://gulik.pbwiki.com/Namespaces http://gulik.pbwiki.com/Packages I'm now writing tests and fixing up bugs in the core code. An alpha release will be made "soon". I'm designing these Namespaces for a fork of Squeak called SecureSqueak which is designed to run untrusted code in a secure sandbox. It is not intended for general use in Squeak. Gulik. -- http://people.squeakfoundation.org/person/mikevdg http://gulik.pbwiki.com/

2 1

The main Squeak problem Was: [Re: [squeak-dev] SqueakMap is a "Showroom"]
by Igor Stasenko 30 Jun '08

30 Jun '08

2008/6/28 Damien Pollet <damien.pollet(a)gmail.com>: > Ex. Pier needs Seaside. If there is a new release of Pier, the Pier > developers update the Pier package and nothing more. If Seaside gets > upgraded, the Pier package should *not* have to change/be > regenerated/whatever until the Pier code is updated. > This scenario is quite unlikely in Squeak , but surely it is possible in general in smalltalk (Spoon addresses that, getting rid of globals addresses that :) Once you change a class from which depends the rest, it may require to update dependent code as well, otherwise it will be broken. Unless people design things with modularity in mind, but i don't see many of such packages, which can be used w/o fear that updating them will not break something else. This is a real main problem of squeak: bad design which prohibits modularity, not MC or SqueakMap nor CPAN or other tools. First, we need a paradigm shift IMO. From solid, single image where everything is closely tied, to modular system where different parts does not interfere with others, or if interfere, they play by strict rules. We had a lengthly battle yesterday on #squeak IRC channel. It seems everyone wants better Squeak as we know it. But having different views on it. Surely, we can improve our tools, and they indeed need improvement. This is great, but in the end, if we stay with old paradigm, no wonder will happen. Ask yourself, do you want a system, where you can load any code without any risk, and even if it broken, it will not break the rest of your system? Do we want it to be a smalltalk, not a NewSpeak? Or we just wait till NewSpeak (or another heir of smalltalk will successed and migrate to it?). Lets just understand, that to get to new level, we need a quality shift (change system to become truly modular) , not quantity (make more or better tools). Only after we do that, squeak can explode with quantity, because there will be much less things to deal with. As with Alan's analogy: we have objects which behave as body cells and they are quite modular. But why, at same time, we deny that group of cells (package/set of classes) can't be modular? Make system modular. This is what most of currently elected board members (including me) had in their platform. This is what, i think people wanted from us. -- Best regards, Igor Stasenko AKA sig.

3 2

[ANN] Prolog home page
by Stéphane Rollandin 29 Jun '08

29 Jun '08

hello list, there is now a page about the current state of Prolog: http://www.zogotounga.net/comp/squeak/prolog.htm to be continued... Stef

1 0

Help needs for the gstreamer on os-x installation process.
by John M McIntosh 29 Jun '08

29 Jun '08

In order to get the GStreamer plugin to work on OS-X in a more friendly fashion I need someone with deep knowledge of ranlib, libtool, ln (etc) to build an installable set of the GStreamer plugins so that you can install the "Good" GStreamer set on an arbitrary macintosh without having to install the 1000 or so packages if you follow the (very unix like) MacPorts or Fink installation process. As far as I know the Linux version of the plugin is ok, and there are people working on the Windows flavour, but sadly the macintosh version is not available. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

3 3

Re: [squeak-dev] Perl is to CPAN as Squeak is to (what)?
by Claus Kick 29 Jun '08

29 Jun '08

> On 28-Jun-08, at 5:27 AM, Claus Kick wrote: > > > If push comes to shove, I would even say, lets ditch them all and > > just use SVN like the rest of the planet (if that is possible). It > > is hard enough to sell a image-based language with a real IDE to the > > C-style crowd, the package management systems should not add their > > grain of salt to the soup. > > Been there, done that... <shudder/> Trying to get SVN to work or trying to sell Smalltalk to the C people, or both? :) > Monticello was created because this turned out not to be feasible in > practice. Could you please elucidate the main obstacles to this approach? >The simple fact is that Smalltalk *is* image based, and > that's a feature, not a bug. For those who can't accept that, there's > Ruby. I agree, in principle - though I would have liked slls to stay outside the image, that makes changing them externally much easier. Instead that meant, unloading, reloading and sometimes crossing your thumbs and hoping all would go well and not fry your image. -- Claus Kick "Wenn Sie mich suchen: Ich halte mich in der Nähe des Wahnsinns auf. Genauer gesagt auf der schmalen Linie zwischen Wahnsinn und Panik. Gleich um die Ecke von Todesangst, nicht weit weg von Irrwitz und Idiotie." "If you are looking for me: I am somewhere near to lunacy. More clearly, on the narrow path between lunacy and panic. Right around the corner of fear of death, not far away from idiotism and insanity."

2 1

Re: Which list?
by Bert Freudenberg 29 Jun '08

29 Jun '08

Am 29.06.2008 um 10:28 schrieb Robert Wierschke: > Hi, > > I would prefer to use jsqueakinterest for the following reasons: > > • The goal is to develop a Java interpreter for Squeak images and > not to develop Squeak in a way that it can be interpreted by a Java > Squeak implementation. So development of JSqueak should not > influence development of Squeak. > • The squeak-dev list is already very active. Hence someone > interested in only on of the topics might be disturbed by the other > discussions on the list. I'm not interested in developing Squeak > itself (for now). > • The jsqueakinterest list is already there and on Sun's official > JSqueak download page announced as the discussion list for JSqueak > (hence the name ;)). So moving the discussion to annother list might > be a problem if Dan does not change this on the JSqueak page. > Furthermore if Dan intended to use squeak-dev as the mailing list > why does he setup and announced jsqueakinterest? > > But I'm afraid I'm already outnumberd. Not really :) Since development will indeed deal with VM development in Java mostly, the squeak-dev list seems inappropriate. The Squeak vm- dev list would fit better, but a special list should work as well. So I'm for using the jsqueak list. - Bert -

2 1

SqueakMap is a "Showroom"
by Chris Muller 28 Jun '08

28 Jun '08

Here are the package requirements I've been hearing in these threads and are congruent with my own: 1) Easy-installation. One-click installation of multi-package software systems, including, if necessary, execution of install scripts and local deployment of resource files. 2) Easy-publication. One-click deployment of multi-package software systems, including install scripts and resources). 3) A full SCM collaboration system, with diffing, merging and distribution across multiple repositories. 4) Ability to plug into any other existing or future packaging system. Requirement #3 is met by Monticello. Requirements 1, 2, and 4, used in the context of an appropriate lifecycle, can be met solely with the existing Monticello and SqueakMap tools we have today. And there are just two steps to get there, one of which is just a change of *thinking*! step 1) Assimilate this thought: "Anyone integrating multiple programs (packages) into a single image is doing development." step 2) Humans make all SqueakMap packages one-click loadable and only publish one-click-loadable packages going forward on SqueakMap. Do this via the SAR install script, making calls to other packaging systems as necessary (satisfying requirement #4). By doing just these two things we don't need any other tools and SqueakMap doesn't need dependencies to meet the four requirements. At the same time, other tools can be used and called from the SAR script if desired. SqueakMap is the "Squeak showroom" place for exploring what packages are about. We only expect SqueakMap to load a *single* package into the image which it says is compatible. Of course, we know we can load more than one, but the included Test Suites provide my comfort on whether everything still "works". We don't worry about conflicts between package versions loaded from SqueakMap because that requires deliberate package integration in which you use Monticello, not SqueakMap. The maintainer will update his dependency list soon enough if we make publishing to SqueakMap easy. I added a "BuildSar" button to Monticello Configurations browser so I could at least build the SAR in one-click, which I then have to manually upload to SqueakMap. - Chris

5 9

[JSqueak] Which Squeak VM is compatible with JSqueak?
by Victor Rodriguez 28 Jun '08

28 Jun '08

Hello, Since JSqueak is not yet able to save an image, I tried to use the Squeak 1.1 VM with the mini image shipped with JSqueak. Using Squeak, I can save the image and reload just fine. But if I then open the image with JSqueak, JSqueak fails after trying to grow the object memory past 60,000 objects. Does anyone have a hint? Thanks, Victor Rodriguez.

3 2

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page: