November 2008 - Pharo-dev - lists.pharo.org

[Pharo-project] New pharo-dev based on 10144
by Damien Cassou Nov. 11, 2008

Nov. 11, 2008

https://gforge.inria.fr/frs/download.php/10934/pharo0.1-10144dev08.11.3.zip Always downloadable from: http://code.google.com/p/pharo/wiki/Downloads -- Damien Cassou http://damiencassou.seasidehosting.st

1 0

[Pharo-project] New pharo-dev based on latest version
by Damien Cassou Nov. 11, 2008

Nov. 11, 2008

http://gforge.inria.fr/frs/download.php/10931/pharo0.1-10142dev08.11.2.zip always available at: http://code.google.com/p/pharo/wiki/Downloads?tm=2 -- Damien Cassou http://damiencassou.seasidehosting.st

6 16

[Pharo-project] Sake Basic Documentation
by Keith Hodges Nov. 11, 2008

Nov. 11, 2008

Introduction ============ Sake-Core -- is an attempt to provide similar functionality to Make and Rake, only using Smalltalk as the DSL. Sake-Packages -- is a reimplementation of Universes functionality, using Sake. It allows the metadata, load script, and unload script for a package to be defined as a Task. Sake-Scheduler -- provides the ability to register tasks to be performed periodically. Sake-Bob -- is a tool for building and testing images. (wip) Basics ====== Tasks are typically defined class side, but can be added to any class in the image. A typical task definition follows. MakeTheTea classSide >> #taskMakeTea SakeTask define: [ :task | task dependsOn: { MakeTheTea taskBoilWater. }. task if: [ Cup isEmpty ]. task action: [ Cup add: 'tea'; add: 'water'. ]. ]. To run the task: MakeTheTea taskMakeTea run. Alternatively #runStepping, or #runLogging are available for debugging. The main structure of a sake task is defined by #dependsOn: (or #addDependency:) , #if: , #action: (or #addAction:). These can all take either blocks, or lists of tasks, or lists of blocks. To see the heirarchy of tasks that will be traversed. MakeTheTea taskMakeTea what explore. Run Order ========= There are two algorithms available for determining task run order. (Further algorithms could be defined in order to support parallelism in processing.) Given a single top level task, standard Rake ordering, simply runs all the dependancies first, for every task. However Sake-Bob, when given a list of things to do, has to analyse the dependencies to determine which needs to go first. (Universes does this) Parameters ========== Unlike Rake, tasks can be defined in terms of parameters. The typical unparametized tasks found in Rake, #taskCreateMyStartingDirectory, can be written more generically as: #taskCreateStartingDirectory: name. e.g. task dependsOn: { self taskCreateStartingDirectory: 'wip' }. Class Tasks =========== In the following examples #Cup is used where the class Cup, is not guaranteed to exist. task dependsOn:{ (SakeTask class: #Cup) exists } "create a needed class" task dependsOn:{ (SakeTask class: Object) subclass: #Cup } "create a needed class" task dependsOn:{ (SakeTask class: Object) subclass: #Cup category:'Demo'} task dependsOn:{ (SakeTask class: #Cup) removeSelector: #tmp } task dependsOn:{ (SakeTask class: #Cup) removeSelectorsMatching: '*' } task dependsOn:{ (SakeTask class: #Cup) removeSelectorsMatching: '*' } task dependsOn:{ (SakeTask class: #Cup) ifExistsDo: [ :c | c rename: #Glass ] } MetaData ======== Each Sake task contains a dictionary, SakeInfo that can be used simply to store any arbitrary metadata. task info someField: someValue. Sake-Packages uses metadata extensively, in this case the typical use pattern is begin with a subclass of SakeTask and to define the generic task on the class side and the metadata on the instance side. SakeTask subclass: MakeADrink. MakeADrink classSide >> #taskPourADrink: aDrink self define: [ :task | task perform: aDrink. task if: [ Bar containsBottle: task info name ]. task action: [ Glass add: (task info name). ]. ]. Documentation Methods ===================== Subclasses of SakeTask, utilise a specialised compiler, which allows raw text to be stored in instance side methods following six quotes. """""" aTaskClass at: selector category: cat putMethod: code doc: content aTaskClass docAt: selector. This is used by the Mantis package to pull raw data from mantis, so that subsequent tasks can process that data. SakeSignal and trace: ===================== If a task needs to communicate with the outside context, it can sends a SakeSignal, a utility method is provided for this. task lookup: #aSelector. The outside context can return a value, by defining an exception handler for SakeSignal. The default implementation of #trace: is used in Sake-Tests for a task to signal to the outside testing context what it is doing. Tasks send #trace: and the SakeTaskTest runCaseWith: block, defines an exception handler to collect the signalled values so as to record the actions of the tasks. For the tests to pass all of the required actions must have been signalled. SakeStep and SakeStop ===================== task step: 'Are you Sure'. Signals a notifier to request confirmation. task stop: 'It Broke'. Finishes processing. Task Extensions =============== In the same manner as magritte. A class side task definition may be extended by another package. #taskDoThis, may be extended by adding the extension method, #taskDoThisAndAlso: task. task addDependency: [ ... ]. task addAction: [...]. Answering Notifications ======================= Tasks are wrapped in notification handlers, to use them: task answer: '*password*' with: 'secret'. ================================ Sake. Below is a SakeTask as generated from the universes package definition. What follows is a "method", in the class PackagesSqueak310U. So here is a Sake Task Definition for Seaside.... (info is simply a dictionary for non-essential meta information) ---------- PackagesSqueak310U -i- Seaside self name: 'Seaside'. info category: 'Web Development'. info description: 'A framework for building sophisticated web applications in Squeak. Develop for the web using reusable, embeddable components and unique call/return semantics for moving between pages.'. info maintainer: 'Lukas Renggli <renggli(a)gmail.com>'. info homepage: 'http://www.seaside.st/'. info squeakMapID: ''. info url: 'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'. info version: '2.8.522'. info provides: #(). self dependsOn: #('KomHttpServer'). self load: [ Installer installUrl:'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'. ]. self unloadDependsOn: { self taskUnloadDependants }. self unload: [ Installer unload: 'Seaside'. ]. ------------- Notice that we have an unload block as well as a load block! This is a new and very experimental feature, we can now define unload scripts for each package, and Sake/Packages provides a way to capture and publish them for some or all image versions. Indeed this feature is barely tested, I mention it here simply to intoduce the concept. usage: PackagesSqueak310 new Seaside load. or, (PackagesSqueak310 named:'Seaside') load. PackagesSqueak310 new Seaside unload. or, (PackagesSqueak310 named:'Seaside') unload. Packages/Sake is also supported by Installer in a manner similar to universes support, e.g. Installer sake addPackage: 'PackagesA'; addPackage: 'PackageB'; install. enjoy... best regards Keith p.s. to load Installer install: 'Packages'. ========== Addendum: Sake/Packages no longer uses blocks as standard, but the principle is the same.

2 2

[Pharo-project] Installer Bug ?
by jannik.laval.gmail Nov. 11, 2008

Nov. 11, 2008

Hi all, I'm testing Installer, and I have a problem. When I do this : (Installer sm package: 'Labby & Walker'; versions) explore. I have a list of 3 elements (there are three versions), it is ok. But these elements are InstallerSqueakMap which contain a list of packages with the first is the name 'Labby & Walker' and the others elements are the three versions. I think it is strange to have this structure. I think a good result would be : - just one InstallerSqueakMap with the three versions inside (in the variable 'packages') - or an orderedCollection with each version. Anybody could test and help me? maybe we could correct this? Thanks Jannik

2 2

[Pharo-project] FreeType
by Gary Chambers Nov. 11, 2008

Nov. 11, 2008

Hi all. Using the latest FreeType (admittedly on a 3.9 image, though probably generally applicable) we are noticing quite a lot of cache thrash, meaning that the low-level glyph rendering is happening quite often. Really noticeable on slow machines (our deployment target has 800MHz processors). Was wondering if it might me a good idea to move the cached form rendering into a plugin (lots of bit manipulation in Squeak code loops)? We've stabilised thing for the moment by hanging onto the LogicalFonts used and modifying the real font lookup to reuse existing matches and switching to CRT mode (3 times quicker). First use of glyphs at varying subpixel positions miss the cache though. Regards, Gary.

4 6

[Pharo-project] Re: Sake, Packages, and deployment code
by StÃ©phane Ducasse Nov. 11, 2008

Nov. 11, 2008

You should show me sake. Because this is still really fuzzy for me. Stef On Nov 10, 2008, at 10:59 PM, Damien Pollet wrote: > Hi, > > I'm looking at Sake and Packages, and I'm wondering if it would make > sense to use them in a slightly different manner. > Currently, the Sake-Package classes duplicate the various existing > universes (most of them are generated from the universe descriptions), > so for end-developers it's basically the same, except there is no nice > OB-based UI for it. There is a difference though: sake package > descriptions are saved in Monticello. > > What I'm thinking is, it would be nice to have a kind of deployment > scripts for some projects, that is written and maintained by the > project authors and not an external guy. For instance, Doru wrote > PRDistribution to generate the Pier kernel in the one-click image, > which is pre-filled with a set of pages, access rights, etc. The > problem is, PRDistribution relies on all the code already being > present, and will fail if you forgot to install Pier-Blog, for > instance. > > So it would be nice if it was able to install the required packages > form Magritte, Pier, and Pier-Addons. Then it would act as a clear > entry point for users of the code, and a nice place for developers to > put stuff that currently goes into class initialization methods (like > the Licence-popping in magritte and pier, or the login/password > stuff). > > The pattern could look like this: > > - application developersâ¦ > package their application code in Foo-Subfoo packages > package their tests in Foo-Tests packages > package deployment stuff it Foo-Setup: dependancies between > individual Foo-specific packages + dependancies to high-level external > dependancies + deployment scripts like PRDistribution > (maybe) copy snapshots of Foo-Setup to a common repository > - code usersâ¦ > know that Foo-Setup will help them get a working installation of > Foo when they browse Squeaksource > install Foo-Setup package using Installer, then call one of the > sake tasks it defines (there can be several of them since they are > quite high-level) > - distribution maintainers (e.g. the other Damien)â¦ > pull carefully chosen versions of Foo-Setup into their repository, > and maybe maintain a distribution-specific -Setup package. > > What do you think? > > ps. remarks on Sake-Packagesâ¦ > IMHO the root class should be packaged separately from its subclasses, > since the former provides the code and the latter define the metadata > for particular distributions. > Also since the rules are somewhat like unit test methods, they could > be named taskFoo instead of just Foo. That would differenciate sake > rules from utility smalltalk methods. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

1 0

[Pharo-project] SUnit extensions and icons OB support
by StÃ©phane Ducasse Nov. 10, 2008

Nov. 10, 2008

Hi david can you tell me what I should do to get the icons showing the status of tests in your browser? I should harvest the Sunit extensions and then? Stef

5 14

[Pharo-project] update #10144
by Marcus Denker Nov. 10, 2008

Nov. 10, 2008

- ifNotNilDo: calls renamed to ifNotNil: - Issue 232: Recreate Special Objects Array should preserve external semaphores + Fix -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

2 4

[Pharo-project] HostWindows rewrite
by Igor Stasenko Nov. 9, 2008

Nov. 9, 2008

Hello list, i started design of new plugin, which is conceptually based on HostWindows, but will be more integral & flexible. The plan is to move windowing & events handling into new plugin and at same time, completely remove cruft from basic VM functionality. - you are in total control when to create a window - multiple windows support (will require refactoring in Morphic code) - control the window style/appearance, including: title, titlebar presence, window icon, size & position, pixel format, transparency (aka layered window), border style (resizeable or not, or completely w/o border ) - control video modes (if its provided by platform) and fullscreen window mode - events are now bound to particular window - different notification events like changing window position / activating or deactivating Plugin is publishing a list of available window attributes. Different platforms, depends on implementation, may or may not support different window attributes. Instead of spawing dozens of primitives , like setWidth/setHeight/setTitle/getTitle etc etc, plugin will have only two primitives - get/setWindowAttribute. So, to set an X position of window, a code will look like: window primAttributeAt: #x put: 10. or to hide window: window primAttributeAt: #visible put: false. or to set multiple attributes in batch manner: window primSetAttributes: { #x -> 10. #y->20. #visible->false. }. I'll try to cover a most basic attributes, available on major platforms for the initial implementation. What you'll never see in new plugin: - native widgets support or any kind of dealing with native widgets/controls. Awaiting for your comments or suggestions. -- Best regards, Igor Stasenko AKA sig.

5 9

Nov. 9, 2008

Hi all I just want to share a part of my vision for pharo with you. This email is raised by the discussion around SunitExtensions. Of course we should look at what the other people are doing. Now I think that this is really important that we incrementally adopt and have the courage to experiment little features at a time. For example lukas and alex enhanced the MC browser and they would have never done it as a specific task. We are all busy and improvements will go that way step by step with sometimes large chunk like MC2 or other but the main drive will be incremental. and we should let incremental change a chance else we will not make progress. Now of course I would love to be able to hire an engineer working full time on pharo. but right now we cannot. Stef

1 0