Squeak-dev June 2003

squeak-dev@lists.squeakfoundation.org

188 participants
973 discussions

Start a nNew thread

[FIX] MailSenderBugFix [approve]
by danielv＠netvision.net.il 05 Jun '03

05 Jun '03

Aahh... one harvesters dream has come true... :-) < Brought to you by the BugFixArchiveViewer and CommentNotePad >

1 0

How to use PackageInfo (was: RE: About 3.6 alpha process: to breakthe less)
by Daniel Vainsencher 05 Jun '03

05 Jun '03

:-) pi _ PackageInfo named: 'Morphic'. "generates something that aggregates all the classes in class categories whose names start with the 'Morphic', plus all the methods in other class categories that reside in method categories whose names begin with '*Morphic' (aka - class extensions)" pi browseExternalReferences. "shows what outside Morphic reference Morphic - useful for making sure something is removable." pi fileOut "pretty self explanatory" It also has enumeration and testing protocols to tell you what code it encompasses. If you don't like the scheme for determining what is part of a PackageInfo and what isn't, you're welcome to subclass PackageInfo. I've done this to create CompositePackageInfo, for example, to be used in a future version of MudPie. Daniel Andreas Raab <andreas.raab(a)gmx.de> wrote: > > > I don't know whether usage of DVS should be mandatory - I > > > think usage of PackageInfo should be. > [...] > > I'd like to emphatically second this - DVS is just one system > > for getting packages in and out of an image, PackageInfo is the > > crucial bit, because it is what allows you to unambiguously > > specify what piece of code is in which package. > > Okay, even if that's the stupid question of the day but how exactly does one > use PackageInfo? > > Cheers, > - Andreas

1 0

[FIX] MailSenderBugFix ( [sm][et][cd] very small; no-brainer to include )
by bvukmer＠blackboard.com 05 Jun '03

05 Jun '03

This is a very small ( 1-liner ), very necessary fix to include in 3.6 .. < Brought to you by the BugFixArchiveViewer and CommentNotePad >

1 0

[FIX] File*-MiscFixes-bkv
by bvukmer＠blackboard.com 05 Jun '03

05 Jun '03

from preamble: "Change Set: File*-MiscFixes-bkv Date: 4 June 2003 Author: Brent Vukmer Here are some changes that I made in my image to get FileUrl>>pathString to produce a correct result on Unix and for FileUrl>>retrieveContents to work on Windows."!

1 0

RE: Final 3.6 Plan
by Brent Vukmer 05 Jun '03

05 Jun '03

> > And what about the file related stuff that apparently exists? > I got seriously bitten by some bugs in FileUrl recently.. <plaintively> Can we please get some File* cleanup in 3.6/ </plaintively>

1 0

Re: About 3.6 alpha process: to break the less
by Daniel Vainsencher 05 Jun '03

05 Jun '03

Loading this package reloads all the packages unloads. If you want to work on a Full image, as you stated, this will help. I've stated before that I don't think that's the solution - I think that refactoring an image with any subset of SM package will break some stuff. Working in Full will make you generate patches to lots of packages. This is good, if you intend to help the maintainer of each package integrate it. Otherwise, it's a waste of time. Either way, don't feel free to deprecate anything you don't think is used, because you *don't* have a closed world. Give consideration to what you remove/deprecate. Daniel Stephane Ducasse <ducasse(a)iam.unibe.ch> wrote: > Hi daniel > > I'm a bit lost. Should I load this package in 3.6 before my KCP changes > then I can produce different changesets for each removal? > > Stef > > On Wednesday, June 4, 2003, at 02:17 PM, Daniel Vainsencher wrote: > > > Just wanted to note that this is exactly what the SM package "Upgrade > > to > > 3.6 Full Image" does. Doug did this a few weeks back. > > > > Daniel > > > > Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > >> One relatively simple tool I can see a use for is just the set of > >> scripts to produce the currently dropped out packages; not the removal > >> of the code, which we already have but the production of the stuff to > >> file back in. > >

5 6

Croquet: A Collaboration Architecture
by Tim Will 04 Jun '03

04 Jun '03

I am trying view the video at this site "http://murl.microsoft.com/LectureDetails.asp?1019" that Alan gave recently on Croquet. I was able to view part of it last week and can not reconnect to the server this week to watch the rest. I am also unable to contact the webmaster through their feedback page due to the same server problems. Does anybody know who to contact to remedy the situation. Thanks, Tim

2 1

Re: Dialog warn: equivalent in squeak
by JOEL SHELLMAN 04 Jun '03

04 Jun '03

As I mentioned, if you need the flexibility of a level of indirection, put it in. It's the difference between a hard and soft dependency. If you have a hard dependency, you will not be able to remove PopUpMenu (ie. your app requires that functionality). A soft dependency means you require similar functionality but could be swapped out. In that case, put in a level of indirection and you're fine. That's just standard good practice. One of the problems with putting it on Object is that if you change it-- you change it for everything. So if you change it for your app, someone else's app now behaves differently than it (or the user) expected which could cause problems. -joel ----- Original Message ----- From: Bert Freudenberg <bert(a)isg.cs.uni-magdeburg.de> Date: Wednesday, May 28, 2003 7:08 am Subject: Re: Dialog warn: equivalent in squeak > > Am Mittwoch, 28.05.03 um 15:34 Uhr schrieb Joel Shellman: > > >> Actually, "self inform:" is way better. > >> > >> How would creating an explicit dependency to PopUpMenu be > better than > >> a > >> generic message send to self? That is as encapsulated as you > can get. > >> > >> The fact that _currently_, generic methods are implemented as > instance>> methods of Object is just a nuisance. The main point is > that > >> currently, > >> any object depends on Object anyway, so no artificial > dependency is > >> introduced at all. > > > > Not only are you introducing an artificial dependency, but you are > > introducing a hidden dependency because anyone who uses self > inform: > > will > > now be dependent on PopUpMenu and may not even realize it. > > Not so. _My_ code is not dependent on PopUpMenu. Suppose you > remove > PopUpMenu (which you surely might want to do in a non-GUI > environment) > - would you rather go and fix a myriad of places explicitely > naming > PopUpMenu? Or would you rather reimplement Object>>#inform:? > > -- Bert > > >

3 2

Re: About 3.6 alpha process: to break the less
by Daniel Vainsencher 04 Jun '03

04 Jun '03

Just wanted to note that this is exactly what the SM package "Upgrade to 3.6 Full Image" does. Doug did this a few weeks back. Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > One relatively simple tool I can see a use for is just the set of > scripts to produce the currently dropped out packages; not the removal > of the code, which we already have but the production of the stuff to > file back in.

3 2

Re: fonts and unicode (esp. Devanagari)
by Darius 04 Jun '03

04 Jun '03

How well does Squeak support Arabic? I've been contracted for a job in which a second phase might include an Arabic version of the application. The only requirements for the use of Arabic text would be to display text in content, text in navigation menus, storing short text notes to oneself about the content, copy/paste text, and sending e-mails with Arabic text for customer support. (Are e-mail addresses in Arabic too?) I'm evaluating the best technologies for the job now. Cheers, Darius

2 1

← Newer
1
...
90
91
92
93
94
95
96
97
98
Older →

Jump to page: