Squeak-dev July 2004

squeak-dev@lists.squeakfoundation.org

146 participants
464 discussions

[BUG]
by tomkoenig＠mindspring.com 31 Jul '04

31 Jul '04

The error report: 30 July 2004 8:42:05 pm VM: Win32 - a SmalltalkImage Image: Squeak3.8alpha [latest update: #5976] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Documents and Settings\Thomas Koenig\Desktop\Squeak Trusted Dir C:\Documents and Settings\Thomas Koenig\Desktop\Squeak\Thomas Koenig Untrusted Dir C:\My Squeak\Thomas Koenig Rectangle>>rightCenter Receiver: 100@100 corner: 200@200 Arguments and temporary variables: Receiver's instance variables: origin: 100@100 corner: 200@200 DecentReviewerNPBugReportTest>>setUp Receiver: DecentReviewerNPBugReportTest>>#testSend Arguments and temporary variables: Receiver's instance variables: testSelector: #testSend aDecentReviewerNotePad: a DecentReviewerNotePad(3186) aCrashDmp: AttachmentResource aMethodContext: Rectangle>>rightCenter [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} Arguments and temporary variables: BlockContext>>ensure: Receiver: [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} Arguments and temporary variables: aBlock: [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self tearDown]...etc... returnValue: nil b: nil Receiver's instance variables: sender: BlockContext>>ensure: pc: 28 stackp: 0 nargs: 0 startpc: 26 home: DecentReviewerNPBugReportTest(TestCase)>>runCase --- The full stack --- Rectangle>>rightCenter DecentReviewerNPBugReportTest>>setUp [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} BlockContext>>ensure: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BlockContext>>sunitEnsure: DecentReviewerNPBugReportTest(TestCase)>>runCase [] in TestResult>>runCase: {[aTestCase runCase. true]} BlockContext>>on:do: BlockContext>>sunitOn:do: [] in TestResult>>runCase: {[[aTestCase runCase. true] sunitOn: self class failure do: [:signal | ...]} BlockContext>>on:do: BlockContext>>sunitOn:do: TestResult>>runCase: DecentReviewerNPBugReportTest(TestCase)>>run: [] in TestSuite>>run: {[:each | self sunitChanged: each. each run: aResult]} OrderedCollection>>do: TestSuite>>run: [] in TestSuite>>run {[self run: result]} BlockContext>>ensure: BlockContext>>sunitEnsure: TestSuite>>run [] in TestRunner>>runSuite: {[result := suite run]} BlockContext>>ensure: [] in TestRunner>>runSuite: {[[result := suite run] ensure: [running := nil. suite removeDependent: ...]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

1 0

[BUG]
by tomkoenig＠mindspring.com 31 Jul '04

31 Jul '04

The error report: 30 July 2004 8:08:23 pm VM: Win32 - a SmalltalkImage Image: Squeak3.8alpha [latest update: #5976] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir C:\Documents and Settings\Thomas Koenig\Desktop\Squeak Trusted Dir C:\Documents and Settings\Thomas Koenig\Desktop\Squeak\Thomas Koenig Untrusted Dir C:\My Squeak\Thomas Koenig Rectangle>>rightCenter Receiver: 100@100 corner: 200@200 Arguments and temporary variables: Receiver's instance variables: origin: 100@100 corner: 200@200 DecentReviewerNPBugReportTest>>setUp Receiver: DecentReviewerNPBugReportTest>>#testSend Arguments and temporary variables: Receiver's instance variables: testSelector: #testSend aDecentReviewerNotePad: a DecentReviewerNotePad(3784) aCrashDmp: AttachmentResource aMethodContext: Rectangle>>rightCenter [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} Arguments and temporary variables: BlockContext>>ensure: Receiver: [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} Arguments and temporary variables: aBlock: [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self tearDown]...etc... returnValue: nil b: nil Receiver's instance variables: sender: BlockContext>>ensure: pc: 28 stackp: 0 nargs: 0 startpc: 26 home: DecentReviewerNPBugReportTest(TestCase)>>runCase --- The full stack --- Rectangle>>rightCenter DecentReviewerNPBugReportTest>>setUp [] in DecentReviewerNPBugReportTest(TestCase)>>runCase {[self setUp. self performTest]} BlockContext>>ensure: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BlockContext>>sunitEnsure: DecentReviewerNPBugReportTest(TestCase)>>runCase [] in TestResult>>runCase: {[aTestCase runCase. true]} BlockContext>>on:do: BlockContext>>sunitOn:do: [] in TestResult>>runCase: {[[aTestCase runCase. true] sunitOn: self class failure do: [:signal | ...]} BlockContext>>on:do: BlockContext>>sunitOn:do: TestResult>>runCase: DecentReviewerNPBugReportTest(TestCase)>>run: [] in TestSuite>>run: {[:each | self sunitChanged: each. each run: aResult]} OrderedCollection>>do: TestSuite>>run: [] in TestSuite>>run {[self run: result]} BlockContext>>ensure: BlockContext>>sunitEnsure: TestSuite>>run [] in TestRunner>>runSuite: {[result := suite run]} BlockContext>>ensure: [] in TestRunner>>runSuite: {[[result := suite run] ensure: [running := nil. suite removeDependent: ...]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

1 0

[BUG]DecentReviewerNotePad mailing out bug report!
by Karl Ramberg 31 Jul '04

31 Jul '04

Selecting mail out bug report from the debugger menu opens the DecentReviewerNotePad but another DecentReviewerNotePad window is attached at the bottom of the first one. Weird. I have also noticed it is hard to bring other windows to the front of the desktop if there is a DecentReviewerNotePad active. Sometimes I have to move the window behind to bring it to front. I'm using the BFAV2.11 version. Karl

4 5

Over The Air
by Jan B. Krejci 30 Jul '04

30 Jul '04

Ladies and gentlemen, I'm happy to announce my new package at SqueakMap - Over The Air. The package contains small GSM-modem server, capable to send and receive PDU encoded SMS from (hopefully) number of AT-compatible GSM phones and modems. It can be controlled via simple HttpView2 interface. You can run one instance for every serial port you have (but only the one at port 0 has the web interface). Works through /dev/ttySx (making symlink you can even run it against /dev/ttyUSBx) on Linux and COMx on Windows. Not tested, but probably working on other systems, too. Because I'm not a Smalltalk guru (yet :-) ), any help, especially code review from somebody experienced will be appreciated. Regards .:jbk:. jbk at umim dot net Jan B. Krejci

1 0

UTF8 as default text encoding? (was: Re: m17n ready to go)
by Hannes Hirzel 30 Jul '04

30 Jul '04

Ned Konz wrote: > On Thursday 29 July 2004 2:14 pm, Yoshiki Ohshima wrote: > >>>>Again, the default assumption is that the String will hold text -- even >>>>though there's nothing in it yet! It seems to me that the default >>>>converter for this stream should be the Latin1TextConverter. If a >>>>particular user of a String has a need for or knowledge of a particular >>>>encoding, they can change the converter. >> >> No. If the default is Latin1TextConverter, there would be more >>problems. > > > Like what? If everyone who wants text is specifying the type (like you suggest > below) there shouldn't be any problems. > > >>>>However, I don't think it's right to introduce new and incompatible >>>>character conversion semantics on the existing file API. >> >> The rule of thumb is that if you open a file, you should think about >>it is text or binary, and if it is text, you should think about how >>it is interpreted. > > > Sure. And the authors of the code that was broken had done that when they > wrote it. > This boils down to the question if Latin1 or UTF8 should be the default text encoding. If one thinks backwards Latin1 is probably the choice whereas if we look forward UTF8 is surely to be preferred. I personally prefer UTF8. But perhaps this decision might be postponed? Hannes

2 1

come play in a universe
by lex＠cc.gatech.edu 30 Jul '04

30 Jul '04

I have cobbled together a little prototype in order to describe what I am talking about. I hope this makes it clearer what I am talking about. It is also interesting that it only two two days of work to get it together. I'm not a fast coder. You simply don't need that much code to get auto-installing, if you build your tool around package universes. The rest of this post is also available on the swiki: "Package Universes" http://minnow.cc.gatech.edu:8080/squeak/3785 Package universes are an approach to supporting one-click installs via a package loader. See Why Packages Exist for an argument that package universes exist. This page describes how to leverage package universes in order to get one-click installs. Trying it Out To try it out, install universe-0.sar into a fresh Squeak 3.7 image. Then "open...Universe Browser". You'll have to press the "update list" button the first time you load the universe browser, and then after a few seconds you will see a list of packages available in the default "Wild n Woolly" universe. Try scrolling down to the "BFAV2" package, selecting it, and then pressing the "install package" button. You will notice that the text (install) appears next to the item now -- that means that the package has been flagged for installation. If you scroll down in the list, you will see that HTTPClient has also been flagged for installation; this happened because BFAV2 depends on HTTPClient. Next click the big "INSTALL" button at the bottom of the window, and the Universe Browser will download BFAV2 and HTTPClient and install them for you. How to Post and Edit Packages If you want to post or edit a package, you need to use the Universe Editor. Use the "open" menu to open a universe editor. You will initially need to create an account. So, type in a username and password, and then press the "create account" button. You will be asked to fill in an email address; leave it blank if you prefer, but this email can be used in case your password is forgotten. New you can press either "new package" or "new package version", depending on whether you want to add an entirely new package or you'd prefer to simply edit an existing template. A new window will pop up and you can fill in the fields that describe your package. Click "submit" when you are finished. If you see a package that you think is yours, then go ahead and feel free to update it. If you are the first to try and edit any information about packages with a particular name, then the Wild n Woolly universe will let you do it. What's a Package Universe? A package universe is a set of packages plus policy on how the set is allowed to change over time. It is called a universe, because each Squeak image will exist within one such universe, and each user will operate within one such universe at a time. A universe provides answers the question "what exists?"; anything outside a user's current universe is completely ignored. Why Bother with this Universes Stuff The short answer is that it seems to work. Universes exist, and it seems to work well to manage them explicitly. Here are some things we can handle, if we and our software explicitly discuss package universes. Simple Dependencies Work By limiting the number of packages that are in the universe, simple dependency approaches are sufficient. There is no need to track which individual versions of which packages are compatible with each other, because people working in any given universe will tend to use the newest versions available within that universe. As a result, dependencies like "A depends on B" are usually fine. If the main author of B has developed B into a form that is incompatible with A, then that package will simply not be posted into the universe. And even if the newest A and newest B are incompatible, the situation can be treated like any other bug: fix A, fix B, or reject one of the two from the universe. Once one is committed to operating within one universe at a time, dependency management can be greatly simplified. Update Policies It is well known that some users prefer the newest software and others prefer the most stable. The packaging approaches described so far seem to by planning to make the package-installer software customizable by the individual users in order to select these preferences. There is no specific mechanism, however, that has yet been proposed. It's always been a problem of the future. The perspective that package universes give is the following: if you want stable packages, then you probably want all of your packages to be stable. Thus, it makes sense to define and maintain a universe of stable packages. Likewise, if you have a few new under-development packages, you probably want to go ahead and try out the new versions of most packages. Thus, it also makes sense to define a wild 'n woolly development universe. Package universes give an easy way to organize and manage these different update policies. You can just say "this universe works like this" and "that universe works like that". Expected Content In addition to different policies, some universes will simply contain stuff that is different. Different universes provide a convenient way to manage different content alltogether. While I might like to put my collection of home videos on the internet and accessible to my family, the rest of the world would prefer not to even be concious of these terribly boring things (or, they'd like to see THEIR home videos). While most of the world might want to have DVD software available publically, such software can likely not be posted to any server that is in the United States. Package universes provide a natural way to manage these different kinds of expected content. No matter how benevolent and permissive any central Squeak authority is, there is sure to be some content that is not appropriate for the general public but that would make a lot of sense to have available for those that want it. Mixin Universes The desire for mixin universes follows from the above desires. Much of the unusual content that people provide is relatively agnostic about Squeak version, and can be combined with other such unusual content in arbitrary combinations. A mixin universe is a set of packages that can be mixed into a large number of other universes without breaking too much. Package universes provide a simple way to think about these mixins: you create larger universes simply by taking the union of the packages in two separate universes. Theory aside, note that Debian supports mixin repositories, and their http://www.apt-get.org meta-catalog lists hundreds of repositories that are at least mostly intended as mixins. Shorter Names By limiting the number of packages that are available in a universe, names can often be shorter than they would otherwise need to be. A universe provides context. In a development universe for Tweak, one doesn't need to name the package "TweakBase", but can instead just say "Base". Everyone will understand that the "Base" package of the "Tweak" universe is the base package of Tweak. On the other hand, it doesn't make sense to post a package named "Base" on SqueakMap. No one will understand what it is the "base" of. Existing Universes There are four "well-known" universes in the above package. Only one of them is really useful, but the others are interesting food for thought. Browse to UUniverse's class methods, and you will see the code to switch universes to one of these others. CAUTION however: mixing packages from different universes is a recipe for confusion, so you will usually want to start in a fresh image before switching universes. * "Wild n Woolly" -- this is the currently useful one. It has a copy of most of the latest packages on SqueakMap on it. It is intended to be a development arena. Packages are inconsistent at early phases of this universe, but over time they should become more consistent or, if they remain problematic, be kicked out of the universe. The update policy on Wild n Woolly is that anyone may create a new account, package names are owned by users, and packages may only be updated by their users. Ownership is decided by: the first person to try to use a package name wins. Aside from those constraints it is free reign. Yee ha! * "Stable" -- This is a model for what a frozen universe could be like . No one is allowed to make updates to this universe except for one person or a small number of people. These people will only let through updates that are clear bug fixes. * "Home Movies" -- This is a universe that holds reams of home videos for a rather unusual family. Only the family may post to it, though they do post it on the net for anyone who wants to read from it. * "Example Compound Server" -- this universe is a union of "Wild n Woolly" and "Home Movies". "Home Movies" is pretty useless by itself, so is usually used in tandem with some other universe. Future Directions As of July 2004, Universes is merely a prototype to show how to build tools based on package universes. In particular, I'm afraid the UI is so ugly it will actually harm those who look upon it. Thus, I am happy whether it is used itself, or whether the ideas get incorporated into some other tool. I'm most happy of all if, in either case, someone else does the future maintenance. :) Note, though, that "package universes" software is orthoganal to a Catalog of Everything tool. A catalog of everything has an index for every package that anyone cared to post, while a package universe holds some consistent subset of those packages. Since these are distinct purposes, it may make sense for the two tools to be separate. Lex Spoon

1 0

mouse clicks in os-x
by John M McIntosh 30 Jul '04

30 Jul '04

Since I'm busy working on multiple window support an annoying issue finally percolated upwards in how the carbon os-x VM works with mouse clicks. I believe the standard behavior should be that clicking on an inactive window brings that window to the foreground and does not process the action of clicking on the contents of the window. However a side effect of how we are processing mouse events means the mouse event is passed into squeak on a window activate. An example would be to startup squeak, startup another application in the foreground, then click on the squeak desktop area when squeak is the background application. This then brings the squeak and the squeak window to the foreground, and also then triggers the display of the desktop menu. What I'm proposing here is to "FIX" that issue and revert to standard click processing on window activation. Squeak and the squeak window should come to the foreground, but we shouldn't pass on that mouse click to cause the desktop menu to be displayed. Please let me know if you have any concerns with this change. PS if anyone used the carbon mac os-x- squeak feature to make the squeak window into a floating window they might want to check their application very carefully once I submit a 3.8 VM for testing. -- ======================================================================== === John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===

6 12

[BUG][BFAV][m17n]Attachments download
by Karl Ramberg 30 Jul '04

30 Jul '04

Attachments downloaded with BAFV when m17n is installed are corrupted. karl

1 0

Re: Thank you!
by Cg 30 Jul '04

30 Jul '04

1 0

Protected message
by Cg 30 Jul '04

30 Jul '04

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
47
Older →

Jump to page: