Squeak-dev February 2005

squeak-dev@lists.squeakfoundation.org

191 participants
430 discussions

Start a nNew thread

Is it possible to put a sar into a sar for delivery purpose?
by stéphane ducasse 01 Feb '05

01 Feb '05

1 0

RE: Views on Map
by Frank Shearar 01 Feb '05

01 Feb '05

Blake <blake(a)kingdomrpg.com> wrote: > I've been playing with the playfield (appropriately enough) > and would like > to go to the next level, as it were: I want a view that > scrolls around a > larger playfield than is seen at anyone time. While I think I > could do > this with the 3D graphics, I'd prefer to keep things 2D for > now. (I guess > I could sorta do that with a top-down view on a 3D field, > too, but I'm > really trying to avoid having to get into the 3D stuff for now.) > > Thoughts? Perhaps a ScrollPane is in order? This is what I use for my ImageMapEditor. Conveniently enough I recently submitted a changeset adding #asScrollPane to Morph - Morph currently has #asTwoWayScrollPane, and TwoWayScrollPane's actually deprecated. Review the changeset, and help get it into the image :) frank ******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent RNID policy. If you are not the intended recipient you are advised that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please notify the RNID Helpdesk by telephone on: +44 (0) 207 296 8282. The Royal National Institute for Deaf People Registered Office 19*23 Featherstone Street London EC1Y 8SL No. 454169 (England) Registered Charity No. 207720 ********************************************************************

1 0

Why I asked (was: How might I set the cursorpoint? )
by Peace Jerome 01 Feb '05

01 Feb '05

Tim wrote: >Prim 91 is actually test display depth... we don't do setting of the cursor position. That's interesting. I�m just trying to learn the stuff by reading the code. What's there was: primCursorLocPut: aPoint "If the primitive fails, try again with a rounded point." <primitive: 91> ^ self primCursorLocPutAgain: aPoint rounded >It'sa pretty bad bit of UI generally to take the users >'attention' and drag it somewhere else by force. > I pretty much agree with you. To see what I was trying to do. Get a rectangle ask for the bitmap fill style and then ask (via red menu) to reset the origin (or orientation). The cursor is where the menu item was selected which is usually nowhere near the original origin. So the UI is that the picture changes dramatically to jump the origin to where the cursor now is. It is not to bad for just the origin but the orientation stuff is rather jarring. So I thought that something that leaves them where they are until you move the cursor would be more pleasant. I�ve been experimenting with different things that might do that and following up my curiosity.\ I�ve found many a piece of code in squeak that indicated someone intended for a particular function to work. I�ve found a curiosity about why it doesn�t and what would make it do so a good learning probe. And while I�m on the subject of curiosity who are the we of > ... we don't do setting of the cursor position. Who makes the communities standards? What are they? And how do newbies find out about them? Thanks for starting a lively conversation on this. With curiosity, --Jerome Peace __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

5 7

OT] post-structuralist object oriented system
by PA 01 Feb '05

01 Feb '05

For your entertainment: "Lua’s Story of O" http://alt.textdrive.com/lua/19/lua-story-of-o Cheers -- PA, Onnay Equitursay http://alt.textdrive.com/

1 0

Harvesting Party Saturday February 5th 12:00 GMT
by Ken Causey 01 Feb '05

01 Feb '05

Just a reminder that the next Harvesting Party will take place between 12:00 (Noon) and 16:00 (4 PM) GMT Saturday February 5th, 2005. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html Information about the Harvesting Party idea can be found at http://people.squeakfoundation.org/article/29.html If you have the time please attend and work toward the future of Squeak. The next seven parties are scheduled for 16:00 (04:00 PM) GMT Wednesday February 09, 2005 20:00 (08:00 PM) GMT Sunday February 13, 2005 00:00 (12:00 AM) GMT Friday February 18, 2005 04:00 (04:00 AM) GMT Tuesday February 22, 2005 08:00 (08:00 AM) GMT Saturday February 26, 2005 12:00 (12:00 PM) GMT Wednesday March 02, 2005 16:00 (04:00 PM) GMT Sunday March 06, 2005

1 0

Squeak People posting summary
by cg＠cdegroot.com 01 Feb '05

01 Feb '05

Below are the most recent 5 articles that were posted on Squeak People (http://people.squeakfoundation.org/). Apart from the articles, you will find people's diary entries there, and an overview of the Squeak community: who is doing what, people's "standing", etcetera. If you don't have an account, please join - we're interested in getting to know you better! This message is posted automatically every week by a dirty shell script. _________________________________________________________________ Date: 2005-01-27 15:49:25 Author: gokr Title: Taming the translation beast! Now - I have just started figuring out how to translate my [1]Homepage Builder application to english and of course ended up digging into the translation stuff. This is a short (well, kinda) report on what I found, how to use what we have, and what I think we need to fix. _________________________________________________________________ Date: 2005-01-10 04:23:15 Author: elvislives Title: squeak logo lookalike Hi, _________________________________________________________________ Date: 2004-12-30 16:37:02 Author: jj Title: Boosting Squeak: RockSolid images I have read the "rant" and "unrant" subject with a mix of uneasiness (embarrassment) and fear. The "Rant" thread began on the 15th of december 2004, and produced a lot of discussion. I will not summarize the thread, because a lot of people read it. Instead, I will go forward and try to find a pragmatic and constructive of helping the community (and yes, I am also very bold and handosome :) << ironic comment). _________________________________________________________________ Date: 2004-12-20 00:34:35 Author: cdegroot Title: Terminus is up'n'running Terminus, the little system I cobbled up to export Squeak People's account and web-of-trust information, is up and running. The first app is a [2]Wiki which uses Terminus to decide whether certain actions are possible. _________________________________________________________________ Date: 2004-09-25 15:46:37 Author: avi Title: Unstable Squeak I'd like to announce Unstable Squeak: an experimental fast-moving, community-based developer-oriented distribution of Squeak. Unstable Squeak leverages Squeak Source, Squeak People, and Monticello to try to present an alternative model for incoporating fixes and enhancements from the community with a minimum of process. References 1. http://www.bluefish.se/english/hemsidebyggaren.html 2. file://localhost/seaside/wiki --- (end of posting. Thank you for your patience)

2 1

Concerns regarding Squeak design quality
by Peace Jerome 01 Feb '05

01 Feb '05

Reading this dialog feels like getting the blindmen�s view of an elephant. Micheal I�ve been using balloon stuff in the form of bitmapfill and have not run into any problems not easily remedied. You found some badly maintained classes. If they are the ones I think they must be they are the only ones using the flawed MatrixTransformationMorph. See my note further down. Squeak is a strange animal. Maybe other smalltalks are too, I�ve only played with squeak and I�m in most departments still a newbie. My take is that it is a living language. It grows as its users need it to grow and the words bump into themselves. There are no pretensions of Squeak being a production system. For reasons of tradition and politeness vestigial pieces remain around. Dead language that doesn�t announce that its dead. Like the parts of our DNA that don�t do anything useful for us. My curiosity is what is it you are trying to implement? Can you tell a paragraph story of what your thing would do after you implemented it? What made you examine squeak as the implementation smalltalk? You will have to judge what is best to implement your project in. If its well defined you could choose from a lot of well defined languages. If you are still playing with what it might be. If you are looking for useful ideas. If you are willing to learn from your mistakes.Well squeaks not production but its a pretty good scratch pad. > >I think there is a big difference in perspective between how you see >the world and myself. > >1) If a piece of code does what it advertises to do, great. If it >advertises an API and only implements 2/3 of that API, that is a >problem. >2) Yes you can produce a working system by tip toeing around the >unfinished/broken/inelegant parts of any system. If there was >documentation or even comments that would be much easier. >3) Citing applications that serve the Squeak community as evidence of >Squeak's production quality is not sufficient if your target is >end-users that do not care about Squeak and only care about getting >their work done. There may be uses of swiki that fit this example, but >I suspect that swiki uses a small percentage of the code in the full >image. > >Your last line is only true if what I want to do is what others have >wanted Squeak to do, and have invested the effort in fixing/finishing. >I would like to use Squeak, but that is difficult given the breakages >of pretty basic functions I have been encountering. Balloon is >advertised as a graphics model supporting scaling and transformation, >but in fact only bezier curves support these functions. Ovals and text >do not support these features. The 3.8 release is advertised as >supporting multi-lingual features, but the code is completely >uncommented, and I was unable to find external documentation, or get a >simple answer from the list on the level of support. > >I compare this with other open source projects that have regular build >schedules, code documentation and comments, and bug tracking that is >clearly available from their website and that provides status >notification on resolution to the submitter. There are a lot of >assumptions built into the Squeak community about how to run a project >that I find difficult to bet my living on. I much prefer Smalltalk and >the ability to persist (in the image) both the data and the execution >artifacts. Once I really give up on using Squeak I will stop bothering >you with my "complaining", but given the number of threads on this type >of subject, I very much doubt that I am alone in this perception. > >Michael > > >On Jan 30, 2005, at 11:08 AM, Lex Spoon wrote: > >> Michael Latta <lattam at mac.com> wrote: >>> What I guess I am questioning is whether the image has enough >>> integrity >>> / quality of design to use in a production project. If there are a >>> lot >>> of unfinished stuff in the image, then our maintenance effort grows >>> with the amount of the existing code we try to use. >> >> The crushing argument that Squeak has enough XYZ to use for production >> projects, is that people are successfully using Squeak in production >> projects. Given this reality, there must be *some* hole in any >> argument >> along the lines of "Squeak does XYZ and thus can't be used in >> production". It's being used in production. Notable examples are >> SqueakSource and Swiki. Swiki alone has 256,000 google hits. >> >> So how can this be, given your concerns about code quality? My answer: >> because this code you are grousing about, actually works. Actual it doesn�t. Michael wasn�t very specific but the two classes he talks about are badly under maintained. They are the ones that use MatrixTransformationMarph which probably never worked correctly and certainly not correctly with the rest of squeak. (see mantis #0000857). >>You have been >> complaining about Balloon and getting it wrong. Now you are saying >> maybe Balloon works, but its design is bad. Consider this: serious >> engineers don't rewrite everything from scratch whenever they change a >> design. Serious engineers have to allocate their resources carefully, >> and often it is a flat out mistake to spend time prettying up the code. >> If Morphic text processing reuses some of the text processing code from >> MVC, then so what? Isn't that good engineering? >> >> If you want perfect pristine code, then there are plenty of toy >> languages around you could play with, where people rewrite everything >> from scratch all the time. If you want something that is useful and >> works, Squeak will be here waiting for you. >> >> So there. >> >> Lex >> > __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 0

let's build package universes
by Lex Spoon 01 Feb '05

01 Feb '05

Let's build package universes as part of our main release cycle. It's easy to do, now that the package universes toolset is all together, and it provides an important artifact both for newbies, and for people who want to build something *in* Squeak. It also gives us a mechanism for building really stable Squeak's, should enough people ever be interested in trying to make that happen. Specifically, I am proposing: 1. Whenever we make a release, we make the standard basic and full images be based on universes, just like in this 3.7u1 image I announced in the previous email. These are the images a user should download by default. 2. We should have a standard development universe at all times. Developers who want their package to be in the standard public set of packages, should post entries to this universe just like they post to SqueakMap right now. 2b. If we want to get fancy, we can have a "freeze" period near the end of each release, where the only updates allowed to the dev universe are for bug fixes. 3. It is considered a bug for entries in the current development universe to not load properly. If such bugs persist until a release is about to happen, the offending package is removed from the universe. These are easy things to do. I ought to have enough time to produce the universized images, so don't worry about that. The rest of the Squeak developers simply need to post their packages to the current development universe. That's easy: install universes from SqueakMap, open a Universes Editor, create an account, and post your package. The instructions are on the Swiki page (linked below). Package universes address a big problem we are having regarding version skew. People who simply build on top of Squeak, want to have a stable basis to work from. Further, I'm itching like heck from hearing people whine about version skew, and from running into it in practice. Debian has 8000+ packages and 900+ developers, and they routinely produce stable releases where all the most critical bugs have been fixed, all the packages are loadable, and (at worst) the truly messed up packages have been removed as standard install options. Package universes let us follow something like their process, and accomplish the same thing. Along these lines, I believe they address Peter's concerns about every package changing the base system and thus being incompatible with each other. With a universes mindset, it is considered a bug for two packages to interfere in this way, and if the bug doesn't get fixed, eventually one of the two packages must be removed from the universe. Package universes also address our small problem of package dependencies. It's kinda nice to just click on Chuck and say "install" and it happens. With our current setup, you have to install several pre-reqs before installing Chuck will work, and you have to carefully read the package descriptions to see. For the record, I don't care whether we use my universes toolset to accomplish all this. In fact, I started this discussion half a year ago by saying I think that SqueakMap should have multiple maps--one map per package universe. If an alternative toolset comes along that does the same thing, I am happy to pass the baton and see that toolset used instead. I don't even really have time to work much on this, and am simply doing it because I think it's extremely important. In the meantime, of course, let's use the tools we have. LINKS "Package Universes" http://minnow.cc.gatech.edu/squeak/3785 "The Future of SM" thread which started all this: http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/080007.html http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/080190.html the original universes announcement: http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-July/080585.html -Lex

3 2

Mac 3.8.6b4 VM posted for testing
by John M McIntosh 01 Feb '05

01 Feb '05

I've posted a macintosh VM that includes the buffered display improvements, changes from Andreas to view certain GC events/features and my changes from last fall to collect GC statistics & alter the VM to bias for growth versus compaction. I've stuck them on my idisk http://homepage.mac.com/johnmci/FileSharing.html See the experimental directory and the squeakGarbage sub-directory. or see the following ftp directory for zip files. ftp://www.smalltalkconsulting.com/squeakGarbage/ ftp://www.smalltalkconsulting.com/ I have not build an os-9 version yet, and I will post a 3.8.6b5 VM in a day after some minor changes to statistical collection and any changes based on feedback I receive. Folks who are interested should review the VM for any performance improvements in the following areas. a) Applications that invoke lots of drawing should be faster b) By setting these two VM parms some application may see altered memory growth patterns (better) and faster transaction thruput. Repeatable results are welcome. Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. "Set growth limit before full GC to 16MB" Smalltalk setGCBiasToGrow: 1. Set bias to grow upto GCLimit, this can avoid a problem where we attempt to avoid growing but results in thousands of incremental GC events as we approach a knee in a curve of space used versus the growth/compaction decision. 3.8.6b4 has: Ensure VMMaker 3.8b2 - the VM code classes and tools for building a working vm for Squeak version > 3.8-6461. is incorporated. Add Andreas's GC improvement changes for * primitiveIsYoung: This answers the question whether an object currently lives in young or in old space. * primitiveIsRoot: Answers the question whether any given object is currently a root for young space. * primitiveRootTable: Answers a snapshot of the current root table. Useful to examine the roots table if the analysis requires complex other operations during which the root table might be modified itself. Note that since this primitive can cause GC there is a small chance that it will give an inaccurate answer. * primitiveRootTableAt: Answers a single element of the root table (by one-based index). This primitive can be used to quickly scan the root table for certain objects. * primitiveSetGCSemaphore: Indicates a semaphore (index) to be signaled whenever a garbage collection occurs. I can see at least two uses uses for the GC semaphore: running cleanup actions (for example after full GCs occured) and dynamic parameter tuning for the GC algorithm itself. Add John's changes for Smalltalk setGCBiasToGrowGCLimit: 16*1024*1024. "Set growth limit before full GC to 16MB" Smalltalk setGCBiasToGrow: 1. Set bias to grow upto GCLimit, this can avoid a problem where we attempt to avoid growing but results in thousands of incremental GC events as we approach a knee in a curve of space used versus the growth/compaction decision. 3.8.6b3 Add in logic for become: to fix issues with changes to become: logic. 3.8.6b2 sqMacWindow.c reduce number of lock/unlock pixel events and flush no more than 91 fps, with flush check every 1/50 or 1/60 and 1/5 of a second. this shaves another 50% off making drawing pixels 1.3% of the time originally taken. 3.8.6b1 sqMacWindow.c, sqUIEvents.c, changed logic to flush screen every 125 fps, this makes pixel level drawing complete in 2% of the time originally taken. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

1 0

REMINDER: Harvesting Party Tuesday February 1st 08:00 GMT
by Ken Causey 01 Feb '05

01 Feb '05

Just a reminder that the next Harvesting Party will take place between 08:00 (8 AM) and 12:00 (Noon) GMT Tuesday February 1st, 2005. As usual we will meet in #squeak on irc.freenode.net. More information about the #squeak IRC channel can be found at http://people.squeakfoundation.org/article/7.html Information about the Harvesting Party idea can be found at http://people.squeakfoundation.org/article/29.html If you have the time please attend and work toward the future of Squeak. The next seven parties are scheduled for 12:00 (12:00 PM) GMT Saturday February 05, 2005 16:00 (04:00 PM) GMT Wednesday February 09, 2005 20:00 (08:00 PM) GMT Sunday February 13, 2005 00:00 (12:00 AM) GMT Friday February 18, 2005 04:00 (04:00 AM) GMT Tuesday February 22, 2005 08:00 (08:00 AM) GMT Saturday February 26, 2005 12:00 (12:00 PM) GMT Wednesday March 02, 2005

3 2

Jump to page: