Squeak-dev January 2005

squeak-dev@lists.squeakfoundation.org

134 participants
235 discussions

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

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

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

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

RE: Squeak is an unsuccessful open source project (was RE: Let us facereality)
by Peter Crowther 01 Feb '05

01 Feb '05

> From: [...] Lex Spoon > Peter, you have a good idea but you are looking at Squeak as the wrong > kind of project. It is not a single application that does one thing. > The individual applications built in Squeak *do* have a small team of > dedicated programmers: EToys, Croquet, Scratch, the Berne > group, Squat, L, etc. etc. True enough. And they all hack at the code that supports all the projects for their own benefit, with no regard for each other and little to no co-ordination. After all, this is a *personal* computing environment. Then those changes get filed out, and some poor sod has to deal with the result - whether harvester, or just someone who tries to load >1 package from SM and gets bitten by incompatible changes. > But for Squeak as a whole? A better analogy, as I've often argued, is > to compare it to a Linux distribution. Squeak as a whole needs to > support all of us working together using the same basic code base. That's fine, and I agree with the analogy *of use*, but I don't agree with the analogy *of development*. Where's chroot() and LD_LIBRARY_PATH? How on earth do I, as a developer of an application inside a larger environment, insulate myself from the chaos around me? At least the Linux folks *know* that if they replace libc, things are in general going to foul up. They know what their dependencies are - hell, you can even *list* them with ldd. How do we prevent changes to (say) Object that cause breakage elsewhere in the image? How do we even know what has changed and might break our code? Given your OS analogy, it's as if libc can change (and break all the other apps that use it) every time you import a package. It's DLL hell, doubled and redoubled. Microsoft tried to address this with smarter installers that didn't replace newer libraries with old, better backward compatibility... Then they threw their hands up, admitted it would never work, and allowed side-by-side assemblies. UNIX has had library load paths for decades. Squeak is getting as large as those systems were when they encountered the problems, and has none of that isolation. > (And given this, I think we should model our processses after linux > distributions, or after SE processes that develop *suites* of > applications, not after SE processes or open source groups that are > building *individual* applications.) Agree. > PS -- why do we see so many depressed posts? Things seem to be > progressing nicely, to me. In every other environment I use, I have a pretty good idea that I can maintain my code with little effort. In Squeak, I'm running the Red Queen's race - I'm trying to keep up with the shifting codebase around me. Dunno about anyone else, but my own depression* is about the amount of time I have to spend fixing my code due to external changes. That's no fun; I enjoy cutting new code, not playing catch-up. If I were on Linux, I would not expect to have to change the code I use for Web-serving just because I've installed a new game. Why should I have to do this in Squeak? - Peter * wrt Squeak; other issues may be contributory :-(.

4 3

A Forum may be better in grouping messages then a mailing list
by jigme 01 Feb '05

01 Feb '05

Any one agree? Though the Squeakland forum is not used by many people currently. 2004-12-17

3 2

[BUG] FileStream class>>concreteStream does not work with Comanche
by Brent Pinkney 31 Jan '05

31 Jan '05

Hi, Squeak 3.8 has changes for m17n multilinguilization. By default FileStream class>>concreteStream now returns MultiByteFileStream instead of the trusty StandardFileStream. Alas, this does not work with Comanche. If Comanche is set up as a bog-standard webserver according to the instructions on SqueakMap*, then opening and image does NOT work. If however one reverts FileStream class>>concreteStream to return StandardFileStream all is well. Any ideas ? * See http://map1.squeakfoundation.org/sm/package/0fdb5ffc-cfa1-4d40-96c2-fe325bc… Brent Pinkney

1 0

Su: Squeak/Spoon Konfabulator Anyone?
by Steven Swerling 31 Jan '05

31 Jan '05

I noticed a neat product called Konfabulator which lets you create small desktop "widgets" that get placed on the desktop and display information downloaded from the web (see http://www.konfabulator.com). You can use Konfabulator, for instance, to create a little widget on your desktop that displays the local weather, or a shot of the traffic from a web cam. There a lot like WindowMaker/NextStep tiles, but of arbitrary shape and size. And Konfabulator provides a simple way to make widgets using JavaScript. Each Konfabulator widget uses its own system process that takes up (usually) around 4-8 megabytes of memory. Are there any takers out there for adding the following to Spoon: 1. Change the VM so that the window displays without a window frame, ala Konfabulator. Allow for transparent portions of the display (also ala konfabulator). 2. Have the ability to display text and images with hotspots. The mvc framework is enough of a UI for allowing the user to alter the applet's preferences. That's it. Since it's Spoon, you've got the Flow already built in for downloading images and data. So the technical aspects of this don't seem overly ambitious. Just with the framework above, most Konfabulator widgets would be quite easy to do. An optional FFI-type package could be provided for the class of applets that monitor other programs and system attributes (ie. The ITunes trackers, the wifi reception gauge, etc). Of course, there's already an app that does all that -- Konfabulator. But by starting with Spoon, you could probably get little applets to run in just a couple megabytes each, beating Konfabulator. Startup and execution speed would be faster. Small devices could be targeted. And Konfabulator costs $25. Of course, the scripting language would be Smalltalk. All good reasons for an applet developer to choose a Spoon-based konfabulator. There have been all kinds of attempts to jump start parcelling of the image. But it might be a good idea to expend a little bit more energy into approaching things from the other direction, and start small. As I understand it, that's the point of Spoon. This just adds a clearly defined target application (a squeak Konfabulator) which might provide some clarity and impetus for the initial development of packages/modules for Spoon. The developer that wants a simple zip tool would port the zip/archiving classes. The developer that wants a slide-show widget would port the ImageReadWriter classes. Someone might want to replace MVC with a compact and skinnable widget set for deployed apps. You get the idea. So is it worth trying?

1 0

Bidirectional text support?
by Michael Latta 31 Jan '05

31 Jan '05

Does Morphic support editing of bidirectional text? The java frameworks place a high emphasis on this, and I would like to know if similar support was included in the internationalization of Squeak? Michael

3 2

Re: Concerns regarding Squeak design quality
by Lex Spoon 31 Jan '05

31 Jan '05

I still think you are being too harsh. At any rate, people are successfully using Squeak for everything from toys to research to products. It's a fact. So why don't we talk about how to do better, instead of how to do tolerably? Michael Latta <lattam(a)mac.com> wrote: > 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. Most Swikis are *not* used by Squeakers. minnow has about 15 non-squeak swikis and about 5 squeak ones, and that's the very server the Squeak swiki is on. swiki.cc.gatech.edu has 235 swikis, and by my quick glance, *none* are related to Squeak itself. All of these users don't care about squeak and just want to get their work done. Most of them probably don't even know what the "s" in swiki stands for. > 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. Isn't that the nature of the beast? Either you write it yoruself, or you find code that someone else has had an interest in writing. How else are you going to get code? Yes, there are a lot of things Squeak has, and a lot of things it doesn't. That is not a very deep observation, if you think about it... > 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. 3.8 is still under development. The multi-lingual stuff hasn't been mixed in very well. I haven't even switched over to 3.8 yet, and I'm a very heavy Squeak user! > I compare this with other open source projects that have regular build > schedules, Do we need this in Squeak? What would be build, exactly? I guess we could re-install the packages automatically, and re-run the tests automatically. > code documentation and comments Some code is documented, some not. Just like in most projects. > and bug tracking that is > clearly available from their website We have had just such a bug tracker for about 6 months. It's linked from the swiki, and is fairly quick to find. It's not on squeak.org yet, because that seems to get updated less frequently. Overall, thanks for your ideas on improving Squeak. Keep in mind, though, that some of this stuff actually exists (like production code and bug trackers), and some of it is not as important for us (like regular builds). On the other hand, there is surely plenty of stuff we could steal from other groups, and any particulars you can point out are great. In addition, you might think about posting changesets instead of rants. If you a feature commented that does not work as advertised, then change the comment and click "mail to list" in a change sorter. Comment-only changesets are one of the easiest ways to improve Squeak, and they do get incorporated quickly. Finally, do be sure to browse around the swiki. It has over 5000 pages of documentation. Lex

1 0

Jump to page: