Squeak-dev January 2010

squeak-dev@lists.squeakfoundation.org

91 participants
425 discussions

Re: [Pharo-project] Fwd: [squeak-dev] Smalltalk vs Eclipse
by Eliot Miranda 22 Jan '10

22 Jan '10

On Fri, Jan 22, 2010 at 1:32 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > Hi ralph and eliot > > > Nevertheless there are advantages to both and I wonder to what > > extent I can have my cake and eat it too (that would be an orapple > > cake I suppose). I should also point out that my discussion is abstract; > > I am asking if it would have been better if Smalltalk had > > been designed the way I propose and not should some Smalltalk, > > say Squeak, now be modified to be so. > > Yes I think that we can the best of both world. A minimal (but not smaller) > runtime with a good separation between the infrastructure for the runtime > and the loadeble ide and others. > > > The thing, particular to this discussion, about Eclipse that I like > > is that the Eclipse (image I will call it) is separate from the > > application (image I will call it). In Smalltalk the two images are > > combined. This means that a lot of code is encorporated > > into your application image that you may not want. > > I imagine that in Pharo in a couple of versions this will be different. > At least this is where we want to go. > > > Of course, before you release your application you can run a > > stripping program or process that strips out code that is not > > used in your application. (I have never done this but my > > understanding is that this is possible.) > > Stripping should not be the process. > > > Never having done this I assume that stripping is not that > > satisfactory because there is much code that cannot be > > stripped out; certainly unused methods and likely unused > > classes as well; the dynamic nature of Smalltalk means that > > much necessary information to determine that a method or > > class is not used is not available so such methods and classes > > must be included in the application release. > > Stripping in VW was not satisfactory not really easy. > It was not easy precisely because it had to strip out its own tools. If the tools are remote then stripping is much easier. I'm not proposing stripping as a standard step in deploying applications. I;m proposing stripping via remote tools as a way to get down to a small kernel image. Part of the difficulty in producing the small kernel image is needing to keep tools around so that the development system keeps working. This is all much easier if that development system is remote. > > Some may argue, that with all the memory processing power > > available today, who cares; but I care. For example, I would > > like to be able to put a Smalltalk application into a linux pipe > > as in: > > > > a | b > c > > > > where a or b or both are applications written in Smalltalk. > > me too :) > > > Similarly I would like to use Smalltalk applications in bash (Linux) > > shells scripts or use it in other scripting languages. So it > > may be important that my image not be unnecessarily > > large as getting it started may take longer than what it > > does once it is started. > > Yes we want that too. So any help in that direction is welcomed. > > > Of course I could use GNU Smalltalk for this but is it really > > necessary that I know/use two smalltalks? > > > > I think the Eclipse model suggests an improvement to Smalltalk. > > It seems to me that when you run Smalltalk ideally you would > > run two images. One would be the development environment image > > and the other would be the application image. When you started > > a new project you would choose from a selection of start images > > each including some subset of the development classes you > > expect to need. > > for minimal image to work, we need a way to manage parts > this is why metacello is important. Because you want to have ways to build > coherent images out of components with dependencies. > This is just because of that that we did not started to heavily remove > packages from the image. > > > I can't speak in detail to the Firewall work done at Digitalk by people > like Steve Messick, but they did get stuff done in the late 90's, although I > don't think anything was productised. I think they made the mistake of > focussing on being able to produce very small executables rather than just > separating the development and deployment images. I think Steve was able to > produce a tiny executable that only contained SmallInteger and hence was > able to eliminate tagged pointers and method lookup. But the focus on > optimization was I think a step too far. > > + 1. > > > One thing I remember was that the communications stub in the deployment > image was in the VM, not in Smalltalk code, again I think a mistake. Can > anyone from Digitalk put flesh on these bones? > ? > > eliot what is the communications stub > Is is some code that sits on a socket in the target image and receives remote message send requests from the UI image, evaluates them and returns the results. So it is a minimal communications port through which the UI can send messages to objects in the target image. It should be written entirely in Smalltalk for flexibility and simplicity. We don't need to get to 100's of bytes of image (e.g. being able to implement the unix mv command) we need to get down below 1Mb. I think Craig has such a remote messaging scheme in Spoon. > > We spent a lot of time discussing doing this in the VisualWorks team > about 10 years ago but as far as I'm aware none of it was realised. > Splitting tools UIs from the image under development (the target image) was > a major design goal behind OpenTalk, the distributed messaging framework > that Xu Wang did. We had the idea of the Model in an MVC triad being the > interface between the UI and target images, the natural point at which one > would define an API narrow enough to be efficiently distributed. If the API > is designed appropriately one would be exchanging symbols (class names, > selectors etc) not complex objects (classes, compiled methods) and that > because symbols and numbers are immutable they can be passed by value. > > > > We had the idea of the model being split in two, one half being specific > to a tool and the same whether one was in a single image or in the ui/target > pair, and the other half being an adaptor to either the local image or the > remote target. This adaptor would have sat between a model and some complex > object graph (like the class hierarchy) and defined the entire API through > which the object graph was accessed, narrowing the interface to make it > suitable for distribution, and doumenting the interface to make it easier to > understand. Vassili named these things between the model and an object > graph TTIBs for "The Things In Between". > > Was using distribution just one way to make sure that your two systems were > decoupled? > Because we could achieve the same using seaside? or > Exactly. The TTIB serves as a specification and a filter. But it is independent of the transport. Seaside is a valid transport. If things are done right one can have many different kinds of UI. But one is making the choice that the transport is Smalltalk messages over some non-Smalltalk stream. No one is contemplating using SOAP or CORBA or... (I hope). > > We very much wanted to produce a set of tools in a tools UI image that > could be targetted either at itself or at a remote target, and wanted to be > able to attach the tools image to a remote target dynamically (which we > called "dynamic capitation", for dynamically gaining a head) so that one > could have full debuggability on a remote image deployed in the field. > > :) > I would really like to know what are the issue at the level of the > Display.... VM code. What are the existing hypotheses > that have to be broken. Like global access to sensor or > Yes, lots of things break potentally. Transcript, self confirm: etc. Part of the challenge is in coming up with "pluggable" replacements. So that for example Transcript in the target image is something that sends its output to stdout until one attaches a tools UI, at which it becomes something that sends its output to the Transcript in the UI image. This takes some thought :) > Alas we never managed to get the priority of the project high enough to > actually commit major resources to it. There were always more pressing more > mundane things to do. Frustration at not doing things like this was in part > behind my leaving Cincom. Xu got quite far with a prototype, demonstrating > things like a distributed inspector that allowed one to walk though an > object graph spanning more than one image. The inspector would change > colour to indicate which machine the current object was one. > > > > > > Personally I think that Smalltalk is the ideal vehicle for this kind of > approach. We have lightweight remote messaging which is relatively easy to > implement. We have UI architectures which are relatively well-decomposed > and amenable to distribution. We have a reified exception system which is > not pushed down into hidden execution machinery and which has resume > semantics. We now have a much faster much more reliable internet. We could > relatively easily add things like delegation which can enable interesting > interleaving of tools and target images (see below). I think we could have > something truly revolutionary, the ability to interact with a remote > headless image that contains no development tools or UI frameworks and only > a relatively small communications module (remote messaging interface). This > would enable us to get to images of a few 10s or 100s of kilobytes. I > fervently hope you work on this. Lots of people want this. I was reading > Colin's Thin Air pages on wiresong yesterday and what he wants is realised > by this. > > Yes this would be good to have that. > I think that cleaning the left over of years of experimentations (which we > started with 3.6 Kernel Cleaning project > and continue in 3.9 and now is taking a large part in current pharo) is the > first phase so that we can > make sure kind of system happening. > > > If you do work on this remember your goals. The most important thing is > incremental deliverables and useful progress. Don't focus on whizzy > optimisations or cool demos (such as the inspector changing colour). Dn't > focus on arbitrarily complex topologies of remote images. Instead focus on > building a robust, well-engineered remote tools framework that just allows > one to do what one can do today in a browser and debugger, but remotely > between two images. > > We were thinking just about that with marcus and noury for mariano PhD. > this could be used to debug remote image running on robots. > > > I would start with browser, debugger and stripper, where stripper would > be something that allowed you to eliminate code from the target image using > the UI image to discover what was there and what was needed or not, i.e. > remote stripping, not the much trickier auto-stripping. > > > > On delegation I think one really cool thing is to wrap remote objects > with local development-only code. In a deployed image I would expect there > to be no inspectorClass methods or debugPrintOn: messages etc. The target > is lean and mean. Anything not needed for deployment except that which > supports adequate remote messaging is absent. So one wants to be able to > add methods that add debugging features to remote objects, and delegation is > the way. If the local handle on a remote object is wrapped by a delegate, > the delegate can implement the debugging methods. Catching > doesNotUnderstand: in the target mage can allow one to intercept > computations in the target and resume them in the development image. So > when connecting a tools image to a target one would layer tools and UI code > upon objects in the target but that code would reside only in the tools > image. > > > > Naming conventions in packaging, like splitting a Foo package into > Foo-Deployment & Foo-Development could help in making this kind of split > easy to navigate and conceptualise. So after producing the tools/target > split I would next focus on packaging tools, including analysis of call > graphs etc to help automating the deployment/development split. > > You forget deliver often :) > Right! best Eliot > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

1 0

Smalltalk vs Eclipse
by Torsten Bergmann 22 Jan '10

22 Jan '10

>Has this been done before One example is GemDev - you remotely control Gemstone Smalltalk with Eclipse tools. [1] Another example I know of is the OOVM from Lars Bak (Self, then Java HotSpot and who is now working on the V8 Javascript engine for Google). If I rememver correctly the old OOVM [2] run on small devices and was also driven remotely from Eclipse. It was a restricted Smalltalk (small bytecode set, restrictions on blocks, ...). Compared to Java development where you build/ compile on a PC and then transfer to the device to test this provided faster cycles since you could work directly on the machine. I think that was the reason they were bought later by Estmertec. Bye T. [1] http://astares.blogspot.com/2010/01/gemdev-ide-smalltalk-in-eclipse.html [2] http://astares.blogspot.com/2004/12/oovmosvm.html -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

2 1

[Cuis] Cuis
by keith 22 Jan '10

22 Jan '10

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

3 5

waveplace haiti update
by Timothy Falconer 22 Jan '10

22 Jan '10

Hi all, Tim Falconer from Waveplace & Squeakland. Just a quick update to let everyone know that the schools and kids from our two Haitian pilots, and the upcoming one in Matanwa, are all alive and safe for now. The building in Petit-Riviere was spared, and luckily the Port-Au-Prince children were moved to the new facility in Williamson just prior to the earthquake. Our chief mentor, Bill Stelzer, is in Port-Au-Prince now . . he's helping with the schools and filming. He & Suzie have been on CNN twice in the last two days (http://haitichildren.org). I'm now in Cambridge MA in talks with MIT and OLPC. A plan is forming, which we'll be announcing soon. Many thanks for all the kind words from everyone! Take care, Tim -- Timothy Falconer Waveplace Foundation http://waveplace.com 610-797-3100

1 0

[Cuis] Cuis
by Torsten Bergmann 22 Jan '10

22 Jan '10

>Squeak ceases to be an interesting platform because it hasn't got any >continuous integration tools, it has no vision for such tools, and those >it has got have just been discarded by the community without a second >thought. There are CI tools available - have a look how Lukas builds Seaside images from Pharo - he can even integrate the results in Hudson (a Java CI platform), see [1] or check the builds live [2]. >If I use BOB to build and regression test my code it only makes sense >if the seaside team also uses Bob to build and regression test their >code and the same goes for magma etc etc. And since the seaside team is not going to use Bob and I dont see Squeak adopting your ideas after trunk I think your original vision will not happen. At least not for Squeak/Seaside. Most people I know use Monticello these days - it works even when there are still issues left. You are able to load/unload packages, have images with modularized packages and the ability to share work between platforms like Squeak, Gemstone and Pharo. You can even read Monticello into VisualWorks. And there is Metacello now - solving the package management problem for Monticello. Dont know if Squeak will adapt Metacello, if it will not maintain Seaside or other packages separatly I think it should. Hope people here will have a look at Metacello too. Only time will tell. At least for Pharo I think Metacello becomes more widespread - since Metacello does a good job (as far as I've tested) and it is not bound to one platform. There are already many configurations available, even when it still lacks some tools. But it is maintained, documented, there is a commercial interest and it is well alive. On the other side I dont see any progress on Sake/Bob these days (we all know about the reasons, but there is now no force behind it) I understand most of your points, how hard it is to get fire from any side even when you tried to shape a better future and all the other problems discussed here - the real question for you is if you are able to leave the past behind and will be able to share a new future again within this community (even when it will walk a different direction than you originally proposed/shaped). Bye T. [1] http://astares.blogspot.com/2010/01/hudson-build-for-smalltalk.html [2] http://hudson.lukas-renggli.ch/ -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

4 4

[Cuis] Cuis
by Torsten Bergmann 22 Jan '10

22 Jan '10

>Metacello very overengineered. Depends on the point of view ;) >Does it track Universes package definitions? No, why should it. It's a package management for Monticello and as I already said it is not limited to Squeak and its derivates. Universe is Squeak only, you wont find it for instance on Gemstone. Metacellos goal is not to rival with Bob/Sake or try to push packages or Mantis fixes into any image derivate out there (which I think would be virtually impossible with the number of derivates and differences we already have) Seaside and Metacello are currently working well enough to build upon. They are open, maintained and one can easily participate. They dont wait for a board, take small steps, care about user base instead of insulting them. Should I rather invest my time into unmaintained code? Metacello (as well as Seaside) just work and are accessible, supported and adopted. So there must be a difference, no ? What about Bob/Sake? With all your actions I dont think it will have a bright future, even when you open the repo (which is still access restricted). >Gofer, a complex heirarhcy for four actual methods which do >anything same comment as on top of this mail >if you build anything on lukas' stuff be preopared to find >the whole infrastructure changing under you in a weekend, he wont even >look at any thing you offer as an addon. Nonsense, there is an active list with discussions - anyone can participate. You can open bugs, get fixes included, ... The framework is well written, there is documentation (even with a book) and meanwhile ported and used in other Smalltalks too. Lukas takes care even to beginners questions. Never had a problem with him. When I offer something it either gets included or I can provide it as addons (like the JQueryWidgetBox I did). Yes - there are infrastructure changes (like "Grease") necessary to ease porting and moving ahead. But typically people use a stable version and decide if and when to follow into a next new stable version. Look at Avi - he is still using an old version of Seaside for his dabbledb business. And according to a statement in an interview he has no problem with that. So again ... what is your point. You sell yourself as the miracle healer who was interrupted right before he was able to cure us from all illness. We now also know that your approach would have done it better than anything other. Then take this last step (another week?) to finish it and convince people to adopt it. And stop throwing mud onto anyone in the whole community who tried to move ahead or you ever had a problem with. With these actions you are the one who is now throwing away all your work and destroys your efforts for any useful reuse. Bye T. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser

2 1

Squeaksource is down from here :(
by Mariano Martinez Peck 22 Jan '10

22 Jan '10

http://downforeveryoneorjustme.com/http://www.squeaksource.com/ :(

1 0

Re: [squeak-dev] [Cuis] Cuis
by Ken G. Brown 22 Jan '10

22 Jan '10

oops, added the repository link... At 10:53 PM -0600 1/21/10, Miguel Enrique Cobá Martinez apparently wrote: > > Write tool to leverage the trunk activity then. Stop whining about >> losing control (via Mantis). >> People like a new and easy way to contribute, otherwise nobody would >> put any commits in trunk. >> Is this something that hard to understand? > >Is there somewhere a list of the users that have commited changes to the >trunk? >Or how many people have been contributing with this new model? > >I for sure have seen commits from >Levente >Nicolas Cellier >Andreas Raab > >Who else? Is an honest question. > > >-- >Miguel Cobá >http://miguel.leugim.com.mx From the initials on the packages at <http://source.squeak.org/trunk/>, I see the following: 1622 packages with the following initials and number of packages. ul - 130 tfel - 11 tbn - 3 stephaneducasse - 1 sm - 1 sd - 3 rss - 7 rkrk - 11 rej - 1 p4s - 1 nice - 475 ml - 2 mir - 1 mha - 18 md - 8 MarcoSchmidt - 1 MAD - 5 ls -1 laza - 29 klc - 2 kb -15 jmv - 35 jdr - 1 jcg -24 it - 2 Igor.Stasenko - 5 hpt - 1 HenrikSperreJohansen - 1 gsa - 1 gk - 1 enno - 1 eem - 9 edc - 41 dtl - 110 dew - 1 dc - 1 cwp - 8 cbc - 4 bs - 2 bp - 6 bf - 18 auto - 16 ar - 606 al - 2 Ken G. Brown

1 0

The Trunk: Tools-ar.164.mcz
by commits＠source.squeak.org 22 Jan '10

22 Jan '10

Andreas Raab uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-ar.164.mcz ==================== Summary ==================== Name: Tools-ar.164 Author: ar Time: 21 January 2010, 8:45:52.731 pm UUID: b6821f78-a328-4c43-9e2d-77182e6e9b0b Ancestors: Tools-ar.163 CodeHolder>>validateMessageSource: should parse the selector proper instead of using #findString: which causes all sorts of random warnings. =============== Diff against Tools-ar.163 =============== Item was changed: ----- Method: CodeHolder>>validateMessageSource:forSelector: (in category 'message list') ----- validateMessageSource: sourceString forSelector: aSelector "Check whether there is evidence that method source is invalid" | sourcesName | + (self selectedClass parserClass new parseSelector: sourceString asString) = aSelector + ifFalse: [sourcesName := FileDirectory localNameFor: SmalltalkImage current sourcesName. - (self selectedClass compilerClass == Object compilerClass - and: [(sourceString asString findString: aSelector keywords first ) ~= 1]) - ifTrue: [sourcesName := FileDirectory localNameFor: SmalltalkImage current sourcesName. self inform: 'There may be a problem with your sources file!! The source code for every method should (usually) start with the method selector but this is not the case with this method!! You may proceed with caution but it is recommended that you get a new source file. This can happen if you download the "' , sourcesName , '" file, or the ".changes" file you use, as TEXT. It must be transfered in BINARY mode, even if it looks like a text file, to preserve the CR line ends. Mac users: This may have been caused by Stuffit Expander. To prevent the files above to be converted to Mac line ends when they are expanded, do this: Start the program, then from Preferences... in the File menu, choose the Cross Platform panel, then select "Never" and press OK. Then expand the compressed archive again. (Occasionally, the source code for a method may legitimately start with a non-alphabetic character -- for example, Behavior method #formalHeaderPartsFor:. In such rare cases, you can happily disregard this warning.)'].!

1 0

Killer Apps
by Overcomer Man 21 Jan '10

21 Jan '10

I'd like to see Squeak come with tons of killer apps so we have no need to go outside of Smalltalk to do any programing job. I think that could turn Smalltalk back to the hopeful industry standard it used to be at the first OOPSLA. To do that it would need support for all types of peripherals including Terrabyte disk files, Webcams, TV Tuners, Multicore CPU's, LANs with one operator, nice elegant code for doing complete tasks that are easy to understand and customize instead of bloated incomprehensable packages. Say in graphics we had a package that made it easier to develop cartoons than whatever Mac software they use for 3D cartoons now and be compatible with Autocad, Solidworks and Inventor? Say in business we had something to rival SAP. Say in Math we could best Wolfram-Alpha. Say in AI we could out do OpenCyc. Say Squeak's browser was finished so it would rival MSIE or Firefox. Say we could bring up a full screen of Squeak and never have to reduce it to do things like capture a screen image, crop, and print it (I still use an old free app for that). What other apps would cause people to say, it's better to hire one Squeak programmer than 10 C++, Java, Ruby, or other traditional programmers? What if we presented advanced apps most people never see like machine vision? Genetic algorithms? Bible metaphor interpreter? Machine translation? Management Accounting (distinct from financial accounting)? Hobby rocket orbit insertion software? What are all the apps that if presented in Squeak would make people prefer Squeak to Microsoft products? Squeak has a big advantage now in being a tiny download compared to Ruby Steel. What is needed to make people choose Squeak? And what if the code repository for Squeak apps had an index that showed an informative description including which were open for download since some aren't and should be in a seprate repository? This is not to provide fodder for critical thinkers to criticize but to provide ideas for creative truth thinkers to develop.

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
43
Older →

Jump to page: