Squeak-dev March 2009

squeak-dev@lists.squeakfoundation.org

134 participants
173 discussions

[squeak-dev] [BUG]MethodReference(Object)>>doesNotUnderstand: #category:
by asselinraymond＠videotron.ca 23 Mar '09

23 Mar '09

When evaluating: Installer install:'LevelPlayingField-Monticello15'. in a 3.9.1 Squeak image the following debugger pop-up 23 March 2009 11:24:45 am VM: Mac OS - a SmalltalkImage Image: Squeak3.9.1 [latest update: #7075] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir /Users/ray1/Documents/PROGRAMMATION/APPLICATIONS-ESSAIS/ATELIER XPNew/XpWEB Trusted Dir /foobar/tooBar/forSqueak/bogus Untrusted Dir /Users/ray1/Library/Preferences/Squeak/Internet/My Squeak MethodReference(Object)>>doesNotUnderstand: #category: Receiver: a MethodReference SequenceableCollection >> mcLessThan:ifEqual: Arguments and temporary variables: aMessage: category: #'*monticello' Receiver's instance variables: classSymbol: #SequenceableCollection classIsMeta: false methodSymbol: #mcLessThan:ifEqual: stringVersion: 'SequenceableCollection mcLessThan:ifEqual:' [] in PackageInfoImpl(PackageInfo)>>methodsInClass:category:do: {[:selector | aBlock value: ((self referenceForMethod: selector ofClass: aC...]} Arguments and temporary variables: aClass: SequenceableCollection aCategory: #'*monticello' aBlock: [] in PackageInfoImpl(PackageInfo)>>classesDo:methodsDo:displayingProgr...etc. .. selector: #mcLessThan:ifEqual: Array(SequenceableCollection)>>do: Receiver: #(#mcLessThan:ifEqual:) Arguments and temporary variables: aBlock: [] in PackageInfoImpl(PackageInfo)>>methodsInClass:category:do: {[:sele...etc... index: 1 indexLimiT: 1 Receiver's instance variables: #(#mcLessThan:ifEqual:) PackageInfoImpl(PackageInfo)>>methodsInClass:category:do: Receiver: a PackageInfoImpl(Monticello.impl) Arguments and temporary variables: aClass: SequenceableCollection aCategory: #'*monticello' aBlock: [] in PackageInfoImpl(PackageInfo)>>classesDo:methodsDo:displayingProgr...etc. .. selector: #mcLessThan:ifEqual: Receiver's instance variables: packageName: 'Monticello.impl' methodCategoryPrefix: '*monticello' properties: an IdentityDictionary(#mc->a MCWorkingCopy 'Monticello.impl ()' ) --- The full stack --- MethodReference(Object)>>doesNotUnderstand: #category: [] in PackageInfoImpl(PackageInfo)>>methodsInClass:category:do: {[:selector | aBlock value: ((self referenceForMethod: selector ofClass: aC...]} Array(SequenceableCollection)>>do: PackageInfoImpl(PackageInfo)>>methodsInClass:category:do: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [] in PackageInfoImpl(PackageInfo)>>methodsInExcludedClass:do: {[:cat | self methodsInClass: aClass category: cat do: aBlock]} [] in PackageInfoImpl(PackageInfo)>>methodCategoriesInClass:coreDo:extensionDo :overrideDo: {[:cat | (self isYourClassExtension: cat) ifTrue: [extensionBlock value: ca...]} Array(SequenceableCollection)>>do: PackageInfoImpl(PackageInfo)>>methodCategoriesInClass:coreDo:extensionDo :overrideDo: PackageInfoImpl(PackageInfo)>>methodsInExcludedClass:do: [] in PackageInfoImpl(PackageInfo)>>classesDo:methodsDo: {[:class | self methodsInExcludedClass: class do: methodBlock]} PackageInfoImpl(PackageInfo)>>behaviorsNamed:do: [] in PackageInfoImpl(PackageInfo)>>includedClassesDo:excludedClassesDo: {[:name | self behaviorsNamed: name do: excludedBlock]} Array(SequenceableCollection)>>do: [] in PackageInfoImpl(PackageInfo)>>includedClassesDo:excludedClassesDo: {[:cat | (SystemOrganization listAtCategoryNamed: cat) do: [:name | self be...]} [] in PackageInfoImpl(PackageInfo)>>includedSystemCategoriesDo:excludedSystemC ategoriesDo: {[:ea | (self includesSystemCategory: ea) ifTrue: [includedBlock value: ea]...]} Array(SequenceableCollection)>>do: PackageInfoImpl(PackageInfo)>>includedSystemCategoriesDo:excludedSystemC ategoriesDo: PackageInfoImpl(PackageInfo)>>includedClassesDo:excludedClassesDo: PackageInfoImpl(PackageInfo)>>classesDo:methodsDo: PackageInfoImpl(PackageInfo)>>classesDo:methodsDo:displayingProgress: MCPackage>>snapshot MCPackageLoader1b>>updatePackage:withSnapshot: [] in MCVersionLoader>>loadWithNameLike: {[:ea | ea canOptimizeLoading ifTrue: [ea patch applyTo: loader] ifFalse:...]} OrderedCollection>>do: MCVersionLoader>>loadWithNameLike: MCVersionLoader>>load [] in InstallerMonticello>>basicInstall {[self mcThing load]} [] in BlockContext>>valueSupplyingAnswers: {[self value]} BlockContext>>on:do: BlockContext>>valueSupplyingAnswers: BlockContext>>valueSuppressingMessages:supplyingAnswers: InstallerMonticello(Installer)>>withAnswersDo: InstallerMonticello>>basicInstall ...etc...

2 1

Squeak Leadership Team Meeting Notes for March 19th, 2009
by Ken Causey 23 Mar '09

23 Mar '09

If you have any questions or concerns regarding this report you can either reply to me directly or within this thread on squeak-dev. This report will also be published to our team blog when it is ready and once that is done I will mention the link in reply to this thread. The Squeak Leadership Team met on Thursday March 19th. This was the first meeting of the newly elected team and incorporated both new and current members as well as retiring members. Present: Jecel Mattos de Assumpção Jr, Ken Causey, Bert Freudenberg, Craig Latta, Yoshiki Ohshima, Andreas Raab, Igor Stasenko Absent: Giovanni Corriga, Edgar J. De Cleene, Randal Schwartz The agenda for this meeting can be found at http://squeakboard.wordpress.com/2009/03/21/agenda-for-mar-19-2009/ At the beginning of the meeting we focused on transitioning duties from retiring members to continuing members and member jobs in general. Ken will take over the duties of Secretary and Overall Mailing List Administrator. Craig will continue as Treasurer. Andreas will take over from Yoshiki as team advisor to the Elections team. Randal will continue to communicate with the Software Freedom Conservancy with Craig's assistance. The topic of the name of this team came up again. It was noted that the word 'Board' is firmly established in the community's mind. A few suggestions were made and we chose 'Squeak Oversight Board'. Also we will list ourselves on the Team list http://www.squeak.org/Community/Teams/ to make it clear we are a Team like many others. Igor will be working with Janko Mivsek and the Webteam to make changes as appropriate on www.squeak.org. The issue of the status of the community teams came up but this was not on the original meeting agenda and is a large topic so it was tabled and to be discussed again in the future. Craig noted that this is a regular topic and should be added as a 'persistent' agenda item and discussion should be expected in nearly every meeting. We discussed the SFC, 4.0 relicensing, and the 3.11 release status but Randal has been the point man on these issues and was unable to attend so we lacked some information regarding current status, some of the other members had bits and pieces of information however. Discussion turned to how we can measure success and progress of projects. Jecel pointed out that it is relatively easy with the relicensing/4.0 project as you can state completion as: 'Compatible with Squeak 3.10 but with all methods not licensed under either MIT or Apache removed or replaced.' It was agreed that this was a very good measure but there is still some discussion going on with SFC regarding the identification of the license which covers a method. Also where do we draw the line on compatible if it turns out that large parts of the code need to be fixed? Should we consider releasing a possibly incomplete or broken 4.0 with the goal of releasing a 4.0.1 quickly with issues fixed? Projects need to have goals that can be reached in relatively short time periods. For now since discussions continue with SFC it was decided to aim for a completely compatible release but consider the possibility of something else later if necessary, in general aiming for a relatively quick release. There was then discussion of the 3.11 release and how one would measure progress and success with this project. It was generally agreed that this was less clear and that Andreas would talk to Randal, Matthew, and Keith and get back to us at the next meeting with more information to discuss this more clearly. How does this team lead? We discussed the job of this team overall. It was noted that in the past the team has tended to take more of an observation and arbitration role. After discussion we agreed that the team needs to take a more active and leading role in the community. Part of this will be adding more outreach and communication. We as a team need to become more visible. The idea of a blog was mentioned where we would all post entries and where we would organize things better than on a mailing list. Andreas volunteered to look into setting this up. For the immediate future, once the blog is available, we will continue to post to squeak-dev but if appropriate we should also post to the blog. This serves 2 goals: 1. We can organize things more affectively on a blog and have permanent pages that can be easy to find. 2. This serves the outreach goal by making our discussions and issues more visible to the greater community that does not follow squeak-dev regularly, if at all. Expect more information on our team blog soon. We then turned our attention to financial issues. It was noted that one of our bigger funding sources is the Google Summer of Code project where the project mentors have been donating their earnings to the community. For 2007 this was $2000 and for 2008 $2500, $500 per mentors. Unfortunately Google paired down the project somewhat this year and we were rejected as they want to focus on larger groups. Giovanni continues to hold the funds from 2007 and 2008 and Craig will be talking to him about that and to Tim and ESUG regarding the current badge sales. Currently the funds to which we have direct control originated from ESUG as donations. Or only unavoidable expense right now is the community server which is about $50 per month and the available funds will continue to cover that for the foreseeable future. We realized that we had spent over an hour and still had plenty to discuss so it was decided that we would schedule another meeting for the following Thursday, March 26th 2009. Remaining agenda items that need further discussion include: Mission statement for 2009 (aka: Where is Squeak headed), Financial needs for 2009, Community outreach (blog etc), Positioning towards other communities, Process improvements (BPPs, decision making etc), and we will of course be revisiting many of the other issues mentioned above. If you have anything you think we should discuss please let us know. Ken Causey

4 5

living in the stone age; change set migration tools anyone?
by Eliot Miranda 23 Mar '09

23 Mar '09

Hi All, I'm embarrased to say that part of my ork environment revolves around ChangeSets. While I very happily use Monticello I also have the Closure bootstrap strewn across a number of change sets, about 20 in all. Because the Closure bootstrap is complicated, with different variations for Squeak 3.9, Croquet etc, with different stages in self-modification of the compiler, etc, it can't be written as a set of Monticello packages. But for the second time I am about to hit my changes file limit and, because of Monticello overrides and my own method history, I do not want merely to condense changes and continue. Instead what I want to do is move my change sets to a more up-to-date image. At Qwaq Andreas builds weekly images whose end result includes the result of the Closure bootstrap. What I would like to do is serialize all my change sets, file-out all my changes (idelaly including history) and then in an up-to-date deserialise the change sets to preserve the structure, and selectively file-in those changes that are different to the up-o-date image (I haven't thought this last point through too carefully; presumably all the changes are in the up-to-date image, so what I really want to bring in somehow is the history). What I wondered was has anyone else gone throguh something similar and if so do they have any code that would help me, war stories that would change my mind, or alternatives (e.g. how to preserve Monticello overrides through a condense changes). AdvThanksance Eliot

4 3

Alien FFI
by Ang Beepeng 23 Mar '09

23 Mar '09

I'm trying to load Alien-core into my image, in Windows. It complaint about syntax error. Ccalloc: byteSize "<Integer> ^<Integer>" <primitive: 'primCalloc' error: Literal constant expected ->errorCode module: 'IA32ABI'> ^self primitiveFailed Similar error occur to many other methods. What should I do to correct it? Thanks. Ang Beepeng -- View this message in context: http://www.nabble.com/Alien-FFI-tp22635925p22635925.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

4 11

[Q] FFI for Windows; PASCAL(WINAPI) or C Calling convention?
by "S.J.Chun" 23 Mar '09

23 Mar '09

Hi, I'd like to create a DLL for windows platform(Tokyo Dystopia based search tool). Now I found that there's 2 kind of calling convention in Windows. What convention should I follow to create DLL so that it could be called from Squeak using FFI? Thanks in advance. PS) I'm using old plain FFI, not Alien thing. :-)

2 1

Maui 1.1r4
by Chris Muller 23 Mar '09

23 Mar '09

I have posted new version of Maui, available from SqueakMap: - Fixed the package load from SqueakMap! - Now using calculated package prerequisites so hopefully above problems won't happen anymore! - Moved new MauiFamily file-in functionality to this package. - #loaded view now starts with a #clear view instead of a #panel view. - Chris

1 0

Rewriting an Input/EventSensor code
by Igor Stasenko 22 Mar '09

22 Mar '09

Hello lists, I making a cross-post, because there are interest from both camps to make it done :) Michael published a changesets with new event sensor code for Pharo, which mainly focused on supporting multiple event consumers(frameworks). Recently , we discussed it with Andreas, and had an idea to integrate this with Announcement framework (and Announcement will become a core package). I very like this idea, but i think we should discuss the implementation details before starting it. Here is my vision , how things should look like: - role 1. Event source. VM, is an events source, in most cases it is the only source, but not always. I would like to be able to plug-in a different event source.. imagine a remote socket connection, or previously recorded events and then replayed. So, an event source should be a separate, abstract entity, where VM is one of the concrete kind of it. There is also, sometimes a need to inject a fabricated events into event queue, to simulate user input, or for producing a synthetic events. - role 2. Event listener/Event sensor (or InputSensor) is a mediator between event source and higher level framework (Morphic.. etc), its role is to listen events from event source and then dispatch it to concrete consumer(s), if any. - role 3. Events. Events should be a full featured objects, with good protocol. A high level framework should not peruse with raw data, as it currently does with raw event buffers which coming from VM. This means, that changes will affect the Morphic. Morphic having a classes for user input events (keyboard/mouse) and decifering raw VM events into own representation. I think we should move the 'decifering' part to EventSource (sub)classes, and make sure EventSensor (and its consumers) dealing with full featured event objects, leaving event consumers free to decide what to do with them. - role 4. Event consumers. Note, there can be multiple different consumers, not just one, as its currently Morphic. We should make sure, that integration with any other framework will be painless. - be ready for supporting multiple host windows. This part is quite simple to do in EventSensor.. but not so simple in Morphic. One thing would be is to refactor all code which uses the Sensor global directly, and replace it with appropriate thing(s). But this is out of scope of event handling framework, at initial stage , we could keep things compatible with old ways (1 Sensor, 1 Display, 1 Morphic World). I started prototyping a classes for events, where each event kind having own event subclass, and directly decoding the VM raw event buffer, so then any event consumer(s) don't have to poke raw events. But since there were a good idea to make use of Announcements for it, it may need some refactoring. Michael, Andreas, i'd like to hear your comments and remarks, as well as any others are wellcome. -- Best regards, Igor Stasenko AKA sig.

6 10

Is LLVM useful to Squeak?
by askoh 22 Mar '09

22 Mar '09

I noticed that Mono and Python are doing some work with LLVM. http://www.mono-project.com/StudentProjects#LLVM_Back-End http://codespeak.net/pypy/dist/pypy/doc/translation.html#the-llvm-back-end http://llvm.org/ What are they gaining from LLVM? Can Squeak benefit from LLVM? Thanks, Aik-Siong Koh -- View this message in context: http://www.nabble.com/Is-LLVM-useful-to-Squeak--tp22638664p22638664.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

4 3

loading SmaCC, Shout, Refactory Browser into Squeak 3.10.2
by Ralph Boland 21 Mar '09

21 Mar '09

I am looking into migrating my Squeak project from Squeak 3.8.1 to Squeak 3.10.2. However, when I try to download Shout or the Refactory Browser using the SqueakMap package loader I am told that the versions available are not compatible with version 3.10.2 of Squeak. The SmaCC (compiler) package doesn't seem to be available at all. For me SmaCC is a must have and Shout is much desired. The refactory Browser is nice to have. How do I download these packages into my image? Thanks, Ralph Boland Bye the way, my project is a package for experimenting with implementations of algorithms for constructing finite state machines from regular expressions (someday it will be generalized for experimenting with parsing algorithms). It is nowhere near ready for release but if anybody is curious and wants to play with it I could send you a copy if you are prepared to critique what I have done so far, especially the GUI. Be for warned, it is a large project, critiquing it would take some time.

4 3

SqNumberParser!
by Göran Krampe 21 Mar '09

21 Mar '09

Howdy folks! In working on Tirade I stumbled upon SqNumberParser and its history: http://bugs.squeak.org/view.php?id=3512 ...it was added to the image in 3.9 but not hooked into Scanner - Scanned still uses Number class>>readFrom:. Now... In Tirade I can use whichever - but using SqNumberParser makes it more correct, and quite faster - although "less portable" since I would depend on it. I will now make Tirade use SqNumberParser *if present* in the image, otherwise fall back on Number class>>readFrom:. This opens up some slight potential incompatibility issues, but whatever. Question: Is there anything stopping 3.9+ including Pharo to start using SqNumberParser from Scanner>>xDigit? And oh, the class name is not so good IMHO, why the Sq prefix? And yeah, class var not used in SqNumberParser: BelllerophonBase10 :) regards, Göran

4 5

← Newer
1
...
4
5
6
7
8
9
10
...
18
Older →

Jump to page: