How about Mouse? ;-) Or Cheese? S
On Monday, January 26, 1998 11:34 AM, Paul Fernhout [SMTP:kfsoft@netins.net] wrote:
Tim Rowledge wrote:
Actually, I'd suggest it might be useful to indirect ALL calls to
'outside' apis, so that the platform specific code can cleanly intercept any that might not be suitable; there aren't many so it wouldn't be too onerous. Let's see, malloc,
fread, frite, fseek, fopen, fclose, math stuff.... that's about it.
The easy way would be to have the SQ code refer to some munged name and to use macro definitions to make use of the 'normal' calls where acceptable.
Thus we could easily intercept all the file handling but leave macros
for exp, floor, sin etc.
I second this.
When dealing with code for the Newton, which doesn't support files, this is a source of complexity. For the most part, it isn't that bad. But there is one place in the VM when it starts up where the shell creates a file handle and passes it to the VM (for reading the image) which created the worst difficulty. That is one place that Squeak does not use its own file primitives and the workaround is ugly.
It would help if there was a test program written in C that exercised the Squeak shell code. The test program woudl be much smaller than Squeak itself - like one hundred lines of code or so. That way a port could focus on getting a shell to work first.
That test case could be as simple as: Draw a diagonal line, respond to a mouse down or key by drawing another line, play a sound, and maybe read a file. These could be individual tests or run together based on compiler flags. One could progress in some arbitrary order - like first get the bitmap to work, then get keyboard, then the mouse, then files, then TCPIP, then sounds. There could be feedback provided at each stage by the test program.
On a related issue, there is much value in having a machine independent GUI shell that collects keystrokes, tracks the mouse, interacts with file like streams, displays bitmaps, does TCP/IP, and plays and records sounds. With a little restructuring, the Squeak shell could turn into a beautiful machine independent framework on top of which *anything* could be placed. This might entail a slight performance hit depending on how nternal Squeak data structures like strings were passed to the shell.
For example, if a group wanted to make a portable version of Python with TK widgets, they could just put it on top of the Squeak shell platform.
This would potentially bring a lot more people into the machine independent Squeak shell API fold. Even though they wouldn't have much to say about Squeak, they might have an interest in porting the Squeak shell to new platforms for their own reasons, and then Squeak could follow. It might also multiply the number of people interested in sharing the work of maintaining and debugging existing Squeak shell ports.
Maybe if the Squeak low level API had a name it would be treated more like a thing on its own. Anyone with a catchy name for the Squeak shell and related API? Conch? Squeak API? Squeak Happy? The Nest? Squeal? Low Squeak? Rumble?
-Paul Fernhout Kurtz-Fernhout Software =========================================================== Developers of custom software and educational simulations Download our Garden Simulator for Windows & source from: http://www.gardenwithinsight.com
squeak-dev@lists.squeakfoundation.org