Squeak-dev June 2009

squeak-dev@lists.squeakfoundation.org

80 participants
92 discussions

Stylesheets for morphic?
by Igor Stasenko 11 Jul '09

11 Jul '09

I found that to write a formal 'css' specs in smalltalk could look very similar to w3c css syntax: .bar { display: inline; border-left: 1px solid #d0cfd5; width: 1px; margin: 0px 5px; font-size: 80%; vertical-align: baseline; } could be written in smalltalk as: (styles addClass: #bar) display: #inline; borderLeft: (BorderStyle width: 1px type: #solid color: #d0cfd5); width: 1 px; margin: 0 px @ 5 px; fontSize: 80 p; verticalAlign: #baseline . I really thinking that what is good in css/html couple is the techique for dividing the actual markup and its visual appearance. Maybe someday we could have similar stuff in morphic / other smalltalk framework. -- Best regards, Igor Stasenko AKA sig.

4 4

Usability and look-and-feel (was Re: [squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean))
by Ian Trudel 10 Jul '09

10 Jul '09

2009/6/29 Hernán Morales Durand <hernan.morales(a)gmail.com>: > Dear Ian, Hello Hernán! > I really understand your position, because I hated > the Squeak UI for almost one year, until I started to read about Color > Theory and Cognitive Pshychology and understand some things about it. > However, each soul has to convince by himself or do something about > it. There are many superficial people in this crazy world. They don't get pass the current look-and-feel. It is unfortunate enough because they cannot see the true beauty behind Smalltalk. The look-and-feel is not so important to me since it's necessary to create a custom UI for our application to be deployed, and localization, deployment facilities, maintenance related stuff, etc. comes on top of my list. But, still, it's good to be able to talk about these issues and understand what the problems are. > Color Theory and Cognitive Psychology Squeak UI is really colourful. Bright colours are stimulating and would be favourable to any child's development. It is however very difficult to spend 8, 10, or more hours a day, everyday, either on a personal project or a professional front, with such a colour scheme. Moreover, the colours are not necessarily clearly identifying each window or graphical component; I feel lucky that it doesn't pop up the same tool with different colour each time. The lack of coherence in the colour scheme makes it exhausting and serve no other purpose than aesthetics, usability completely left aside. The lack of coherence in the general look-and-feel is also disturbing and annoying. Usability comes second in the list of complains from my acquaintances, which I tried to Squeak-e-vangelize. The first obstacle is obviously no edit-compile-cycle but we ain't gonna get it (it makes no sense at all in Squeak). Sincerely, I think, people can get over the fact there is no edit-compile-cycle. Then, they hit themselves to a bunch of separated windows in contrast to an IDE, which traditionally provides everything integrated through panes and top menus in categories. Newcomers (or even not so new) should easily find features without having to dig into obscure menus or, sometimes, even code. Menus are a big mess. They're sometimes huge and the lack of organization is problematic. The programmers not so familiar with Squeak definitively have to understand the principle behind the workspace, transcript, class browser, saving an image, etc. Nonetheless, the sense of being lost in this new but exciting environment would not repulse them if only they could find familiar elements. > Let me put my feelings into the words of Schoenberg, he once said : > "Art is not for everyone; and if it is for everyone, it is not Art.". > And I believe pretty much the same here : "Smalltalk is not for > everyone; and if it is for everyone, then it is not Smalltalk". It is perfectly fine if Smalltalk is not for everyone. Though, wasn't it the initial spirit of it? Anyway, while it might not be for everyone, it shouldn't make our own community split up and flock away. Right? I've got the feeling the Squeak community has created a very comfortable niche for itself and sort of forgot about the essentials. A reality check once in a while is always good. > Cheers, > > Hernán Best regards, Ian. -- http://mecenia.blogspot.com/

27 67

Future of Squeak, and outsider's view
by David Goehrig 02 Jul '09

02 Jul '09

Yet another lurker here. While I'm not at all qualified to speak for the seasoned Squeaker communities, I am qualified to comment on the issues I've found attempting to implement some sample applications for contract bids on top of Squeak. I've also tracked the progress of Pharo with great anticipation, and have spent a lot of time pondering what needs to change to make it useful for my production work. Here's a few thoughts, inspired by Dan Ingalls's famous 1981 Byte article on the principles of Smalltalk. Principle 9: *Modularity:** No component in a complex system should depend on the internal details of any other component.* Well if you look in the latest Pharo image, you'll find there's around 38 methods of the Object class that amount to: isFoo ^ false Each of these methods violate this principle, not only in spirit but also in practice. While this has been common practice for ages, it means that building downloadable modules that can be easily merged with any given image is practically impossible. As soon as you have two packages that define their own class that wants to use the same name, and register its own methods in a "base object", you both violate the principle of modularity AND break other packages. Principle 12: *Factoring:* *Each independent component in a system would appear in only one place.* This is probably the single greatest reason for moving towards Traits across the board. But look at this concept in the context of two seemingly entirely different methods: Object acceptDroppingMorph: transferMorph event: evt inMorph: dstListMorph Object hasLiteralSuchThat: testBlock If you look at both of these methods, you'll quickly realize that they are in fact the exact same method! This is because they have the exact same bytecode representation. These two methods are also exactly the same as the 38 isFoo methods I mentioned above. The only different is the semantics as viewed by the programmer, but the reality is none of these methods should be necessary, and should be factored out. These methods only exist due to a flaw in the design of the API and its semantics. This brings up the issue of Principle 2: *Good Design:* *A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.* If you look at the problems of creating packages (see principle 9 above) or the excessive verbosity which leads to inordinate redundancy (see principle 12), these ultimately stem from lapses in principle 2. Over the years, cruft has accumulated, people's code has become fragile and dependent on that cruft (remember message passing's and modularity's purpose is to reduce fragility), and result in an inertia against fixing the fundamental design flaws. We end up with arguments over Squeak vs. Pharo vs. Etoys because the design of the core system has lapsed into disrepair, much like the US's infrastructure. A serious effort to address this short coming, and re-examine old design decisions to improve the core infrastructure would dramatically impact the future of all of these projects (as they all inherit the same problems). Principle 17: *Natural Selection:** Languages and systems that are of sound design will persist, to be supplanted only by better ones.* The concept of forking the language, fixing core issues, and addressing design flaws is a core principle of Smalltalk. Maybe it is time for a better one. Just my two cents, Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

13 42

The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)
by Göran Krampe 02 Jul '09

02 Jul '09

Hi all! Matthew Fulmer wrote: > Awesome job guys. The volume of improvements Pharo has over > Squeak really makes me wonder if the latter has any real > relevance anymore. Yes, it is quite an interesting situation IMHO, and one that most of us could foresee too I think. NOTE: Read the following with a nice bucket of love, ok? I don't intend to make anyone upset. :) And sorry for the long post. On one hand I really appreciate the Pharo project - lots of good people doing lots of good progress etc. It seems to be doing simply great. On the other hand the "negative" effect I can see is the "drain" it has caused (I think) from squeak.org/squeak-dev. In other words, squeak.org has lost a lot of momentum, and of course not only due to the birth of Pharo I should add. And in many ways Pharo may also be the "rescue" to squeak.org. God knows we have been trying to find "our way" lately and with... less impressive results. :) So... how will the future evolve? Does the Squeak community (in the large sense) have anything to gain from keeping both the squeak.org and the pharo fork "alive"? I presume we have at least the following three scenarios: 1. Continue as now and take no specific action. This will probably lead to Squeak.org going weaker and Pharo stronger by the day. Developers will want to be where the "action" is. Soon squeak.org turns irrelevant and dies a slow death. 2. Take some decisive action and "merge" the two in some *smart* way beneficial to both. Impossible? I hope not. 3. Just kill off squeak.org. A mercy kill :). Then people could move over to Pharo without having to think about it - there is no other "Squeak". Eh, well, my analysis is probably full of silly holes here. Looking at the above, 1 and 3 feels less nice. So how could a "merge" look that would be attractive to *both* camps? I call the theoretical merged project Phreak below (but I am not proposing name changes etc, but I need a name to use in the text). Pharo characteristics: - A small "benevolent dictator" board. Lots of action, less talk. - Has a very clear stated "direction". - Has a website using CMSBox. - Uses Google code for issue tracker and wiki. - Has Mailman mailinglists and downloads at gforge.inria.fr (I think) Squeak.org org characteristics: - Has an elected SOB, an election process and a Team model. The jury is still out I think, we seem to have lots of trouble "getting shit done". - Has very little stated "direction" at the moment. - Has a website using Swazoo. - Uses Mantis, Swiki, file archive and Mailman on a community paid Hetzner server. Now... why would Squeak.org want to merge with Pharo? Pros: Get momentum back. 1 + 1 = 2. A revitalization. Very important! Cons: The SOB & Team model would probably have to be dropped. The work made since Pharo forked may or may not be a "lost cause", that depends on if Phreak is interested in utilizing that work. Other cons? ...and Pharo? Pros: An influx of developers. A much stronger position as Phreak would be Squeak + Pharo. No "compatibility" to worry about, Squeak is out of the picture. Cons: Some people in Pharo may perceive such a merge as dangerous since they might be afraid that certain aspects of Squeak.org (that Pharo was created in order to escape from) is coming back "knocking on the door". I personally don't think there is such a danger if Phreak simply adopts the simple organisation of Pharo (with board and all) BUT... since it would make the Pharo community much *larger* the effects of that growth need to be taken into account. But Pharo should not fear growth, because that would be an odd position. How could a merge be done practically? I really don't know :). And I must stop typing now, this post is waaaaay to long anyway and I have probably stepped on too many toes already. regards, Göran

39 181

Let's push it
by Andreas Raab 01 Jul '09

01 Jul '09

Folks - I truly love this discussion and I think it has generated enough insight that we can try pushing a few things. As a first step, I would like to propose a slightly different development model for Squeak, because I think that is one of the fundamental bits that is wrong. Here we go: 1) Agree on MC as the core development tool/model. This is painful and consequently the decision has to be made consciously. However, from my perspective there is really no suitable alternative [1]. 2) Decide on the canonical repositories. I would suggest that http://source.squeakfoundation.org/trunk is a fine starting point [2]. 3) Decide on who gets commit rights. I would suggest that the board decides that (equally for eventual access removals). The "masters" list from Squeak-people could act as a starting point. 4) Implement an update model for MC. I would suggest to adopt a similar model to what we've been using for Tweak in the past: Use MC config maps to mark points in the update process where order is important and otherwise update the packages in a well-defined order[3]. These four steps are intended to achieve the following: I can propose to the board that Eliot should be given access to the kernel repository so that he can commit any fixes to the compiler or other changes required for Cog directly without the need for an intermediate. I can propose to the board that Nicolas gets commit rights to the kernel repositories so that he can commit any fixes for numeric stuff he has or comes up with in the future. If the board agrees, they can do that, period. If they screw up or abuse their powers the board can retract commit rights. The main difference to what we've done in the past is simply that we have an inclusive list of committers instead of a select few and that we do understand the image as truly being "work in progress" inbetween the releases. In other words, be more active, change things faster, make it possible to report, devise, submit, and deploy a change in a matter of minutes. For people who don't have commit rights, there is both Mantis or commit-by-proxy which reinstates the SqC model of having a champion for your change. I.e., to commit something you can ask someone else to commit your change but that person implicitly takes responsibility for your change and will be the person who gets blamed for it and is expected to take care of it (and they may loose their commit rights if the change they commit is complete crap). To me, that is a useful intermediate state because the proxy acts as a mentor to teach the original author about how to provide changes, make sure it's okay etc. For Mantis, Keith just added a bunch of wonderful scripts that allow us to pull changes from it and build images (and hopefully soon run tests like the integration tests that I've been working on earlier) which means that we can build images with those changes included, test them, and if they pass those tests (and possibly other review), commit them to trunk. Again, I think having a champion who does the commit would be a good model. Obviously there is still a manual element involved here but the idea is that the regular committers would be able to go straight to the repository without requiring further approval. For users of Squeak there would be an update process which (although much slower than the update stream of the days of yore) would allow people to keep track of the ongoing changes and (for forks) merge those changes as desired along the way using Monticello. What do people think about this as a straw-man? Obviously, I want to enable people to contribute in the most straightforward way possible. Allow development to be more fluid, make mistakes faster, fix them faster. It does not address the issue of controversial / strategic changes but I think we're mostly loosing out on the most basic level and if we want to fix the processes we must make simple things simple and complex things possible, not the other way around. Cheers, - Andreas More detail on some of the issues above: [1] Why I think update streams don't cut it: When you do distributed development it is necessary to know if there are conflicts with what you are working on. If you only get to spend two hours a week on development you need to be able to quickly find out if anything changed in an area that you've been working on since last week. If you want to provide backwards compatibility you need to be able to reflect about what has changed, etc. Monticello is pretty bad but it's still the best we got. [2] http://source.squeakfoundation.org/trunk: The idea is to use the version specific directories (Squeak39, Squeak310, Squeak311 etc) as branches for released versions. The "current" version is always on trunk, the specific ones provide updates after a version was released. [3] MC based updates: The basic idea is that the config maps define load order and intermediate stages where required. There is an update-<version>.mcm in every repository that is consulted by the update loader process. The update process loads the update.mcms in order and uses the order in the last loaded update.mcm to update all the remaining packages. In other words, as long as the packages load with the last defined order, we change nothing. If Bob finds a problem we issue a (series of) configurations that get past that update bump. Yes, there is a certain element of risk to it but if Bob runs test builds of the image for us we can simply update to the last version which Bob was able to build for himself (and Bob can notify us that there's a problem).

14 20

Thoughts about Cog and "tracing" etc
by Göran Krampe 30 Jun '09

30 Jun '09

Hi folks! This post is a just a "heads up" based on some websurfing around VMs and JITs. I am itching badly to hear Eliot announce some kind of Cog-thingy - so consider this rambling post to be a symptom of that itch. :) There are a few things going on in the VM world that most of us have no clues about. We know about V8 but most may not know about TraceMonkey/Tamarin and its use of a new technique called "tracing" and a backing library for it - nanojit. Evidently TraceMonkey is giving V8 a real run for its money, and AFAICT this is mainly due to work of Andreas Gal (really interesting long article): http://andreasgal.com/2008/08/22/tracing-the-web And some other: http://www.bailopan.net/blog/?p=72 Hot off the press (yesterday): http://www.bailopan.net/blog/?p=430 After having read that Eliot does not think LLVM is suitable mainly due to lack of large basic blocks in Smalltalk code - and he seems to be looking hard at Factor and its JIT - I just wanted to mention the above as Yet Another Interesting Bit. I also think that the latest work on Lua (LuaJIT) includes tracing, not sure though. So Eliot, how is your work progressing? No pressure, just LOTS of interest! :) regards, Göran PS. Being bored hacking C#...

5 6

sane defaults and doesNotUnderstand: (was Future blah blah blah)
by David Goehrig 30 Jun '09

30 Jun '09

On Tue, Jun 30, 2009 at 12:22 AM, Michael van der Gulik <mikevdg(a)gmail.com>wrote: > > > Changing the implementation of doesNotUnderstand: is a code smell. You're > starting to play with voodoo and you need a *very* good reason to do it. > Otherwise you'll have made yourself a very difficult application to debug. > In the spirit of communication, I'll explain why I consider the current defaultHandler behavior of doesNotUnderstand:aMessage to be "broken". My Very Good Reason (TM) is based upon the principles of expectation. In the abstract, semantically if I say something like: anArbitraryObject someMethod ifTrue: aBlock. I am implicitly stating that I expect anArbitraryObject will return a boolean when passed the message #someMethod. This expectation has nothing to do with the implementation of anArbitraryObject, or with the meaning of #someMethod, only in the semantics of how it fits within the overall structure of the statement. Similarly if I were to say something like: ( anArbitraryObject + 1 ) < someLimit ifFalse: anotherBlock I am stating that I expect anArbitraryObject to return some sort of numeric value, and that #+ will perform some sort of addition. In this case the result of #+ should also be something that can be compared using an ordering #< message. If any of these objects were to fall through to the defaultHandler, instead of getting what I expected, I'll get a MessageNotUnderstood dialog, which while incredibly helpful in debugging, doesn't actually "Do What I Mean". From a pure semantics point of view, I'd rather the system honor my intent more so than confront me with implementation details. MessageNotUnderstood is an implementation detail, and does not correspond to the semantics of the statement. It is a literal non sequitur. This is doubly true in the case of methods which merely test for a capability. If the object doesn't understand, then it clearly doesn't have the stated capability! Res ipso loquitur. So from my point of view, the current system behavior, while useful for debugging, doesn't match the programmer's explicit semantics. Additionally there is an entire class of application, ones that consist of lots of distributed and unique objects, in which the existing class based objects become a de-optimization. These apps are typically only implementable by rolling your own objects by hand, and attaching a custom doesNotUnderstand:aMessage handler to each. But that's a post for another time. -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/

3 4

Image crash and doesn't generate crash.dmp in Windows
by Mariano Martinez Peck 30 Jun '09

30 Jun '09

Hi folks! My image is crashing but no crash.dmp is being generated. I am in windows. Does someone know what can be the cause? Thanks! Mariano

2 2

Compatibility (was some other subject...)
by Ian Trudel 30 Jun '09

30 Jun '09

2009/6/29 Stéphane Rollandin <lecteur(a)zogotounga.net>: >> So what? Some people keep using even older images. > > well thank you for driving me out. I guesss I just have to shut up now. Don't be so dramatic, Stéphane. Your opinion is all right and worth one voice. As everybody else here. =) There are frustrations in regard to the constraint of backward compatibility. It is greatly increased by the fact that we have limited set of test cases to ensure our changes don't break anything. And we don't have an official API to lean on as well... Moreover, the community should ask the question on how important the compatibility is (specifics in term of qualification and quantification)? We could certainly define levels of compatibility, set for each (major?) component. What has to be absolutely kept? What can be ditched? To simply state that it will break one's code is perhaps not enough when a growing frustration in the community shows up. We should definitively understand better what kind of need in terms of compatibility our community has. Could also this compatibility be simulated? Can we use text transformation rules to update the code and thus ensure an easy migration to newer image? Etc. Ian. -- http://mecenia.blogspot.com/

6 9

Coding style (was: Future of Squeak, and outsider's view)
by Michael van der Gulik 30 Jun '09

30 Jun '09

On Tue, Jun 30, 2009 at 4:53 PM, Cameron Sanders < csanders.personal(a)functional-analyst.com> wrote: > > On Jun 30, 2009, at 12:22 AM, Michael van der Gulik wrote: > > Back to the question of adding behavior to classes that you don't own. >> VisualWorks has a means to extend a class in a different package ... as I >> recall. As I recall, squeak has no such capability, right? >> >> >> Squeak certainly has that capability, but I would discourage you from >> using it. >> > > Why? It's a gut feeling thing rather than any serious good coding practise. Often if you feel the need to put code for your package in another package, then that other package was somehow deficient and your modifications should be made to that other package "properly". If your package modified another package such that it gains knowledge of other class's internal behaviour, you're breaking encapsulation and leaving your code prone to breakage when that other package changes. Collisions can occur if two packages try to modify the same method on a third package. It spreads your code around. I like to keep my code in one place and I've personally got a tendency to write slightly less elegant code which is "right here" in preference to modifying external classes. Gulik. -- http://gulik.pbwiki.com/

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →