Squeak-dev July 2009

squeak-dev@lists.squeakfoundation.org

126 participants
195 discussions

Problems installing packages (FFI for instance)
by Casimiro de Almeida Barreto 03 Jul '09

03 Jul '09

As of yesterday some packages doesn't install anymore. As an example: FFI Perhaps Universes must be adjusted to http://source.squeakfoundation.org/trunk/FFI ? Unknown simbols: repo, reader, version UndefinedObject(Object)>>doesNotUnderstand: #version DoIt repo := MCHttpRepository location: 'http://source.squeakfoundation.org/FFI' user: '' password: ''. 'Installing FFI' displayProgressAt: Sensor cursorPoint from: 1 to: 6 during: [:t1 | #('FFI-Kernel-ar.8.mcz' 'FFI-Tests-ar.2.mcz' 'FFI-Examples-ar.1.mcz' ) keysAndValuesDo: [:t2 :t3 | t1 value: t2 * 2 - 1. reader := repo versionReaderForFileNamed: t3. t1 value: t2 * 2. version := reader version. version workingCopy repositoryGroup addRepository: repo. version load]]. (Smalltalk at: #ExternalType) initialize. ^ (Smalltalk at: #ExternalStructure) compileAllFields

1 0

Re: [squeak-dev] Re: A New Community Development Model
by Norbert Hartl 03 Jul '09

03 Jul '09

Hi Klaus, as these are the times to deal with community and feelings your answer is a perfect sample what drives people like me away. I really don't like to be offensive so please don't take it too literally. As an introduction I think I am making a good point that is close to obvious. Neither is bugs.squeak.org a closed tool where I have to register first nor must I have been working for years with it to judge about its state. I can just look at it. All I wrote is just my impression how I encounter squeak. And I'm writing this even if I always have to think twice before posting to squeak-dev. > On Thu, 02 Jul 2009 09:02:20 +0200, Norbert Hartl wrote: > > ... >> For the new setup to work well there is still one thing to do IMHO. Sooner or later the bug tracker should help in organizing and >> documenting changes. But mantis is in an awful state. > > Are you a Mantis user? I checked reporter id's but didn't find one matching your name. > Why are you asking this? For me it has nothing to do with what I wrote. But for me as a squeak user it sounds like "Who are you to speak up against our work? What have you done to dare?" Maybe I'm sensible for this but it sounds like to put others first in a defensive state. From this on in my imagination you are already wearing a grey beard. To me it doesn't sound welcoming at all. For your information. I'm a mantis user? yes. You could find me in the bug database? yes. I did ground breaking work for squeak? no. >> There are nearly >> 2200 tickets in the database. Coming from the outside it looks like really nobody cares. > > Except to those people who use it. For example, Ken has recently closed bugs which have fixes in 3.10.x ... > That is what I said! I never said that mantis is not used or obsolete. I was referring to the amount and the age of the tickets. But if you want to frustrate people than just say "Works for me". IMHO every other is confused by a ticket system that contains tickets that are 5 years old and have a rather massive amount. But the biggest problem is that I can easily assume nobody of you has an overview over the open issues. So beside being confusing what are these tickets helpful for? If they are obsolete close them. If they are real bugs nobody cared the last 5 years so they can't be that important. Norbert > /Klaus > >> A bug tracker with less tickets and tickets that >> give an overview what is going on right now is essential. Maybe not for the gurus and old timers but for everyone else (e.g. me). I would like to propose a cleaning initiative of mantis. I would expect a lot of these old bugs to be obsolete by now. So a quick check if this bug is still valid can be done. And then if it is invalid you just need to close it. >> >> Norbert >> > > >

7 11

ipod touch os v2.x user needed
by John M McIntosh 03 Jul '09

03 Jul '09

It seems I need an ipod touch user who has not yet upgraded to OS 3.x yet. This is so I can test something on a 2.x machine because we've managed to upgrade all our devices to 3.x and you can't downgrade them in order to confirm your changes work on a 2.x device. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

Sake/Packages Screen cast
by Keith Hodges 03 Jul '09

03 Jul '09

Hello all, In an attempt to get some documentation together, I thought I would experiment with screencasting. For those who havent had a chance to look over Sake/Packages I have just done a screen cast about it. This video also demonstrates MC1.6 (using SystemEditor) to load Seaside29 ftp://squeak:viewpoints@squeak.safeprayer.com/bob/docs Keith p.s. also available at: www.vimeo.com/groups/squeak

1 0

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

Problem with fork
by Mariano Martinez Peck 02 Jul '09

02 Jul '09

Hi folks! I am doing some benchmarks and I having problems with fork (I think). I have this method collect: collect |semaphores tr| semaphores := Array new: 10. tr := ThreadSafeTranscript new. tr open. 1 to: 10 do: [ :index | semaphores at: index put: Semaphore forMutualExclusion ]. 1 to: 10 do: [:i | [ tr show: 'one fork'; cr. (semaphores at: i) signal. ] fork ]. semaphores do: [:each | each wait ]. tr show: 'all forks proccesed'; cr. What I want is that the method collect returns when ALL of the forks created inside, are finished. Obviously in my real code, I don't do a transcript show: but another thing. I would expect something like this: one fork one fork one fork one fork one fork one fork one fork one fork one fork one fork all forks proccesed But the output is: all forks proccesed one fork one fork one fork one forkone fork one fork one fork one forkone fork one fork one fork one forkone fork So, I guess it isn't working :( I don't know too much about forks so any help is welcome! can be a problem with ThreadSafeTranscript ? If so, how could I test if my code is working as expected ? Thanks, Mariano

3 8

DeltaStreams again
by Göran Krampe 02 Jul '09

02 Jul '09

Hi! I noted more mentions of DeltaStreams and some info: - DS is not in a usable state yet. Unless you are suicidal. :) - I support the proposed commit model using MC. - ... it turns out Igor *is* suicidal, he just joined up! Great! Hopefully Igor and I can move DS to a usable state relatively quickly and then we can see how it can complement the model. We are focusing on these things now: - Get all green bar. (both) - Get Tirade hooked in for fully workin fileout/filein. (Göran) - Whip up a DualDeltaSorter UI. (probably Igor) There are lots of other details, refactorings, ideas etc. But all things in due time. regards, Göran PS. I will go on vacation tomorrow for 4 weeks. Not much will happen during that time period from me.

1 0

Re: [squeak-dev] A New Community Development Model
by Norbert Hartl 02 Jul '09

02 Jul '09

Hi, > Norbert Hartl wrote: >> On Thu, 2009-07-02 at 00:33 -0700, Joshua Gargus wrote: >> >>> Norbert Hartl wrote: >>> >>>> Hi, >>>> >>>> this proposal is really a step towards openness. I'm glad you added the inbox to your original proposal. Without that it wasn't really welcoming work from others. >>>> >>>> I still don't think that Monticello is the right way to go. It doesn't really manage changes. I can so easily overwrite a change that was applied before that it is hard to use. You can argue that you have to be careful anyway and that you can merge. You are right but still it is hard to use. >>>> >>> Do you have an alternative? I use Monticello every day in a >>> heavily-developed commercial codebase, and don't run into significant problems. >>> >>> >> Yes, I did this, too. In my own team the only problem was dependencies. But in a more loose environment like this there are other things to be aware of. Having an inbox that is world-writable is a good thing. But if you use Monticello that does not have a notion of change but contains the new source code than every day you don't harvest that archive it will detoriate. If you not use the same image as the originator of the source package than it will eventually show a lot of changes. Only some of these are your own changes. It is much more difficult to integrate those package and the have to danger to introduce regression very easily. >> > > That's a good point. It's difficult to predict how well it will work in practice. But, it's even more difficult to design better tools when we don't see where the current ones fail. >> >>>> Another thing is pharo. All of my contribution to the >>>> image I did in pharo because I never saw much a chance to do this in squeak. Now it can be doable. And doing something in pharo and not be able to do it in squeak at the same time strikes me really. Using always Monticello with full source compare will prevent applying fixes from one team to the other. The sources are just more different every day. >>>> >>>> >>>> >>> Again, do you have an alternative? I don't think that there currently exists a technical solution to this problem (nor can one, to the extent that the codebases really are different). Maybe someday Squeak and Pharo will merge, but that will be after we overcome social challenges, not technical ones. >>> >>> >> Well, goran took his chance to speak up. There is DeltaStreams und MC2. While there is a risk using this pieces of software the benefit could be really big. First you would give one of these tools the chance to become a part of the overall that they deserve. And they try to eliminate the problems that are experienced with changesets and MC. So there has to be a point in using it. These are good tools but they all tend to starve because at the end nobody dares to try it and to migrate if you not promise that it is already rock solid and matured. I don't think this is "how it works [tm]". >> >> I just think that at this particular moment where everybody has woken up and a little wave is making its way there could be a chance to finalize one of the newer products. >> > > Personally, I have a tendency to over-engineer and build "The Right Thing" the first time. Following the example of my excellent > colleagues, I have learned to resist this impulse to a certain extent. > > In this case, I don't see any danger in using the currently-available tools. In particular, I don't see anything in the process that makes it difficult to experiment with or adopt better tools as they become available. On the other hand, I perceive some risk to the current momentum if we make the process contingent on tools that may not yet be ready for the task. > > I would think the same if I would ignore the discussion about these topics in the last months/years about this topic. DeltaStreams and MC2 are there because there are experiencable shortcomings they want to solve. As far as I can tell both are in a usable state but not fully matured, yet. But they have state where there might be used for such a project. And this is a work this community can survive for the first weeks. Norbert >>>> For the new setup to work well there is still one thing to do IMHO. Sooner or later the bug tracker should help in organizing and documenting changes. But mantis is in an awful state. There are nearly 2200 tickets in the database. Coming from the outside it looks like really nobody cares. A bug tracker with less tickets and tickets that give an overview what is going on right now is essential. Maybe not for the gurus and old timers but for everyone else (e.g. me). I would like to propose a cleaning initiative of mantis. I would expect a lot of these old bugs to be obsolete by now. So a quick check if this bug is still valid can be done. And then if it is invalid you just need to close it. >>>> >>>> >>>> >>> Good point. I'm hopeful that the process that Andreas describes will lower the barriers to addressing some of the bugs listed in Mantis. >>> >>> Cheers, >>> Josh >>> >>> >>> >>>> Norbert >>>> >>>> >>>> >>>> >>> >> >> >> >> > > >

1 0

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

SqS is down
by Igor Stasenko 02 Jul '09

02 Jul '09

Do you need more proofs that Murpy's law works? "Anything that can go wrong, will go wrong." As always, in the middle when i using it: "Whatever can go wrong will go wrong, and at the worst possible time, in the worst possible way." :) -- Best regards, Igor Stasenko AKA sig.

1 0

Jump to page: