Squeak-dev December 2008

squeak-dev@lists.squeakfoundation.org

91 participants
114 discussions

[ANN] SwaLint
by Tobias Pape 13 Mar '09

13 Mar '09

Dear Squeak community, we would like to announce the first release of SwaLint. SwaLint is a Squeak source code linting tool in the spirit of (C) Lint or SmallLint. It is intended as a developer aid to * test source code for stylistic coherence and * identify possible errors. It has been developed by Johannes Dyck, Christoph Neijenhuis, Tobias Pape, Nico Rehwaldt, and Arian Treffer during a course on software engineering held by the Software Architecture Group at the HPI, Potsdam, Germany. SwaLint is available from SqueakMap. Documentation can be found at http://swalint.netshed.de/. Tobias Pape on behalf of the SwaLint team

12 32

[ANN] - New SqueakDBX release
by Mariano Martinez Peck 20 Jan '09

20 Jan '09

We are very glad to announce our second beta release of SqueakDBX. The aim of this project is to build an OpenDBX (http://www.linuxnetworks.de/doc/index.php/OpenDBX/) plugin which will allow users to perform relational database operations (DDL, DML and SQL) through a truly open source library. The features for this release are: Bugs fixed: - Bug in odbx_query(), odbx_result() and odbx_result_finish() execution order. - Timeout in DBXPlatform #nextResultSet: was wrong mapped with FFI. Now, it is nil. - Some bugs in OpenDBXWin32 with apiCalls. New Features: -Support for SQLite in Linux -Support for MSSQL in linux and windows (with MinGW) -Support for PostgreSQL in Windows (with MinGW). -Better error handling. See http://wiki.squeak.org/squeak/6076 -New non-blocking plugin to replace FFI (just a proof of concept, but running). See OpenDBX-Plugin package in Monticello. -New SqueakDBX tutorial: how to compile openDBX in linux and windwos, common problems and solutions. You can download it from: http://www.assembla.com/spaces/Proyecto-Proyecto/documents/a0bKPg0qCr3Aeaab…. However this pdf will be converted into "wiki format" and put there. -Configurable Log. See http://wiki.squeak.org/squeak/6099 -Refactorized and updated wiki: http://wiki.squeak.org/squeak/6052 - We will be adding benchmarks on different backends and OS soon in the wiki: http://wiki.squeak.org/squeak/6063. - You must use openDBX 1.3.10 version. Useful links from wiki: - Current supported backends, operating system and squeak images here: http://wiki.squeak.org/squeak/6108 - ChangeLog: http://wiki.squeak.org/squeak/6109 - Targets and Features: http://wiki.squeak.org/squeak/6106 Again, help wanted. We are really convinced about open source projects. A software project is better when people share opinions, work, advice, comments, etc. We would really appreciate if you: -Give us opinions, comments, ideas, new features, complaints and so on. -tell us if you find a bug. -tell us if you test SqueakDBX with other RDMBS or OS different from the ones we tested. Just to know if it works or not :) Full documentation, installation and getting started instructions can be found at wiki page: http://wiki.squeak.org/squeak/6052 Packages can be installed from Universe (3.10) or SqueakMap. Current version is 0.8 Sources can be download from SqueakSource http://www.squeaksource.com/SqueakDBX (it requires FFI installed) Mary christmas, SqueakDBX team

2 3

second call for feedback on Naiad design
by Craig Latta 19 Jan '09

19 Jan '09

Hi-- This is another call for feedback on the design of Naiad[1], a Smalltalk module system I'm writing for Squeak as part of the Spoon project[2]. On the theory that I'll get more of a response by including the whole text rather than a link to it, here it is... :) *** 2008-10-20, 1946 GMT Copyright (c) 2008 Craig Latta. All rights reserved. Hi-- I've been on a quest to make Squeak smaller and more modular, the Spoon project[1]. Part one was making the object memory small. Part three is about making the virtual machine small. This message is about part two, making a module system suitable for adding new behavior to a minimal system in an organized way, and for transferring behavior accurately between running systems. Spoon's module system is called "Naiad", which is an acronym for "Name And Identity Are Distinct". It keeps track of the development history of a system (what the "sources" and "changes" files are for now), and makes it available for exchange with other systems. I think keeping classes' names and identities separate is critical for this. Following are some notes on its design and use, including the object model[1]. At this point I'd like to emphasize I am the author of this design, that I intend to release its implementation under an MIT-style license, and that I'd like to pursue a graduate degree with it (I'm open to invitations :). *** motivation A traditional Smalltalk system uses source code to express both development history and changes exchanged between systems. The precise meaning of source code depends on the current state of the system compiling it. Since a Smalltalk system is dynamic, source code is an inherently ambiguous medium across time. The most problematic system artifacts in light of this ambiguity are classes. All activity in a Smalltalk system is the result of sending messages to objects. The sending of a message invokes the execution of a method, a sequence of instructions for a virtual processor. Some of these instructions manipulate the state of the object receiving the message. Classes define the structure of that state. Therefore, when those class definitions change, the source code for the methods of those classes may become meaningless. One may confront this situation when trying to recompile source code for an old version of a method whose class definition has changed in the meantime. Similarly, source code from one system may not be meaningful on another, since corresponding class definitions on each system may change independently (or be removed entirely). This means that the accurate exchange of behavior requires manual labor, hindering the propagation of useful fixes and new code. It also means that interpretation and use of historical code is more difficult than necessary. So we pay twice for this problem: when learning the system, and when trying to share our work with others. By separating class name from identity, Naiad makes Smalltalk more approachable for newcomers, and more productive for developer and user communities. editions Using Naiad, each development system consists of two object memories: one containing developed code, and another containing "editions" which describe that code. I'll call the first one the "subject memory" and the other the "history memory". An Edition is a description of some artifact in the subject memory at some point in time, currently an author, comment, tag, class, method, module, checkpoint, or edit. Each edition has a reference to that artifact's next state in the future (the next edition) and in the past (the previous edition), as well as an author edition, a collection of licenses, and a timestamp. An Edit represents the activation of some edition at a point in time. For example, there may be a method created in 2005 that is removed in 2006 and reactivated in 2007. There would be an Edit for each of those three events, but only two method editions (one representing the method becoming active, and one representing it being removed). The history memory replaces the current changes and sources files. It has an instance of EditHistory corresponding to the subject memory, which records the active (current) editions for the classes, method, modules, and authors in the subject memory. It also keeps the subject memory's id and the last Edit made to the subject memory. Every time the subject memory adds, changes, or removes a class definition, method, author, comment, tag, or module, or makes a checkpoint (i.e., makes an edit), it adds the appropriate editions to the history memory via remote messages. The history memory snapshots itself after every edit, so as to provide crash recovery support. The subject memory keeps a remote reference to the history memory's instance of EditHistory as a class variable of the local EditHistory class, and interacts with it using utility messages sent to the local EditHistory class. The history memory also keeps that EditHistory instance as a class variable of its local EditHistory class, but as a local reference. An edition typically elides some of its references when it is transferred out of a history memory. For example, a transferred edition will usually omit the references to its next and previous editions. The requesting subject memory can calculate the ID of those editions and obtain them with a separate request, if necessary. A subject memory may elect to keep its EditHistory instance as a local object, such as in a situation where one wants some limited immutable history for debugging purposes, and no crash recovery support. Whether in this scenario or in normal development the same EditHistory utility messages suffice, since no special code need be written to support remote objects. If no edits will be made during deployment, and no history retrieval is required, one may simply jettison the history memory. One may always reconnect the subject and history memories at a later time and continue development. The subject memory has tools for browsing and activating the editions, wherever they are located. This means that no special tools are needed to browse the artifacts of multiple subject systems; one uses the same tools as for browsing the artifacts of the local subject memory. Each subject memory may connect to multiple history memories concurrently (if allowed). For that matter, the history memories of multiple systems may connect to each other directly, to aggregate editions from multiple people, for example. class and method IDs Each class in the subject memory has a universally-unique identifier[3], or UUID. The classes in the minimal subject memory are assigned UUIDs before the initial release, and all subsequent classes are assigned UUIDs when created. Rather than use the single word "class" to refer to either a metaclass or to its sole instance, Spoon introduces the term "protoclass". For example, (Array class) is a metaclass, and its sole instance, Array, is a protoclass. Each metaclass and protoclass has its own UUID, called a "base ID". This is supported by a new instance variable in ClassDescription. Each version of each class is identified by a ClassID, a byte array with segments for the class's baseID, author UUID, and a sixteen-bit version. This means we can uniquely identify, for each author, 65,535 versions of each class in the system. Since we identify authors by UUID, the number of possible authors is very large. Each version of each method is identified by a MethodID, a byte array which contains a ClassID and segments for the method's selector, author UUID, and a sixteen-bit version. This means we can uniquely identify, for each author, 65,535 versions of each method in each version of each class in the system. method editions and method literal markers Each MethodEdition holds a reference to the corresponding ClassEdition, the method source code, and the information needed to reconstruct the corresponding CompiledMethod directly, without need of the compiler (the method header, initial and final program-counter values, method literal markers, and instructions). If one will never use the history memory to install methods in a subject memory that lacks a compiler, one could drop the compiled method information to save space. Method literal markers are used to transmit a compiled method's literal frame values between object memories. There are method literal marker classes to support references to classes, class variables, other pool variables, and literal objects, and to support methods which perform class-side super-sends. Each method literal marker instance knows how to serialize itself as part of Spoon's remote messaging system. In particular, when a method literal that refers to a class transmits itself, it transmits the ClassID of that class, not the name of the class. This gets at the namesake concept of Naiad, "Name And Identity Are Distinct". When referring to a class, we never need to use its name. Each version of each class is an object with a distinct identity. By using ClassIDs to refer to each of them, we can avoid using class names at all when storing history or distributing code. This means that name of each class can be anything, as far as the system is concerned. With every class name unconstrained, there is no need for "namespaces" to distinguish between classes which happen to have same name at some point in time. Each class effectively has its own namespace, since it is uniquely identifiable regardless of its name. Developer tools armed with this information can resolve ambiguity for humans browsing and changing the system. If a developer writes a method which uses a name shared by multiple classes, the system can present more information about each of those classes (such as the author, time of creation, version, and module association), so that the developer can choose the intended one. When browsing such a method, the system can distinguish the aliased class name visually, indicating that there is disambiguating information available. class editions and shared variables Each ClassEdition holds the editions for all the method versions currently active in the corresponding class in the subject memory. Since every edition keeps a reference to its previous and next editions, one can trace the history of any method by starting at the active edition. Removed methods are represented by method editions which have the same MethodID as a normal previous method edition, but with the rest of the fields set to nil. Each ClassEdition also holds the information needed to reconstruct the corresponding class directly, without need of the class builder. For all classes, this includes the format, instance variable names, and superclass ID. For protoclasses, it also includes the class pool keys, class name, and received pool IDs. In Spoon, every shared variable pool is the responsibility of some class in the system. There is no global variables pool ("system dictionary"). Each class that defines a pool is said to "publish" that pool; classes which use that pool "receive" it. Spoon adds an instance variable to Class to map published pools to their names. Each ReceivedPoolID that a protoclass edition uses is a byte array which contains a class ID and a published pool name. checkpoints and modules A Checkpoint edition is simply a named marker of a particular point in time. A developer may use checkpoints to indicate various interesting states of development, and use the tools to regress or replay edits made before or after that time. The largest unit of work is represented by module editions. They are named collections of method IDs, indicating the specific versions of methods which comprise a module, along with sets of child, parent, prerequisite, and postrequisite module editions. When a module edition is transferred out of a history memory, those edition references are transmitted as ModuleIDs. Each module edition also has an "antimodule", a module edition calculated at installation time by a receiving system which, if applied, would undo the changes made by installing the original module. Finally, each module edition has a URI by which someone at a remote site may install the module. That URI represents a command to a Spoon system running on a requestor's local machine; it refers to a standard port on localhost. Its path is a text-encoded action, containing an instruction (in this case "install a module"), the hostname and port of a Spoon system providing the module, and the module's ID. The receiving system uses this information to request the module from a providing history memory, which then transmits editions as necessary. Exactly which editions are transmitted depends on the state of the receiving system; this is a two-way conversation between the providing and receiving systems. This is often more time and space efficient than simply providing all of a module's code, which is what happens with traditional static representations like change sets. The URIs may be cited on ordinary webpages, which are indexed by search engines like Google. A person in search of a module for a particular purpose can search for it with a web browser, using those search engines. Having found a module's URI, the person can click on it, establishing a connection to an embedded webserver in their local Spoon system, which carries out the URI's command. This mechanism for code distribution avoids storing code in static files. It's a deparature from Smalltalk's traditional "fileout" mechanism. The encoded URIs can serve other functions as well, such as listing a system's installed modules, removing an installed module, making a snapshot, and quitting the system. In this way one can use a web browser to interact with a Spoon system for several basic tasks; this is especially useful when the system is headless (e.g., in its initial minimal state). comments and tags Editions for authors, classes, methods, checkpoints, edits, and modules each have their own comment and tag editions. This means each one of those artifacts has a comment and tags, and the changes in both are recorded over time. Comments are as we've already been using them: they're explanatory prose about the artifacts. Tags may be familiar to you from the web; they are short semantic markers used for grouping similar artifacts. I intend for tags to replace class and method categories. Nominally, we've been using class and method categories to establish semantic hierarchies, but the hierarchies have turned out to be quite shallow. Although we can form hierarchies with tags as well, I think we would do better to apply the sorts of algorithms that search engines use, and not concern ourselves with memorizing an artifact's semantic markers. The computational cost this incurs for the tools might have been high in the early days of Smalltalk, but it is quite modest now. Thanks for reading! Please let me know of any questions or other feedback, and feel free to discuss this on the Spoon and Squeak-dev mailing lists. -C [1] http://netjam.org/spoon/naiad [2] http://netjam.org/spoon [3] http://en.wikipedia.org/wiki/Universally_Unique_Identifier -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

6 7

Linux and ttyUSB0
by Jon Hylands 13 Jan '09

13 Jan '09

Hi everyone, On my current robotics project, I'm using a gumstix verdex to talk over a USB to serial converter chip (FT232) to a serial bus. My brother Dave made up a new kernel driver for the gumstix, and when I plug in the chip it registers itself as ttyUSB0. For work I've done previously on Squeak on the gumstix, I've used standard serial ports, which map to ttyS0, ttyS1, ttyS2, etc, which correspond to port 0, 1, and 2 when I open the Serial Port in Squeak. However, I have no idea which port number ttyUSB0 corresponds to... Anyone got any idea? Thanks, Jon -------------------------------------------------------------- Jon Hylands Jon(a)huv.com http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog

11 24

[Sq2.x] primitive 128 #elementsExchangeIdentityWith: fails
by Klaus D. Witzel 31 Dec '08

31 Dec '08

Hi, I'm backporting code to Squeak2.x and an ivocation of #elementsExchangeIdentityWith: which works fine with some 117k elements, fails under the Squeak2.x VM :( Searched the list archive to no avail. Was there something in the past, a limit on the # of elements? What directions can there be towards a solution, TIA. /Klaus -- "If at first, the idea is not absurd, then there is no hope for it". Albert Einstein

2 2

Squeak, Etoys, Robots and Wiimote
by Ricardo Moran 31 Dec '08

31 Dec '08

Hi, for the past several months we (http://tecnodacta.com.ar/gira/?page_id=9) have been working on making Squeak and Etoys a suitable platform for teaching robotics. We have made some progress and now we have few robotic kits that can be controlled with Etoys. These packages work reasonably well, but they still contain some bugs. SqueakNxt: SqueakNxt allows the user to control Lego Nxt robots ( http://mindstorms.lego.com/) over a Bluetooth serial port. It has an etoy interface and supports the servo motors and also the four basic types of sensors (light, touch, ultrasonic and sound). Currently we only have support for communication with direct commands but we are starting to work on a translator from a subset of smalltalk to NBC ( http://bricxcc.sourceforge.net/nbc/). This will allow to execute Smalltalk programs on the NXT. You can get SqueakNxt from here: (http://www.squeaksource.com/SqueakNxt.html ). To improve the performance we made a plugin that is available here: ( https://sourceforge.net/projects/squeaknxtplugin/). We have only tested SqueakNxt on Windows but if the SerialPort class works I believe it may work on Linux as well. I-Sobot: I-Sobot is the world's smallest humanoid robot in production ( http://www.isobotrobot.com/eng/). This package allows the user to control the I-Sobot with Etoys using a serial Lego IR Tower. You can download it from here: "http://www.squeaksource.com/ISobot.html". You also need the "sapien.dll" file. You can get it from here: " http://www.robotika.sk/mains.php?page=/projects/robsapien/". RoboSapien: RoboSapien is a toy-like robot designed by Mark Tilden ( http://www.wowwee.com/en/products/toys/robots/robotics/robosapiens:robosapi…). This package allows the user to control the RoboSapien v2 with Etoys using a serial Lego IR Tower. You can download it from here: "http://www.squeaksource.com/Sapien.html". You also need the "sapien.dll" file. You can get it from here: " http://www.robotika.sk/mains.php?page=/projects/robsapien/". RobotSoccer: This project allows the user to develop robot soccer teams capable to compete in the Fira Simurosot game. Currently it supports only virtual robots, but making it work with real robots may be trivial. This project is a bit more complex than the abovementioned because it requires the user to program in Smalltalk. Robot Soccer is a complex discipline so we believe Etoys is not good enough to develop highly functional robot soccer teams. It is available here: "http://www.squeaksource.com/RobotSoccer.html". You are also going to need the RobotSoccer simulator ( http://www.fira.net/soccer/simurosot/R_Soccer_v15a_030204.exe) and the proxy (http://tecnodacta.com.ar/gira/wp-content/uploads/2008/11/proxy.rar). The proxy is a team developed in c++ that uses sockets to interact with any software platform, i.e. Squeak. As the simulator only allows teams developed in Lingo or C++, we need the proxy to link the simulator with Squeak. We have also a tutorial but it's written in Spanish, in case you are interested here is the link: " http://tecnodacta.com.ar/gira/wp-content/uploads/2008/11/tutorial-de-futbol… ". SqueakWiimote: This project is simply a FFI interface to the wiiuse library ( http://www.wiiuse.net/). It allows to interact with several Nintendo Wii remotes using Squeak and/or Etoys. Although this project doesn't have anything to do with robots, controlling the robots with the wiimote becomes easy using Etoys. And it's fun! You can download it from here: " http://www.squeaksource.com/SqueakWiimote.html". You are also going to need the SqueakWiimote plugin ( https://sourceforge.net/projects/squeakwiimotepl/) and the wiiuse library ( http://www.wiiuse.net/).

4 3

[ANN] Soup 0.1
by Zulq Alam 30 Dec '08

30 Dec '08

Soup is a port of Beautiful Soup [1]. If you're not familiar with Beautiful Soup, it is a tolerant HTML/XML parser written in Python and is extremely useful when you need to scrape data from a web page. soup := Soup fromUrl: 'http://www.google.co.uk/search?q=squeak'. results := soup findAllTags: [:e | e name = 'h3' and: [(e attributeAt: 'class') = 'r']]. links := results collect: [:e | e text -> e a href]. Squeak Smalltalk -> http://www.squeak.org/ Squeak Smalltalk: Download -> http://www.squeak.org/Download/ Squeak - Wikipedia, the free encyclopedia -> http://en.wikipedia.org/wiki/Squeak etc... The main differences in API are: - find*Tag(s) for tags - find*String(s) for strings, CData, declarations, processing instructions - the use of blocks for complex queries For more usage information browse the searching tags and searching strings protocols on SoupElement subclasses. Also look at the tests in SoupElementTest, SoupTagTest and SoupParserTest. I will write/port proper documentation later. There are still many things to do: - No attempt is made to deal with different character sets and encodings. This is a major feature of Beautiful Soup which I have so far ignored. - The parser will not convert entity or char refs. Although this is the default behavior for Beautiful Soup on HTML it is still an important feature. - The parser will not accept options such as whether to convert entities, which entities to convert, what to parse, etc. - The parser will only do HTML. Unlike Beautiful Soup there are no configurations for other XML flavors yet. The project is globally writable. I look forward to your feedback and contributions. Thanks, Zulq. [1] http://www.crummy.com/software/BeautifulSoup/ [2] http://www.squeaksource.com/Soup.html

2 2

Additional Text Converters
by Zulq Alam 30 Dec '08

30 Dec '08

While adding multiple character encoding support to Soup, I needed a windows-1252/cp-1252 text converter so I wrote CP1252TextConverter (attached). Seems to work OK, though I've not tested it much. It seems like I'm reinventing the wheel. Is there a package with additional text converters available? If not, is a Mantis enhancement against the Multilingual project the best way to submit this? Thanks, Zulq. 'From Squeak3.10.2 of ''5 June 2008'' [latest update: #7179] on 30 December 2008 at 3:33:49 am'! TextConverter subclass: #CP1252TextConverter instanceVariableNames: '' classVariableNames: 'FromTable ToTable' poolDictionaries: '' category: 'Multilingual-TextConversion'! !CP1252TextConverter methodsFor: 'as yet unclassified' stamp: 'za 12/30/2008 02:40'! fromSqueak: aCharacter ^ FromTable at: aCharacter charCode ifAbsent: [aCharacter asciiValue]! ! !CP1252TextConverter methodsFor: 'as yet unclassified' stamp: 'za 12/30/2008 02:41'! nextFromStream: aStream | character | aStream isBinary ifTrue: [^ aStream basicNext]. character := aStream basicNext. character ifNil: [^ nil]. ^ self toSqueak: character. ! ! !CP1252TextConverter methodsFor: 'as yet unclassified' stamp: 'za 12/30/2008 02:42'! nextPut: aCharacter toStream: aStream aStream isBinary ifTrue: [^ aCharacter storeBinaryOn: aStream]. aCharacter charCode < 128 ifTrue: [aStream basicNextPut: aCharacter] ifFalse: [aStream basicNextPut: ((Character value: (self fromSqueak: aCharacter) charCode))]. ! ! !CP1252TextConverter methodsFor: 'as yet unclassified' stamp: 'za 12/30/2008 03:23'! toSqueak: aCharacter | value | value := aCharacter charCode. (value >= 128 and: [value <= 159]) ifTrue: [^ ToTable at: aCharacter charCode]. ^ aCharacter! ! "-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "! CP1252TextConverter class instanceVariableNames: ''! !CP1252TextConverter class methodsFor: 'as yet unclassified' stamp: 'za 12/30/2008 02:34'! encodingNames ^ #('windows-1252' 'cp-1252') copy ! ! !CP1252TextConverter class methodsFor: 'as yet unclassified' stamp: 'za 12/30/2008 03:01'! initialize ToTable := Dictionary new. ToTable at: 16r80 put: 16r20AC. "16r81 is unused " ToTable at: 16r82 put: 16r201A. ToTable at: 16r83 put: 16r0192. ToTable at: 16r84 put: 16r201E. ToTable at: 16r85 put: 16r2026. ToTable at: 16r86 put: 16r2020. ToTable at: 16r87 put: 16r2021. ToTable at: 16r88 put: 16r02C6. ToTable at: 16r89 put: 16r2030. ToTable at: 16r8A put: 16r0160. ToTable at: 16r8B put: 16r2039. ToTable at: 16r8C put: 16r0152. "16r8D is unused " ToTable at: 16r8E put: 16r017D. "16r8F is unused " "16r90 is unused " ToTable at: 16r91 put: 16r2018. ToTable at: 16r92 put: 16r2019. ToTable at: 16r93 put: 16r201C. ToTable at: 16r94 put: 16r201D. ToTable at: 16r95 put: 16r2022. ToTable at: 16r96 put: 16r2013. ToTable at: 16r97 put: 16r2014. ToTable at: 16r98 put: 16r02DC. ToTable at: 16r99 put: 16r2122. ToTable at: 16r9A put: 16r0161. ToTable at: 16r9B put: 16r203A. ToTable at: 16r9C put: 16r0153. "16r9D is unused " ToTable at: 16r9E put: 16r017E. ToTable at: 16r9F put: 16r0178. FromTable := Dictionary new. ToTable keysAndValuesDo: [ :key :value | FromTable at: value put: key ]! ! CP1252TextConverter initialize!

1 0

re: the Teams page (was "Producing alpha images")
by Craig Latta 30 Dec '08

30 Dec '08

Hi-- Andreas writes: > 3.11 has lost *all* visibility to me. I didn't know whether it had > even started because there was nothing on the server, there were no > announcements on this list, so how would people know? Göran responds: > IMHO this has more to do with our current board and its lack of... > communication. It's been quite a while since you've said anything to me on the #squeak channel on IRC, and I'm there most days. Given your current comments, this seems odd to me. While I can't always read all of squeak-dev every day, I do watch the meetings notes threads for responses. I haven't seen any for several cycles. I encourage everyone to let loose there. :) I also look forward to when we have a tenable way for people to send meeting agenda item suggestions to us. > Sure, I just skimmed meeting notes posted... Indeed, the meeting notes are the primary way we communicate with the community. They exist because, currently, I seem to be the only one who can spare the time to write them. Even sparing that time is nontrivial, so if someone would like to volunteer to make them more prominent, please contact me. I encourage anyone who chooses to spend significant time complaining to consider spending at least some of that time being on the leadership team instead. > ...and AFAICT there was a motion back in july: > > "Motion: Spoon will be basis of a R4 and 3.x will continue as planned > in 3.11 proposal as long as people want to maintain it. (Passed > unanimously) " > > ...but I can't say that the community is very AWARE of this and what > it means. So either the team is to "blame" for not speaking up or the > board is to blame for not showing the official support. The 3.11 team has the full support of the leadership team. The leadership team's understanding is that the 3.11 team (like all teams) would take responsibility for their task and its visibility. The primary task of the leadership team is to delegate. Again, those who prefer a different mandate for the leadership team should run for election. > Let me also YET AGAIN point to the team table on squeak.org: > > http://www.squeak.org/Community/Teams/ > > ... > > It seems I have pointed this out a THOUSAND times and nothing is > happening. The last time you said nothing was happening, I sat with you live on IRC and edited that table until you said you were satisfied with it. Apparently you misspoke, or I misunderstood you to be satisfied. Regardless, something did happen, and it is false to say that nothing happened. A few minutes ago I tried to login to edit that page, and the credentials I used before didn't work; I've asked Janko for new ones. If you are willing to point something out a thousand times, perhaps you might be willing to point it out nine hundred and ninety-nine times and then volunteer to do it yourself. > If the board totally ignores this table then for god sake - > delete it. Göran, you know full well that I am the person responsible for that table. Why you choose to get upset, let months go by while being upset, and then post heated tirades here rather than contact me directly about it at some point during those months is quite beyond me. thanks, -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

4 8

leadership team meeting notes for 2008-12-17
by Craig Latta 30 Dec '08

30 Dec '08

Hi-- The Squeak leadership team meets on first and third Wednesdays. Please contact me, directly or in this thread, with questions about the team or any of its meetings. - Attending on 2008-12-17 were Bert, Craig, Edgar, Giovanni, and Yoshiki. Absent were Igor and Randal. - Craig spoke with Rita Freudenberg from Squeak e. V., the German Squeak Association, about reimbursing them for the squeak.org web hosting costs they have paid. Rita is looking into how to accept money via PayPal. - Craig got credentials for editing the Squeak website from Janko, and updated the Teams page. Janko says he's working on a captcha system for the community to use for sending mail to the leadership team. thanks, -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)]

1 0