headers
Marcel Weiher | 8 Nov 2000 23:35

Reactive Squeak ( [VM] Hooks from module into platform support code?)


[Henrik had asked why it wasn't possible to call a Squeak method  
from the outside]
[Andreas gave lots of good, technical reasons[

Although the reasons Andreas gives are all excellent, I don't really  
think they answer Henrik's question, which I would restate as  
follows:  why are there all these (absurdly) difficult obstacles to a  
rather straightforward requirement.  After all, what more basic  
requirement can you have for a method than invoking it?

The answer, as so often, is architectural mismatch (*).  Squeak is  
built around architectural assumptions that make it difficult for it  
to interoperate with other systems.  One of these assumptions, and  
one talked about at length in the referenced paper, is ownership of  
the event-loop, of the thread of control.

A system that assumes it has control of the event loop will be  
difficult to impossible to integrate with other systems that make the  
same assumptions.  On the other hand, a stand-alone system must take  
charge of the event loop, and Squeak does, in essence, play the part  
of a stand-alone system, with the integration problems that we keep  
running into.

However, I believe it should not be too difficult, and quite useful,  
to re-cast Squeak as a reactive system, similar to the way Objects  
were turned into re-active entities in Smalltalk-76 [I hope this  
characterization is correct].  One of the keys to this is that  
object-oriented systems, unlike procedural ones, don't really need to  
be active in order to offer well differentiated reaction to external
(Continue reading)

Permalink | Reply | 0 comments |
headers
John M McIntosh | 15 Nov 2000 21:02

Re: Stability opf Squeak on Linux

>
>I did have it this way, originally, but one of the Flow tests didn't
>like it so I changed it to closing both the read and write channels.  As
>John mentions, most code checks isConnected.
>
>Squeak State
>Unconnected            read data: no   write data: no
>WaitingForConnection   read data: no   write data: no
>Established            read data: yes   write data: yes
>ThisEndClosed          read data: yes   write data: no
>OtherEndClosed         read data: no   write data: yes ???
>
>If we have agreement on this, and decide what close means (shutdown
>write only?), and determine that a read or write primitive fails
>(exception signalled), when attempted in the wrong state, then we will
>have just about licked this thing.

On the mac if the otherEndClosed and we attempt a write I *think* 
we'll end up with a primitive failure. What really happens here is I 
just invoke the socket write (OTSnd) and if it fails and the failure 
case isn't one I've got a valid handler for (flow control for 
example) then we invoke a primitive falure.

The reason for this is that because the socket state is run at the 
interrupt level I can't check a flag to see if the socket is still 
valid to write to because it's no guarantee that the socket will be 
writable at the point when I want to do the write (a race condition 
issue), thus I just let the write fail.

Re close from the Squeak code
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Briggs | 15 Nov 2000 06:11
Picon

Re: Bug Tracking (Re: Squeak 2.8 "finalization")

On Tue, Nov 14, 2000 at 11:45:00PM +0100, Stefan Matthias Aust wrote:
> 
> I can only repeat myself and ask all bug report provider to actively lobby 
> and make sure that their fixes are incorporated.
> 
> >(I suspect it is too much distraction to write this as a Squeak server and 
> >application, though I don't know).
> 
> Well, sourceforge is available *now*.  I consider this as a big 
> advantage.  My question would be, how well does the CVS /patches / files 
> stuff of sourceforge work together with Squeak's changesets / images / etc?
> 
> 
> bye
> --
> Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf
> 

While going through the newsgroups the other day I discovered the Aegis 
transaction-based software configuration management system.
	http://www.canb.auug.org.au/~millerp/aegis/aegis.html

This may provide a solution to the problems you have been discussing.

John Briggs
Permalink | Reply | 1 comment |
headers
John M McIntosh | 3 Nov 2000 08:12

Re: MPEG3 DLL for Windows

>Download the Squeak code from John's site:
>http://www.smalltalkconsulting.com/html/mpeg3source.html
>

We'll reintegrate the macintosh and windows source code in a few 
days, for people wishing to compile their own version. So don't 
expect to find windows source code on my site yet...

But Ya Stephen....
--

-- 
--
===========================================================================
John M. McIntosh <johnmci <at> smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================
Permalink | Reply | 0 comments |
headers
Kazuhiro ABE | 2 Nov 2000 05:22
Picon

Re: Help with Multilingualized Squeak (was: Re: Celeste withGerman Umlaute)

Hello, Bernhard

I took charge of the part of Celeste in M17n Squeak(CelesteJ). CelesteJ
is supporting only Japanese now.  I think that the current status of
CelesteJ is pre-alpha.

On Wed, 1 Nov 2000 15:29:30 +0100
Bernhard Pieber <pieber <at> acm.org> wrote:
> I then tried to receive mail with Umlaute which I composed in Outlook
> Express. Multilingualized Squeak showed Umlaute in the message text
> correctly! However, it did not show Umlaute in a message subject. I got
> '=?iso-8859-1?B?dGVzdCDk9vzE1tzf?=' instead.

Sorry, CelesteJ does not support MIME header encoding now. I plan to
make CelesteJ correspond to it. 

> A second problem is that I cannot compose a mail using Umlaute because when
> I press a key the wrong glyph is shown.

M17n Squeak remaps glyphs of a StrikeFont(NewYork) from Sqeuak specific
(MacRoman) to ISO-8895-1. But the keycode that returned from
InputSensor>>primKbdPeek and primKbdPeek is MacRoman.

> What would have to be done to fix those problems? Do I need a different font
> with the right encoding? Or should the problem be fixed somewhere else, in
> ParagraphEditor or InputSensor? You see, I am not sure what the right design
> is here. As always, any help is appreciated.

Please try the attached patch.
The patch converts the keycord from MacRoman to ISO-8895-1.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stefan Matthias Aust | 11 Nov 2000 20:15
Picon

Re: [FIX] macintosh 2.9.4 source code update

At 13:53 11.11.00 -0500, David N. Smith \(IBM\) wrote:

> >So If you've build a VM from the macintosh source, you need this
> >change file and a rebuild.
>
>I assume this will eventually show up in the update stream?

I cannot (will not, sorry) process .sit files and leave this one for the 
SqC which is, I'm sure, already aware of that fix.

bye
--
My eyes adapted to the darkness... finally I can see clearly now
Permalink | Reply | 0 comments |
headers
Stephan Rudlof | 29 Nov 2000 18:54
Picon

[FIX][plugin] LargeIntegers v1.2

This fix correponds to the fix with subject
	[BUG][FIX] anyBitOfMagnitudeFrom:to:Fix-sr
.
It fixes the corresponding method inside the LargeIntegers plugin.

Greetings,

Stephan

"Change Set:		LargeIntegersV1.2-sr
Date:			29 November 2000
Author:			Stephan Rudlof

Fix:
	LargeIntegersPlugin>>anyBitOfBytes: aBytesOop from: start to: stopArg 

Minor Fix/Improvement:
>>testTwoComplementRightShift:
	moved it from LargePositiveInteger to Integer and corrected user messages.

ToDo:
(If commented out) you have to uncomment the primitive call in
Integer>>anyBitOfMagnitudeFrom: start to: stopArg
if you have updated the LargeIntegers module to v1.2 (or a VM with it). This
is also made by fileIn the InstallLargeIntegersV1.2-sr changeset.
"
--

-- 
Stephan Rudlof (sr <at> evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Way | 30 Nov 2000 00:58

Re: Making an inverted ellipse morph?


Dean Pu Mao wrote:
> 
> I'm curious if it's easily possible to make an inverted ellipse.  (It's
> like an ellipse only that the bounding rectangle is not transparent and
> the ellipse itself is transparent (and all clicks go through it)).
> 
> I could subclass EllipseMorph and make it so that the
> containsPoint: returns an opposite value so that clicks go through, but
> that still doesn't solve the drawOn: problem.  How can I make drawOn: to
> draw everything around the ellipse keeping the insides transparent?

There are a few different approaches you could try...

The brute force method would be to use the debugger to drill down to where the ellipse drawing code actually
happens.  If you halt in EllipseMorph>>drawOn:, you'll eventually get down to GrafPort>>fillOval:,
which seems to be where the action is.  You could try to copy this code (into your subclassed drawOn: method
or wherever) and modify it so that it draws outside the ellipse instead of inside.

However, there might be an easier way.  The first thought I had was, in your new drawOn: method, to first draw a
rectangle (fillRectangle:color:) in the ellipse's color, and then draw an ellipse on top of that in with
'Color transparent'.  But that doesn't work because the rectangle shows through behind the transparent ellipse.

Something that would probably work would be to use Form>>replaceColor:withColor:.  First you'd draw the
rectangle on the Form in one color, then you'd draw the ellipse in a second color, and then do a "aForm
replaceColor: secondColor withColor: Color transparent".  Then draw this Form on your canvas.  (Or,
simply get the Form from the canvas in the first place, with something like Canvas>>contentsOfArea:.)

Hopefully, this will be enough for you to go on...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Henrik Gedenryd | 13 Nov 2000 16:17
Picon
Picon

Some j3 feedback

I think this was meant for the list...

----------
From: carlg <at> world.std.com
Date: Mon, 13 Nov 2000 14:46:15 -0000
To: Henrik Gedenryd <Henrik.Gedenryd <at> lucs.lu.se>
Subject: Re: Some j3 feedback

--- In squeak <at> egroups.com, Henrik Gedenryd <Henrik.Gedenryd <at> l...>
wrote:
> I am speculating that the cache is too small. Is that possible? I
didn't
> find any way to adjust the code cache size. Would it be an idea to
use the
> regular object memory for code caching? Then any available memory
would
> benefit j3, and a low space watcher could be used to ensure that
the cache
> only used memory that isn't needed elsewhere.

Is there a cache?  I was under the impression that J3 isn't a just in
time compiler.  Doesn't the J3 simply essentially substitute machine
code for bytecodes on a per-bytecode basis as it goes?  The plugin
looks to see if a bytecode is in its case statement, and if it is it
executes machine code for it.  If a bytecode is not in the case
statement it feeds back into the regular bytecode interpreter.

Anyone care to clarify?  :-)

-Carl
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel | 16 Nov 2000 21:53
Picon

[BUG] Problem with Diff Action in ComSwiki

	Setting up a swiki here at work that might be used to document a JAVA
project, of all things... ;)

	Anyways, right now I'm hosting it on my NT box ( NT 4, SP 5 ) while the
people involved in the project play around with it and decide if it's
good or not...

	BUG:

	One page has about 27 revisions to it.

	When I click on the +/- to show the diffs, everything works fine, but
it gets progressively slower, becoming quite noticeable at rev #14, and
finally, causes the Squeak VM to go to 100% processor usage and turn
unresponsive at diff #25 ( rev 27 is the current page ). I have to shut
down the VM, and restart, since it doesn't come back to normal, even
after a few minutes. 

	Viewing the old revisions works PERFECTLY for all revisions, only
trying to view the diffs causes the problems. I took a look at the diff
code in the swiki/refs/actions directory, but couldn't see anything
nasty, like a recursive call. 

	I checked the Squeak Swiki, and found a page with 141 divisions.
Clicking on +/- for each of the revisions worked nearly instantly, with
no slowdon appearent for even the latest revs. 

	Does it use a different version of the DIFF code? Or does it just have
more ram? I will test tomorrow with more ram allocated to the JVM to see
if that helps...
(Continue reading)

Permalink | Reply | 1 comment |

Gmane