Squeak-dev January 2002

squeak-dev@lists.squeakfoundation.org

176 participants
612 discussions

[ENH] SUnit TestSuite extensions, so we can build and debug suites from a workspace
by Rob Withers 05 Jan '02

05 Jan '02

This is from a 4411 image, but should work for 3.2alpha as well. Now one can do the following: | suite | suite := TestSuite new. suite addTest: ProxyTestCase buildSuiteFromSelectors. suite addTest: MixinProxyTestCase buildSuiteFromSelectors. suite debug rob

1 0

[FIX] Browser-NoHardCodedBrowserClassReference
by stephane ducasse 05 Jan '02

05 Jan '02

from preamble: "Change Set: Browser-NoHardCodedBrowserClassReference Date: 5 January 2002 Author: stephane ducasse Ready for 4599 This changeset changes all the Browser hardcoded reference in the Browser class methods into self and for the instance methods into self class . This way subclasses can work!!!!!! We can consider that as an enhancement but not alllwoing subclassing is a bug for me"!

1 0

RE: GPG plugin (was Re: [ANN][VM][SF] my Unix patches integrated into SF layout)
by danielv＠netvision.net.il 05 Jan '02

05 Jan '02

Read an article (in an ACM transactions, I believe) about such a system - each user would many virtual mailboxes. Unprivileged writers would only know the basic public box, which would discard any message not bearing a stamp (some form of micropayment). After you recognize a friend has sent you a stamped message, the polite thing to do is of course to return the stamp along with a priviledged sub-address that doesn't require a stamp. So once you've made contact, it's just email. But if you're a spammer, you pay for every unwanted mail you want read. Of course, micropayments are still quite a bit less available than encryption, so... But it's a nice idea. Daniel Stephen Pair <spair(a)advantive.com> wrote: > Along these lines, it would be great to create an entirely Squeak based > email system that would allow the email account holder to decide who is > allowed to send them messages...I imagine that some sort of protocol > involving public key cryptography could be useful such a system...spam > is such a huge annoyance these days that such a system might get a lot > of attention. > > - Stephen > > > -----Original Message----- > > From: squeak-dev-admin(a)lists.squeakfoundation.org > > [mailto:squeak-dev-admin@lists.squeakfoundation.org] On > > Behalf Of Tim Rowledge > > Sent: Friday, January 04, 2002 5:55 PM > > To: squeak-dev(a)lists.squeakfoundation.org > > Subject: GPG plugin (was Re: [ANN][VM][SF] my Unix patches > > integrated into SF layout) > > > > > > "Lex Spoon" <lex(a)cc.gatech.edu> is widely believed to have written: > > > > > And I've thought GPGPlugin would > > > be nice, to hook into Celeste. > > I was just about to post a message asking about this. Some > > form of ability to handle encrypted mail would be pretty > > handy. There's quite a bit to it from some discussions I've > > had recently with a friend that wrote much of the original > > SSL stuff. Considering that we are discussing seriously > > subversive topics here that impact M$'s plans to take over > > everything we should be more careful to encrypt it. > > > > tim > > > > -- > > Tim Rowledge, tim(a)sumeru.stanford.edu, > > http://sumeru.stanford.edu/tim Strange > OpCodes: LTT: Lose Timing > Track > > > > > >

3 2

Reading/writing JPEG comments
by Joshua 'Schwa' Gargus 05 Jan '02

05 Jan '02

Hi, I was browsing through the new JPEG code, and didn't immediately see a way to embed comments or other arbitrary data within a JPEG. I believe that the standard supports this; before I dig deeper, I hope someone can give me a quick answer. The reason I want to do this is to embed a serialized and compressed morph (such as you'd find in a .morph.gz file) inside a JPEG that looks like the morph. My goal is to integrate a simple drawing tool into a Swiki that can edit a compound morph, and then generate a JPEG to be displayed in an HTML page. If someone want to re-edit the JPEG, the morph stored in the "arbitrary data area" is opened in the browser plugin. Thanks, Joshua

2 1

Re: Re: Primitive failure with second version of JPEGReadWriter2P lugin
by jmvuletich＠uolsinectis.com.ar 05 Jan '02

05 Jan '02

Hi Karl, I made a mistake. The Smalltalk code needed to run the latest version of the plugin is at: http://groups.yahoo.com/group/squeak/message/37086 In my previous message I directed you to an older version. Please file in that thange set, and the plugin should work OK. This cs will get in the update stream real soon anyway. I'm sorry for making you loose your time. Regards, Juan Manuel Vuletich > > > John M McIntosh wrote: > > > Well it might be best if we agree upon both the C source and the > > Smalltalk code, if there is an issue I'll distribute another plugin. > > > > Karl if you can demo the problem? We should see if other have the > > same issue? Maybe there is a missing changeset somewhere? > > > I downloaded a Squeak3.2a-4599 image changes from the ftp. > This I run with the Squeak 3.1Alpha1MT vm. > JPEGPlugin from the ftp. > MacOS 8.6. > ...

3 4

Re: [FIX][VM][UNIX] vmPath (was: "Re: [BUGS] Looking for plugins (Linux)") (2)
by Joern Eyrich 05 Jan '02

05 Jan '02

> > Me, I'm more than happy for people to improve code I write. Sometimes I > > even learn something from it! > Well, not this time; it's mainly a cut & paste job... Which, of course, means it should be refactored... attached is an updated SHA.4 version of sqXWindow.c Joern

1 0

Re: [ANN][VM][SF] my Unix patches integrated into SF layout
by Joern Eyrich 05 Jan '02

05 Jan '02

> Still, just one small request on how the copying is done: why do all the > internal plugins get smushed together in src/vm? If they have a > same-named file, such as make.inc on Unix, then those files will > overwrite each other. How about having a "src/intplugins" hierarchy > that's just like the "src/plugins", except that it's for internal > instead of external plugins? Good point. I naively assumed more or less only an xyz.c and xyz.h per plugin. I realize it doesn't make sense for me to discuss the build process before I have had a deeper look into it. > > Makefile:286: warning: overriding commands for target > > `sqUnixExternalPrims.o' > > Yuck, well, they should *really* be gone now, though there's one new > complication mentioned above. Cool, I get a clean build now. Joern

1 0

About Button
by ducasse 05 Jan '02

05 Jan '02

Hi, I would like to know what is PluggableButtonMorph a subclass of AlignmentMorph and why SimpleButtonMorph and all is subclasses are not subclass of AlignmentMorph? Does it mean that certain buttons are not polymorphic? Stef

1 0

Re: [ANN][VM][SF] my Unix patches integrated into SF layout
by Lex Spoon 05 Jan '02

05 Jan '02

> > > If they have a > > same-named file, such as make.inc on Unix, then those files will > > overwrite each other. How about having a "src/intplugins" hierarchy > > that's just like the "src/plugins", except that it's for internal > > instead of external plugins? > That could probably be made to work, although it would be little tedious > to rewrite. Maybe it would be simpler to add a unix subclas of VMMaker > that understood the possiblity of these extra make.ic files and merged > them? I'm curious what should be done when they are intended to be > external though; presumbly something ought to be done with them? Is this > in danger of invoking the 'recursive make considered dangerous' > argument? Hmm, you could do the merging in VMMaker, and it would be a lot nicer than the shell script I've been using. That's a nice idea! Plugins that use external libraries are the ones that are likely to have their own build rules. For example, Mpeg3Plugin not only *uses* an external library, but *builds* the library. Also, VorbisPlugin appears to be coming on the scene before long. And I've thought GPGPlugin would be nice, to hook into Celeste. And so on. Squeak is starting to reuse some existing libraries, waddya know? Really, in a nutshell, the idea is that external and internal plugins are very similar. They are going to be compiled almost exactly the same way whether they are internal or external, and so it is convenient to have the same directory structure each way. But, I wouldn't want you guys to have to redo the Mac and RiscOS platforms for it. > > Perhaps this is another strong argument for OSProcess driving the > compiler directly ! I don't think you want it running "cc' directly, because make's functionality is really nice. I don't think you really want to redo make in Squeak -- while it sounds so simple, everyone who tries redoing make ends up going on for months and then just posting what they have and going on to something else. Also, a lot of the autoconf code can't easily be moved into Squeak; while autoconf is simpler than make, it's still not something that seems worth fiddling with since it already exists! Still, parts of the build stuff could certainly be moved into VMMaker, and firing "make" via OSProcess sounds very handy. Hmm.... -Lex PS -- in SHA, you should guess that the make rules aren't invoked recursively -- the files are called make.*inc* for a reason. :)

5 5

Status Check on 3.1 and/or 3.2
by Roger Vossler 05 Jan '02

05 Jan '02

Hi Gang, I see that 3.1beta and 3.2alpha are on the UIUC archive site. Are we going to have an official 3.1 release? Is 3.1 going to be skipped in favor of 3.2? What's the real story here? Cheers, Roger.....

2 1

← Newer
1
...
53
54
55
56
57
58
59
...
62
Older →

Jump to page: