Squeak-dev March 2009

squeak-dev@lists.squeakfoundation.org

134 participants
173 discussions

Any plans to update the supported backend of SqueakDBX?
by Simon Kirk 09 Mar '09

09 Mar '09

Hi all. I'm not sure who to contact about this, but I thought a general list email would be OK. I noticed that there's a new OpenDBX version (1.4.0) released as of last Tuedsay. Interestingly, this one supports an ODBC backend, which would of course make a SqueakDBX that supports this version particularly attractive. Is there work afoot to update SqueakDBX's supported OpenDBX version? Cheers, Simon Consider your responsibility to the environment - think before you print! ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

2 1

Elements - a Scratch-like Smalltalk
by Robert Hawley 08 Mar '09

08 Mar '09

Hi Jens I like the idea very much. However, I note you say "all rights reserved" for the experimental version. I am not sure that you want this to become a community activity - what is your view? Yours Bob

2 1

[Ann] Bob has built!
by Keith Hodges 08 Mar '09

08 Mar '09

Dear All, The long awaited Bob, the image builder has been building away! When Bob is building himself, he will be released as a one click image. This email is intended to give you an idea of how he works, in order that we can begin to develop useful scripts for building one-click images, testing etc. Bob Components ============= squeaksource/Sake Sake-Scheduler = Package providing the ability to run actions/tasks periodically squeaksource/Sake Sake-Bob = Main image building tasks, based upon sake. squeaksource/Bob-Releases = Package where we/you add your build tasks, for distributed bob build/test servers to pick up. How Bob works ============ There is a Bob build/test server running at http://bob.warwick.st you can see what he has built and what he is doing by looking around that site. He is also available via vnc display 1. User/password for ftp/vnc is as for the swiki. If you are keen you can download the currently running bob from http://bob.warwick.st/bob/home Bob picks up his assignments from the Bob-Releases package, the following is an example of a build instruction from that package. Example Bob Build Tasks =================== BobBuildDev>>#build0000 self name: 'Squeak3.10.2-dev'. self dependsOn: { BobBuildBuildBase taskBuild }. self when: true. info by: 'Damien Cassou'. self image: 'ftp://bob.squeak.org/release/Squeak3.10.2-build/release/*.zip'. self linkRelease: false. " info upload: 'ssh://updates@squeakfoundation.org/var/www/files/3.11/' , self name." info upload: 'link:///bob/release/' , info name. "http not yet supported" info download: 'ftp://squeak@bob.warwick.st/bob/release/' , self name. self comment: 'Learning to breathe'. """""" Installer sake install: 'Squeak-dev image'. ======== In the above meta-data those lines sent to #self are meta-data items that the framework knows about, those sent to #info are arbitrary meta-data that Bob ignores but are included in *.info files that Bob outputs. #name - defines where the wip/output/release directories will be, and what the final image and zip files will be named. output will be written to: /bob/output/Dev/build0000/<timestamp>/<timestamp>_Squeak3.10.2-dev.zip /bob/output/Dev/build0000/<timestamp>/<timestamp>_Squeak3.10.2-dev.info /bob/output/DevBuild/latest (symbolic link) /bob/output/DevBuild/release (symbolic link) The *.info file is the metadata filed out into a man & machine readable format. Bob uses this to compare what he has already built, with what he is being asked to build. dependsOn: - uses the standard Sake method for defining dependencies, i.e. references the actual task that is used for building the dependent. #when: - true/false/#dont/aDateAndTime/aTimeStamp/aDuration/aFile - specify a time to build, a period, or a file whose creation time is monitored to see if it changes. #image: - a match that will find one zip file in which an image is available. The file may be a) local b) remote via ftp, or c) local in the output tree having been generated from other tasks. b) remote files are cached locally. #imageCreationTime: aTime - if this field is specified then bob does NOT poll the image file to see if it has changed. This is set so as not to keep nagging ftp.squeak.org needlessly on images such as Squeak3.7-basic. #linkRelease: true/false - indicates whether or not this is to be designated a release via a symbolic link. Notice how the #image field is picking up the latest "release" of 3.10.2-build via the "release" symbolic link, rather than the "latest" symbolic link. The result of the build is packaged into the ftp://bob.warwick.st/bob/output directory tree, also visible via http://bob.warwick.st/bob/output #upload: aDirectory - a destination directory to send package in the output directory to - options are: 1) ssh:// perform the upload via ssh (but not as part of the build, this will be done by a separate uploading thread) 2) link:// perform the upload by linking the /bob/output/Dev/yymmdd-hhmm to the bob/release/Dev/yymmdd-hhmm directory which may then be rsync'ed to a mirror ftp site. This is the option that bob.warwick.st uses to upload files to ftp.squeak.org, because the user that bob is running under does not have access to ftp.squeak.org, but the user which performs the rsync does. This allows bob.warwick.st to be made public via vnc, without compromising the security of ftp.squeak.org 3) list:// perform the upload by adding the file to a list, which can then be used as an input to rsync in an external process. 4) file:// perform the upload by copying the files to a directory locally. #download: Bob will look at the download location to determine whether or not an upload is required. Multi-Bob-Collaboration ================== For each instance of Bob the choice of targets to make is specified by creating the output directory e.g. /bob/output/Dev. If the output directory does not exist locally bob will not build that target. Multiple distributed Bob's collaborate by using #image: that are available via ftp, as generated by another bob. Thus your bob can wait for my bob to release a new Dev image by pointing to ftp://bob.warwick.st/bob/release/Squeak3.10.2-dev/release/*.zip Only one bob should be designated as an uploader to the final ftp site (see BobConfig and discussion about Configurations later on) Multiple Bob threads on a single server collaborate by using the "locks" described below. Within Sake a task can raise a SakeBlock exception, Sake then trys to find another task that it can do in the meantime, returning to the blocked task later on. If a Sake task discovers that all of its dependent tasks are Blocked it too raises a SakeBlock exception. If a bob thread finds his tasks blocked (i.e. in progress) he will try again later. Blocking - Multi-bob-collaboration ========================= When a build is in progress this is indicated by a BUILD-IN-PROGRESS link appearing in the output directory. When an upload is in progress this is also visible in the output directory like so: "090308-1316.uploading". BobBuildImage - Starting Image ======================= Minimum Requirements for the starting image: Bob expects to find the image to build on, in a zip file, either locally or on an ftp site somewhere. The image simply needs to support the execution of a script (full path) from the command line. There are no other minimum requirements. Configuration of Bob =============== The top of the class heirarchy is like so. BobBuild -> BobConfig -> BobBuildImage BobConfig is purely used for configuration options. You will need to configure the parameters, such as : #configSqueakVM - path to the vm #configBaseDir - the base directory in which to work, default is set to '/bob'. #configPackageCacheDir - a directory that all built images may use for their package-cache. This allows you to define a local configuration and to save it simply by filing out/in the class BobConfig. Build Scripts ========= There are two parts to the build script: 1) #theScript, and 2) metadata on the instance side as shown below. A number of useful script methods have been defined for you. Each is generated into a chunk of the script file that is handed to the image on start up. This is an example #theScript. BobBuildImage>>theScript script reset. self scriptTranscriptLogToFileStart; scriptAddLPF; scriptAddInfoScript; scriptTranscriptLogToFileStop; scriptSaveImageAndQuit: true. The line #scriptAddInfoScript appends any script chunks you defined as an appendix to your metadata method: e.g. """""" "self halt." Installer sake install: 'Squeak-dev image'. Debugging ======== On the class side of each target, the methods #configStepNeeded #configStepAction, and #configStepScript are available, if you set any of these to true, it will halt at the appropriate place for you to step through the process. For debugging build scripts, the script is gnerated with a halt at the beginning of each chunk. Comments and Description ==================== The comment can contain arbitrary text. The info metadata can contain any additional fields that you care to use. However #comment and #description meta data fields are concatenated with the comment and description of any dependent images. enjoy Keith

1 0

[Election] Final call for alc... I mean, votes!
by Göran Krampe 08 Mar '09

08 Mar '09

Hi all! Ok, so we are *seven* votes short of number of votes cast last year. Ouch! NOTE: Voting period ends in about 8 hours and 30 minutes - 18.00 UTC! Please, if you haven't voted - and you *do have a ballot* sitting somewhere in your mail account - please vote! regards, Göran

1 0

SUnit broken again in squeak-dev images.
by bryce＠kampjes.demon.co.uk 07 Mar '09

07 Mar '09

This time it's the method: TestCase class>>withInheritedSelectors ^ self shouldInheritSelectors ifTrue: [ self allSelectorsBelow: TestCase ] ifFalse: [self selectors] The method #allSelectorsBelow: isn't implemented in the image so it's hard to see what this is supposed to do. Bryce

5 10

UML Diagrams
by Houssam FAKIH 07 Mar '09

07 Mar '09

Hello, I would like to know what is the tool the community use to generate UML class diagram of a class or a set of classes. I try to use Mondrian but I have no result when I execute the code. MOSmalltalkPaintings systemComplexityOfClasses: String Any help.. Thanks Sam

5 5

import VSE 2000 files in Squeak
by Houssam FAKIH 07 Mar '09

07 Mar '09

Hello, I try to import VSE 2000 files in Squeak. I have some problems related to incompatibility between the two smalltalk implementations. So I would like to know if there is a tool to help me to do the import. By the way, what is the purpose of CLU files ? By looking in the content of these files, it seems that they are very close to manifest files in J2ee applications. What is the equivalent of these files in Squeak ? Thanks for your help Sam

5 4

An old gripe (or: SystemChangeNotifier + Announcements = Sanity?)
by Andreas Raab 06 Mar '09

06 Mar '09

Folks - While doing some preferences stuff I ran into one of my "most-hated" issues in Squeak. Anyone who has ever encountered SystemChangeNotifier must have noticed how terrible it is to use it. I mean, just look at this code: prefEvent: anEvent "Check if this system event defines or removes a preference." (anEvent itemKind = SystemChangeNotifier classKind and: [anEvent isRemoved]) ifTrue:[...]. anEvent itemKind = SystemChangeNotifier methodKind ifTrue:[ (anEvent isRemoved or:[anEvent isModified]) ifTrue:[...] (anEvent isAdded or:[anEvent isModified]) ifTrue:[...] ]. just needless, pointless lines of case statements. How do people feel about replacing that mess with Announcements? If you really want to have all events you register for SystemEvent and if you'd like to be more specific you go for more specifically for ClassEvent or even more specifically for ClassAddedEvent. It would also remove the need for all of these weird tests like anEvent itemKind = SystemChangeNotifier methodKind and:[anEvent isRemoved] and just replace them with something like "anEvent isMethodRemoval". It would likely be faster too, since most places aren't really interested in *all* events either. It would mean that Announcents would have to go core but this cleanup alone seems worth it. I also suspect that adding Announcements and fixing SystemChangeNotifier may remove more code than it would add. How do people feel about that? Cheers, - Andreas

6 6

Problem with a Collection of Blocks
by Joel Turnbull 06 Mar '09

06 Mar '09

I'm trying to apply a collection of blocks to another collection to filter it. like... blockCollection := OrderedCollection new. collectionWith1and2 do: [ :tag | blockCollection add: [ :collection | collection includes: tag ]]. self halt. newCollection := collectionCollection copy. blockCollection do: [ :block | newCollection := newCollection select: block ]. It's not really behaving though. the problem is that blockCollection doesn't get two different blocks referring two two different tags, but two identical blocks pointing to second tag. I included a test method below. I inserted a halt where if you explore blockCollection you can drill down into home: and see that the date is 6 March 2009 on both blocks in the collection. Both tests fail, and I don't understand why :) If there's an alternative strategy for applying multiple filters I'd love to hear it too. Thanks, Joel testUpdateCollectionFromBlocks | newCollection | tag1 := Date year: 2009 month: 3 day: 5. tag2 := Date year: 2009 month: 3 day: 6. collectionWith1and2 := OrderedCollection new. collectionWith1and2 add: tag1; add: tag2. collectionWith2 := OrderedCollection new. collectionWith2 add: tag2. collectionCollection := OrderedCollection new. collectionCollection add: collectionWith1and2; add: collectionWith2. blockCollection := OrderedCollection new. collectionWith1and2 do: [ :tag | blockCollection add: [ :collection | collection includes: tag ]]. self halt. newCollection := collectionCollection copy. blockCollection do: [ :block | newCollection := newCollection select: block ]. self assert: ( newCollection = ( ( OrderedCollection new ) add: collectionWith1and2 ) ). self deny: ( newCollection = collectionCollection ).

3 3

mar visits callbackEnter/callbackLeave
by John M McIntosh 06 Mar '09

06 Mar '09

A few weeks back Esteban Lorenzano of Mars fame http://news.squeak.org/2009/01/08/squeak-goes-to-mars/ asked about the SqueakProxy and Objective C Bridge I've been working on, could he use it to get a callback for oh say windowShouldClose: from an NSWindow instance then have some smalltalk code run, and determine YES or NO? Well that sounds simple, should only take a bit of time,... time passes (lots) and lots of iChat and email pass by too. Now it seems the issue is that on OSX and the iPhone UI related things can only run on the main thread, so let's talk a bit about that history. When the Carbon Squeak VM was ported from OS-9 we actually started the interpreter on a background thread. This worked fine until Apple started enforcing the rule about UI related things can only be run on the main thread as they quickly revised the operating system. The VM was patched to ensure any UI related things were performed on the main thread via a cross thread callback. This worked fine until the Sophie team started to exploit Quicktime for audio/video and graphics. It turned out QuickTime calls *really* needed to be on the UI thread. We could funnel *ALL* the FFI calls to the main thread, but that is expensive. So the carbon VM was changed to co-execute interpreter() on the UI thread via polling logic, where the interpreter runs and polls for UI events to service. This solved the problem of deciding should this FFI call be on the UI thread or the background squeak thread, plus then ensured any plugins etc would always have logic that ran on the main UI thread without having the developers worry their brains over it. The curious might note this explains the odd behaviour of the carbon VM when you toast the morphic event polling process, then it fails to service macintosh menus because it's really waiting for some squeak process to invoke get next event so it can service the pending menu interaction. Now the Unix os-x vm using cocoa is less affected by this, but it will NOT run FFI based quicktime calls, also the iPhone VM is *extremely* broken if you do any UIKit stuff (even allocating UIKit objects) from a background thread. For the iPhone VM you *must* remember to execute objective C calls either on the main UI thread, or the background thread. We have to run the iPhone VM on a background thread because the trick we use for the carbon VM to make it run on the foreground thread is broken on the iPhone. Plus if you don't service UI events fast enough on the foreground thread, then the iPhone watchdog will kill you with exception code 0x0badf00d (yes really). Ok, but given the Squeak VM is running on the UI thread then why can we just deal with the windowShouldClose: Well good question, and days of work. Now it seems when get next event is called, we ask the operating system if there are any pending UI events, if so we ask the operating system to service them. Fine, now the SqueakProxy object enters the mix. On the windowShouldClose: the SqueakProxy instance at some point into this operating system call stack gets the windowShouldClose: message. So what does it want to do, well it wants to let the Squeak interpreter *run* so it can convert the NSInvocation instance into a squeak message send, send a windowShouldClose: to the Smalltalk SqueakProxy instance and set the return value, then of course return back to the caller which is 238 levels (well maybe 10) down from the Interpreter's call to the operating system request to service the UI event. Well see the problem I'm already buried in the Interpreter, but need to go back. Now fortunately others have had this *same* issue. http://bugs.squeak.org/view.php?id=6669 I note the Smalltalk code has been integrated into VMMaker many months/ years ago, but the virtualMachine.c/h has not been updated. I further note it works just like advertised. So now when the UI thread enters the SqueakProxy objective-c instance I just do if (isCarbonVM) interpreterProxy->callbackEnter(&callbackid); The simplistic viewpoint is that this call lurches the interpeter() awake (well and lots of other stuff). The smalltalk code runs, and then invokes a primitive to do the interpreterProxy->callbackLeave(callbackid) which longjmps me back to the original point of the callbackEnter() so I continue the flow of finishing up servicing the windowShouldClose: And everyone is happy. Well assuming this stuff actually works, and there isn't some pending callbackEnter/callbackLeave VM changes that have never flowed into the mix, and where how does the Alien support collide, or not collide with all this trickery. Anyway it seems Esteban might get his windowShouldClose: tomorrow. Certainly he can be the first beta tester. -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

1 0

← Newer
1
...
11
12
13
14
15
16
17
18
Older →

Jump to page: