Squeak-dev August 2007

squeak-dev@lists.squeakfoundation.org

132 participants
163 discussions

Heap>>first broken?
by Andreas Raab 25 Oct '07

25 Oct '07

Hi - Just stumbled over this: self should:[Heap new first] raise: Error. Right? However, in Squeak 3.9 and later it doesn't. From the 3.9 change log it appears it got introduced here: ------ Change Set: decompileBlock-md Date: 24 November 2005 Author: Marcus Denker A simplification for BlockContext>>decompileBlock: The Method got the tempNames by compiling the source of the method. This is already implemented in methodNode tempNames... thus not needed here. ------ remove emptycheck for Heap>>fist and SequencableCollection #first, #last, #middle ------ but no comment as to why. Any insights into the reasons for this change anyone? Cheers, - Andreas

3 2

DeltaStreams again
by Göran Krampe 05 Oct '07

05 Oct '07

Hi! After yet another night of hacking I have come a bit further. I started working on #apply and #revert. #revert is implemented like: self asAntiDelta apply ...and asAntiDelta is more or less done by: changes reverseDo: [:each | antiDelta addChange: each asAntiChange] ...modulo my memory. ;) I came as far as a test case where I create a DSDelta with three changes: - Create class - Change its comment - Add two ivars ..and then can nuke the class, apply delta (Johnny is back!) and revert delta (Johnny is gone again!). Well, apart from some buglet in SystemEditor regarding class comment - this works. DSDelta>>apply looks something like: ^self class applier apply: self Which means the actual apply code is broken out into an "applier" object which uses double dispatch on all change instances to do the work. I am implementing a DSSystemEditorApplier. Well, that is it for now. :) Note though that I am doing a bit of "spiking" here - all kinds of changes are not working yet and so on. regards, Göran

3 4

Package Universes and Squeakmap
by Keith Hodges 23 Sep '07

23 Sep '07

I have been using package universes for a few days, and have discovered some of its limitations. I have also been wondering how best to integrate its use with SqueakMap. We already have SqueakMap as the master repository and Lex, the creator of package universes does not seem to think that simply tagging items in SqueakMap according to what works with what and what doesnt would work very well, all things considered. To a certain extent I now agree with him. I initially thought that having Universes separate from SqueakMap was a bad idea. However, after using universes I have now changed my mind and think that is a good idea. I imagine SqueakMap to be the Model, and Universes to be the View, with the community acting as the controller so to speak. One of the limitations of Universes is that it does not have much in the way of integration with Squeakmap or Monticello, and so it looks to be attempting to make SqueakMap obsolete, but it is somewhat of a poor replacement. At present it is totally agnostic to the package provider, it simply loads a package from a url based upon the file's extension. One of the positive things about SqueakMap is that it caches the packages, it also has more information on it than the universe. I think that it too would benefit from some feedback features, and more openness, and some indication of dependencies, but perhaps it makes sense not to have these as hard and fast rules. For example, Seaside specifies Kom, but some users may prefer Swazoo. This flexibility seems difficult to support prescriptively on the macro level, but could be supported in local mini/sub-universes, such as a "Swazoo users seaside universe". Perhaps SqueakMap could allow anyone to upload a new version, but reserve "blessing" of releases to the owner/maintainers, since this is how a public squeaksource repository works by "social" default. One Universe limitation is that when using a Universe package, unlike an installer script which integrates with the native monticello tools, the package is loaded, but the Monticello browser is not informed of the repository details. This means that you have to manually inform the Monticello Browser of the required repository before a monticello package with dependencies referred to in a package universe will work. For example when Chris posted 'Magma Server' he would have had the Monticello Browser properly configured on posting the package to the Universe and it will work for him but it will not work for users out of the box who do not have the Monticello repositories configured. So thinking about it this it would not be a problem at all if Package Universes replaced: http://www.squeaksource.com/Magma/MagmaServerLoader-cmm.25.mcz with: Installer squeaksource project: 'MagmaTester'; install: 'MagmaServerLoader-cmm.25'. So why not have Package Universes call installer for SqueakMap items too. Installer squeakmap install: 'MyPackage(1.0)'. (I will fix installer to fall back onto using the http interface #websqueakmap if SMSPackageLoader is not present) By doing this we can uphold the use of SqueakMap as the place to publish released packages, with Universes being the place to define dependencies within a locally defined context/scope/use scenarios. If the "publish to squeakmap" button could be fixed on squeaksource the picture would be complete. This approach also allows mantis fixes and change sets to be included in the Universes without any extra work. thoughts feedback? best regards Keith I think that having universes, together with sub-universes and personal-local universes

10 25

Re: Linux desktop manager Close Window is dangerous.
by bradallenfuller＠yahoo.com 23 Sep '07

23 Sep '07

On 8/29/07, Brian Brown <rbb(a)techgame.net> wrote: On Aug 28, 2007, at 8:43 AM, Brad Fuller wrote: > > In fact, I'm now thinking this should be labelled a defect. What do > you think? If the user is likely to lose data, then yes. I usually use Squeak full-screen, and IceWM asks me for confirmation anyway. == Really? Wow, I don't remember KDE nor Gnome asking. Xfce4 certainly doesn't

6 5

New mock objects framework
by Denis Kudriashov 18 Sep '07

18 Sep '07

I realize new smalltalk mock objects framework named BehaviorMockup with SSpec functionality. There is Squeak (http://www.squeaksource.com/BehaviorMockup.html) and VW versions (cincom public repository) Simplest language for behavior specfications: [:mock | mock someMessage] should strictly satisfy: [:mock | mock someMessage willReturn: 'some'] or [:mock | mock someMessage] should lenient satisfy: [:mock | mock someMessage willReturn: 'some'] SSpec functionality: - 5 should equals: 6 - and ... For more detailes see Wiki on SqueakSource and many acceptance tests in package Best regards, Denis

2 1

[ANN] FixedDecimals
by Chris Cunningham 08 Sep '07

08 Sep '07

Hi. I've just release a package FixedDecimal on SqueakSource. A FixedDecimal is similar to a ScaledDecimal, but different in certain select ways. It's primary purpose was to be able to represent precise decimals for such things as representing money - where ScaledDecimals leave something to be desired. For instance, with ScaledDecimals, you get: (33.333s withScale:2) + (33.333s withScale:2) print it yields 66.67s but with FixedDecimals, you would get: (33.333 asFixedDecimal: 2) + (33.333 asFixedDecimal: 2) print it yields 66.66. So, FixedDecimals round the numbers to the exact scale you specify - converting a float to a FixedDecimal and back will not necessarily return the starting number, unlike ScaledDecimals. Most simple arithmetic is defined for FixedDecimals, but not all methods that probably should be (it's getting late and I'm going away for the weekend - thought I'd publish what I have). Thanks, Chris

3 5

[ANN] UI Enahncements released
by Gary Chambers 04 Sep '07

04 Sep '07

Available on the development universe under the "User Interface" category.

11 21

[OT] looking for Beta Testers for a Second Life related tool written in Squeak
by Michael Rueger 02 Sep '07

02 Sep '07

Hi all, this is probably more than slightly off topic, but we (Impara) are looking for beta testers for a Plopp based sculpture modeling tool for SecondLife. Assuming that there are people actively using SecondLife :-) Can't really imagine ;-), but for those who don't know yet, Plopp is a 3D painting tool for kids, based on the Teddy algorithm and written in Squeak (http://planet-plopp.com). People interested in testing the tool and especially giving feedback on the exported results on Mac, Windows or Linux would need a SecondLife account and the ability to upload objects. Please reply to me off-list if you are interested. Thanks and apologies for this off-topic, shameless self promotion :-) Michael

4 3

Some Delay tweaks
by Andreas Raab 02 Sep '07

02 Sep '07

Hi - Just FYI, I've updated http://bugs.squeak.org/view.php?id=6576 with another change set containing a few relevant tweaks to Delay. The most important one is probably the one which ensures that Delays get unscheduled if the process they wait for is terminated. The problem is that delays which are scheduled are kept in the SuspendedDelays even after "their" process terminates. So that, for example a "(Delay forSeconds: 9999999) wait" (with an Alt-Period following it) would leave that delay being scheduled for expiry 100 days from now although its process is long gone. The tweaks also ensure that delays which actually expire in Semaphore>>waitTimeoutMSecs: don't get unscheduled twice (since unscheduling is a linear search over all scheduled delays it should be avoided). Lastly, there is a bit of bullet-proofing to Delay>>handleTimerEvent since each poll of the msecs clock has the potential to overflow and needs to be guarded explicitly. The tweaks make sure there is only one such poll and consequently only one place to check. Except from another obscure situation which the change set addresses as well. In any case, it's a nice roundup for the Delay changes. If you're using the first one, you should probably use this one as well. Cheers, - Andreas

3 2

Re: pipe
by Alan Kay 01 Sep '07

01 Sep '07

Just a kibitz from the peanut gallery.... It's not a question of functionality, but of simple readability and writeability. This idea has come up a number of times in the past, and it is a very reasonable one. In fact, there are a number of other perfectly reasonable additions that would be nice to have in Smalltalk. The basic idea of having a flat precedence for binary operators came from the same practice in APL -- if you have a zillion of them, then just using grouping instead of precedence can be a reasonable solution. But, for example, the "." could be considered to be a kind of operator (that is like a procedural "AND") that tests to see if the previous expression SUCCEEDed before moving to the next expression. We could think of it as being defined in Class Object. If we think of "precedence" then we want everything else in expressions to be more closely bound. This opens up the possibility of having something like "|" (apologies for using this for a different purpose) to deal with the "OR" case. So if an expression FAILs, then the OR path will be taken. It is easy to see why we should use precedence ideas here to avoid parentheses. Note that the overloading of these operators with a little more processing could lead both to a "Prolog" way of thinking about things on the one hand, and a way to think of parsing and searching, on the other. Both of these would be great additions to the basic semantics of Smalltalk. And so would pipes. They provide a syntactical way of writing very useful sequences of processing that is much nicer than functional application syntax (which gives a difficult to read "backwards view"), and Haskell did absolutely the right thing in making an operator for this. Since Squeak is a completely open Smalltalk, and intended to be extended in major as well as minor ways, there is no reason whatsoever to prevent these ideas and more to be added (and I wish that people would take it upon themselves to extend the language). Cheers, Alan At 11:40 AM 8/25/2007, Jason Johnson wrote: >On 8/25/07, Fabio Filasieno <fabio.filasieno(a)gmail.com> wrote: > > > > check this out ... > > > > (((((((((((obj message1: param) message2:param) message1: param) > > message2:param) message1: param) message2:param) message1: param) > > message2:param) message1: param) message2:param) message1: param) > > message2:param > >This is a bit contrived. If you ever did find the need to do this it >should look like: > > >(((((((((((obj message1: param) > message2:param) > message1: param) > message2:param) > message1: param) > message2:param) > message1: param) > message2:param) > message1: param) > message2:param) > message1: param) > message2:param > >Code smell to be sure, but you pile what you don't like on one line >and say you can't read it while formatting what you do like and saying >"see!". > > > The pipe is needed to support a pipe&filter style of programming. That > > perfectly works with Smalltalk syntax, and truly > > opens up a better way of doing functional transformations. > >pipe&filter style of programming? Most people call this "functional >programming" and it doesn't require a pipe operator to work. Such an >operator can make certain code cleaner to be sure, but it doesn't >"open up a better way of doing functional transforms" by any means. >Just saves you one character per function call. > > > >>>>>>>>> cascade is useless <<<<<<<<<<<< > > > > because it's redundant : > > > > Example : > > > > point x:10; y:10; z:10. > > > > Your could write in fact. > > (((point x:10) y:10) z:10) > > since x:10 returns self anyway, y:10 returns self anyway and z:10 returns > > self anyway. > >In this case yes, one could use parenthesis, the cascade operator or a >new statement delimiter (which you call "pipe"). But sometimes you >wish to send a bunch of messages to an object that may not return >self. > > > With the pipe I removed parenthesis from much wider selection of cases, I > > enable a cleaner way of writing functional transformations, and therefore > > it's a better design. > >You don't have a conflict between cascade and your "pipe" unless you >want to use the ; symbol. Cascade is a special message that causes >the compiler to put in some op codes for duplicating the cascaded >object on the stack. What you want is just the current behavior >without needing the parenthesis to disambiguate. I don't think it >would be too hard to add a new symbol that has the compiler treat it's >left side the same as it would if the statement was in parenthesis.

23 83

Jump to page: