Squeak-dev March 1998

squeak-dev@lists.squeakfoundation.org

67 participants
130 discussions

{ } also for VisualWorks?
by Stefan Matthias Aust 20 Mar '98

20 Mar '98

Hi! Squeak has a special { } notation for constructing array objects. I wonder whether somebody has implemented the same for VisualWorks already. I'd like to be able to port some squeaky code to VW. Thanks, bye -- Stefan Matthias Aust // Ride on - through the night - ride on

1 0

Re: headless vm changes suggestions
by Andreas Raab 20 Mar '98

20 Mar '98

> > Did you try any networking code? It depends on having a window for async > > notification of what is happening. > You're kidding, right? This is an early April Fool's joke? Nope. It's still march. I've never looked deeper into the async notfications - there may be ways such that we don't have to use it (actually I'm quite sure because several NT services use them as well). But at the moment you'll probably get a lot of strange results from it. > Oh boy, well if you gotta hava window then you gotta hava window, but > I guess it can be made invisible and not counted as being there until > a beDisplay is done. Blech. Oh boy, stop whining! I'll have a look at it once I got a spare minute left ... well if anyone out there knows how to do async network notifications without a window let me know. Andreas -- Linear algebra is your friend - Trigonometry is your enemy. +===== Andreas Raab ============= (raab(a)isg.cs.uni-magdeburg.de) =====+ I Department of Simulation and Graphics Phone: +49 391 671 8065 I I University of Magdeburg, Germany Fax: +49 391 671 1164 I +=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+

2 1

#raisedToInteger:
by sqrmax＠cvtci.com.ar 20 Mar '98

20 Mar '98

Hi. I've found that Fraction instances doesn't understand #raisedToInteger:. This results in senseless #gcd: and so, then here's the fix (for 1.23). Maybe it's already fixed, but maybe not. Andres. Content-Type: application/octet-stream; name="Fractio1.st" Content-Disposition: attachment; Filename="Fractio1.st" Attachment converted: Cog:Fractio1.st (????/----) (0000C922)

1 0

headless vm changes suggestions
by Tim Rowledge 20 Mar '98

20 Mar '98

I've made a simple set of changes that make doing headless squeak much simpler and which might interest you folks. John & I have discussed it a bit previously and he seems to quite like it. The most obvious glitch when trying to do a headless run of squeak is that the window is created and opened by the vm before the image is started up. Thus there is no easy way to have a headless image without a vm that can understand not having a display. Ian has put a bunch if #ifdefs in his window stuff to do this. Obviously there are a load of other issues such as the communication to some other image/machine for debugging etc, but that's for another day! I spotted the posibility of a neater way to do this as a side effect of having to change the beDisplay prim to support the Acorn display. I have to call a function in the window.c file to fake out the dispaly bitmap being outside object space, and noticed that it would be a really good place to move the SetupWindow/SetWindowSize etc work. That way, it is only when beDisplay is called that the window need be created and now the image can have complete control over whether a window is used. The VM changes are very small:- - primitiveBeDisplay needs to call some outside function. For my needs I use ioSetDisplayBitmap(int displayObj, int suggestedSize, int w, int h, int d) where the arguments are the Display oop, the suggested size of the bitmap in bytes, the width, height and depth. This seems a reasonably comprehensive set of information that might be useful, since we can actually specify the window size directly rather than it always being a defaulted size. It also sets a flag value to indicate that the window exists and avoids redoing it. If the window is already open to a different size, it ought to resize the window programmatically. - main() loses the Setupwindow etc calls and they move into the ioSetDisplayBitmap function. - ioScreenSize() checks the above mentioned flag and returns the open window's size or the savedWindowSize as appropriate. The image changes are simple as well:- the startup sequence has to be fiddled a little, since we need to check to see if the image wants to run headless very early on; I used the existence of a file called 'beheadless' asa trivial test. I suggest that using one of the vm attribute ids might be useful, since that could be tied to the vm build. Obviously, image code could use a variety of tests with no trouble. Since a headless image won't want a display or cursor or source code (probably) we can branch away from starting them up if running headless and go to some other branch that filesin some code or simply hardcodes some work. Clearly there would be more complicated work to do to handle notifiers when running headless, but one thing at a time. If you're interested, I can offer up the code; I'll happily do the C code edits for you as well if you're interested but short on time. I can test W95 (in fact I have indirectly got it running anyway) and Mac but I have no unix machine available to test. tim -- Useful random insult:- Enjoys listening to telemarketers. Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 856-7230 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

2 1

Re: headless vm changes suggestions
by Ian Piumarta 20 Mar '98

20 Mar '98

Tim, > Thus there is no easy way to have a headless image without a vm that > can understand not having a display. Ian has put a bunch if #ifdefs in > his window stuff to do this. Credit where it's due: Georg Gollmann did the "ritual sprinkling" of the #ifdefs for the headless version. (And a damn fine job too: after two [three?] revisions of the support code [including the X shared memory extensions] since the last time I tried, I compiled with -DHEADLESS the other day and it worked first time! :) Regards, Ian

1 0

Acorn 1.31 release finally out there
by Tim Rowledge 19 Mar '98

19 Mar '98

I know that up to any number of you have been waiting with bated breath (can you have UN-bated breath?) for the availability of 1.31 for the Acorn RPC. Well, bate no more, 'cos it's here. Web your way across to <http://sumeru.stanford.edu/tim> and follow the obvious pointers and download yourself some happiness. I made two versions this time, one as normal and one without the VM code, saving a couple of meg of disc space a nd a bit of download time. I didn't release the jitter vm, since we haven't quite worked out where the funny performance figures come from. Bouquets and brickbats to the usual addresses... tim -- Useful random insult:- Runs squares around the competition. Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 856-7230 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

1 0

Re: General comment on Cheese and prior work in this area
by wirth＠almaden.ibm.com 19 Mar '98

19 Mar '98

Nope, not Garnet (done by Brad Myers and students at CMU), which has now been ported to C++ and is called "Amulet". I say "ported to C++" with a smile, because they implemented a dynamic, prototype object model on top of C++, so they could get the flexibility they wanted. BTW, I always thought Garnet had an interesting approach, with its separation of an information system into a "model" (which modeled the real world), multiple "views", and coordination through "active variables", an interesting variation on MVC. The framework I'm thinking about was done by the Boston Lisp crowd (BBN? MIT?) and had a name like... hmm.... was it "CLIM"?. Mike Wirth stp(a)limbo.create.ucsb.edu (Stephen Travis Pope) on 03/18/98 04:01:54 AM Please respond to stp(a)limbo.create.ucsb.edu To: squeak(a)cs.uiuc.edu cc: usib6tfj(a)pol.ru, wirth(a)almaden.ibm.com Subject: Re: General comment on Cheese and prior work in this area I believe that Mike's thinking of the "Garnet" package for CommonLisp, which was large and complicated and not all that platform independent anyway. (I once tried to port a "portable" Garnet package from SGI to the Mac, oh boy...) If anyone's looking for a set of potential graphics and window primitives for platform-independent GUIs, why not look at VisualWorks for ideas? stp _ Stephen Travis Pope _ Center for Research in Electronic Art Technology (CREATE) _ Department of Music, Univ. of California, Santa Barbara (UCSB) _ stp(a)create.ucsb.edu, http://www.create.ucsb.edu/~stp/

2 1

"Minimal" MIDI Primitive Interface
by stp＠limbo.create.ucsb.edu 19 Mar '98

19 Mar '98

Hi John, Dan, Dan, and Sam (et al.)! With reference to our discussion of a "minimal standard" set of MIDI I/O primtitves for Squeak, here's a revised proposal. I have the driver 90% rewritten to implement this interface. I'm pretty sure that the "full complement" of Siren primitives can be made to be a proper superset of this. Your comments are invited... stp -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- /*********************************************************************************** * Header File for the Squeak Interface to MIDI * Stephen T. Pope -- stp(a)create.ucsb.edu -- 1998.03.18 * * Version 1.31d -- New "Minimal" Primitive Interface * * This file should be "platform-independent" (yeah, right). * * Note: Most of the primitives fail only under extreme conditions, and return * large positive results for "normal" failure. A return value of 0 means "success" * or "true." */ /*********************************************************************************** * External MIDI interface function prototypes (Smalltalk primitives) */ // Open/start the MIDI interface. (Prim. 610) Answer the // number of interfaces found, or 0 if already open. // 'callbackSemaphore' is the index of the read semaphore // 'readSocket' is the socket to read from; writeSocket will // be 1 greater in value. int sqOpenMIDI(int callbackSemaphore, int readSocket); int sqCloseMIDI(void); // Close the MIDI interface (611) // Get the name of a MIDI device (612) // 'name' is interpreted as (char *); // 'index' is a 1-based table index. int sqGetMIDIDeviceName(int index, int name); // Send data out the default port now (613) // 'message' is interpreted as (unsigned char *) // 'interface' is the number of a device. int sqMIDIPlaySizeOn(int message, int length, int interface); // Read input into a MIDI packet (614) // 'buffer' is interpreted as (MIDIPacket *) // Answer the number of data bytes. int sqReadMIDIPacket(int packet); // Answer the last-read value of the selected MIDI controller // (assuming controller value caching is turned on). (615) // 0-127 are normal controllers, 128-255 are key pressures // 256-271 are channel pressures, 272 is pitchBend int sqReadMIDIControl(int which); // General-purpose MIDI driver query/set call (like UNIX // device driver ioctl() calls). See the flag definitions // below. (616) // 'which' selects the operation; // 'onOff' is a flag for query/set/clear operations // Answer the result (true/false, or a number) int sqMIDIioctl(int which, int onOff); /*********************************************************************************** The Smalltalk side looks like: (610 primitiveOpenMIDI) (611 primitiveCloseMIDI) (612 primitiveGetMIDIDeviceName) (613 primitivePutMIDIOn) (614 primitiveReadMIDIPacket) (615 primitiveReadMIDIControl) (616 primitiveMIDIioctl) ***********************************************************************************/ /*********************************************************************************** * MIDI Driver ioctl flags */ #define sqMIDIInstalled 1 // Is a MIDI driver installed? #define sqMIDIVersion 2 // What driver version is this? #define sqMIDIHasBuffer 3 // Is there a time-stamped output buffer? #define sqMIDIHasDurs 4 // Is there a 1-call note command? #define sqMIDIHasClock 5 // Does the driver have its own clock? #define sqMIDIUseSemaphore 6 // Should the driver signal a semaphore in input? #define sqMIDIEcho 7 // Should we echo in-coming events in the driver? #define sqMIDIControllerCache 8 // Should we cache controller values for polling? #define sqMIDIEventsAvailable 9 // How many events are in the input Q? #define sqMIDIQuery 0 // Query about the state of a feature #define sqMIDITurnOn 1 // Turn it on #define sqMIDITurnOff 2 // Turn it off /*********************************************************************************** * E N D */ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _ Stephen Travis Pope _ Center for Research in Electronic Art Technology (CREATE) _ Department of Music, Univ. of California, Santa Barbara (UCSB) _ stp(a)create.ucsb.edu, http://www.create.ucsb.edu/~stp/

1 0

Re: General comment on Cheese and prior work in this area
by wirth＠almaden.ibm.com 18 Mar '98

18 Mar '98

Wow! Thanks, Les. Like Casey Stengel said: "It's deja vu all over again". In the '88-'92 timeframe I directed a group that built yet another graphical UI toolkit in CLOS as part of a GIS for the oil patch, called "Sorcerer's Apprentice". We looked at most of the systems your message mentioned. I guess my subconsious was just blocking out that information :-) Now the critical question is: Can people who worked with those systems recall the "lessons learned" and describe them here for Boris' benefit in his design of Cheese? Mike PS: I love the web. A quick search in the "subject" categories in Alta Vista led directly to a bunch of CLIM info, including: A new research project on "CLIM 3.0": http://www.darpa.mil/ito/Summaries97/D935_0.html The CLIM 2.0 user's guide: http://www.harlequin.com/education/books/CLIM-2.0/ <---- Boris, you probably want to take a look at this. Les Tyrrell <tyrrell(a)canis.uiuc.edu> on 03/18/98 01:24:32 PM Please respond to Les Tyrrell <tyrrell(a)canis.uiuc.edu> To: squeak(a)cs.uiuc.edu cc: Subject: [LONG] Re: General comment on Cheese and prior work in this area The following is from: http://mx.nsu.ru/FAQ/F-lisp/Q1-7.html It mentions CLIM and a few others... this should jog your memory! les ------------- Begin Included Message ------------- <Info on CLIM, CLX, CLUE, WINTERP, CLM, GINA, etc.>

1 0

[LONG] Re: General comment on Cheese and prior work in this area
by Les Tyrrell 18 Mar '98

18 Mar '98

The following is from: http://mx.nsu.ru/FAQ/F-lisp/Q1-7.html It mentions CLIM and a few others... this should jog your memory! les ------------- Begin Included Message ------------- How can I use the X Window System or other GUIs from Lisp? There are several GUI's and Lisp interfaces to the X Window System. Mailing lists for these systems are listed in the answer to question [4-7]. Various vendors also offer their own interface-building packages. CLX provides basic Common Lisp/X functionality. It is a de facto standard low-level interface to X, providing equivalent functionality to XLib, but in Lisp. It is also a good source for comparing the foreign function calls in various Lisps. Does *not* depend on CLOS. Available free as part of the X release in the contrib directory. Also available by anonymous ftp from ftp.x.org:/R5contrib/ as the files CLX.Manual.tar.Z and CLX.R5.02.tar.Z. [Note: The new version of CLX for X11R6 can be found (untarred) in ftp.x.org:/pub/R6.1/contrib/lib/CLX/ with documentation in ftp.x.org:/pub/R6.1/contrib/doc/CLX/ and includes some slight modifications for CLtL2 compatability. You can get it in tarred form from the CMU AI Repository, Lisp section.] Primary Interface Author: Robert W. Scheifler Send bug reports to bug-clx(a)expo.lcs.mit.edu. The 232 page manual is available in /pub/R5untarred/mit/hardcopy/CLX (PostScript format) and /pub/R5untarred/mit/doc/CLX (Interleaf source). CLIM (Common Lisp Interface Manager) is a portable, graphical user interface toolkit originally developed by International Lisp Associates, Symbolics, and Xerox PARC, and now under joint development by several Lisp vendors, including Symbolics, Franz, Lucid, Illudium, and Harlequin. It is intended to be a portable successor of Symbolics UIMS (Dynamic Windows, Presentations Types). CLIM 2.0 also supports more traditional toolkit-style programming. It runs on Symbolics Lisp Machines; Allegro, Lucid, and Harlequin on several Unix platforms; Symbolics CLOE on 386/486 IBM PCs running Windows; and MCL on Apple Macintoshes. It is *not* free, and with the exception of Macintoshes, if it is available it can be purchased from the vendor of the Lisp system you are using. For the Macintosh version write to Illudium: Contact: Dennis Doughty - Doughty(a)ileaf.com or contact: Bill York - york(a)parc.xerox.com Illidium has signed a distribution agreement for MCL CLIM with Lucid. [Contact Harlequin for information about Lucid.] CLIM includes a general purpose grapher. The CLIM 2.0 SPECIFICATION is available by anonymous ftp from ftp.franz.com:/pub/clim/clim.ps.Z. To be added to the mailing list send mail to clim-request(a)bbn.com. CLUE (Common Lisp User-Interface Environment) is from TI, and extends CLX to provide a simple, object-oriented toolkit (like Xt) library that uses CLOS. Provides basic window classes, some stream I/O facilities, and a few other utilities. Still pretty low level (it's a toolkit, not widget library). Available free by anonymous ftp from csc.ti.com:/pub/clue.tar.Z Written by Kerry Kimbrough. Send bug reports to clue-bugs(a)dsg.csc.ti.com. CLIO (Common Lisp Interactive Objects) is a GUI from the people who created CLUE. It provides a set of CLOS classes that represent the standard components of an object-oriented user interface -- such as text, menus, buttons, scroller, and dialogs. It is included as part of the CLUE distribution, along with some packages that use it, both sample and real. Allegro Common Windows provides a front end to CLX. Uses CLOS. It is *not* free. Contact info(a)franz.com for more information. [Intellicorp's KEE4.0 comes with Common Windows also. They've implemented the CW spec to run on Lucid 4.0 on Sparcs, HP300/400s, HP700/800s, and IBM RS6000s. Contact tait(a)intellicorp.com for more information.] The LispWorks Toolkit is an extensible CLOS-based widget set that uses CLX and CLUE. The LispWorks programming environment has been written using the toolkit and includes: an Emacs-like editor, listener, debugger, profiler, and operating system shell; browsers/graphers for classes, generic functions, processes, windows, files, compilation errors, source code systems, and setting LispWorks parameters; and an interactive interface builder and complete online hypertext documentation. Contact: lispworks-request(a)harlqn.co.uk CLM (Common Lisp Motif) and GINA (Generic Interactive Application) and IB (Interface Builder). CLM runs Motif widgets in a separate C process, with minimal work on the Lisp side and communicates between C and Lisp using TCP sockets. Runs in Allegro CL, Sun CL, CMU CL, Lucid CL, and Symbolics Genera. GINA uses CLOS. Available free in the X contrib directory or by anonymous ftp from either ftp.x.org:/contrib (formerly export.lcs.mit.edu) or ftp.gmd.de:/gmd/gina [129.26.8.84] as the files CLM+GINA.README, CLM2.2.tar.Z and GINA2.2.tar.Z. CLM was written by Andreas Baecker , GINA by Mike Spenke , and IB by Thomas Berlage . Contact Mike Spenke for more info. To be added to the mailing list, send a message to gina-users-request(a)gmd.de. EW (Express Windows) is intended to mimic Symbolics' Dynamic Windows user and programmer interfaces. It is available free in the Common Lisp Repository as ftp.cs.cmu.edu:/user/ai/lang/lisp/gui/ew/ It is no longer under active development. Runs on Sun/Lucid, Franz Allegro, and Symbolics. Should port easily to other Lisps with CLX. Written by Andrew L. Ressler . Garnet is a large and flexible GUI. Lots of high-level features. Does *not* depend on CLOS, but does depend on CLX. Garnet (version 2.0 and after) is now in the public domain, and has no licensing restrictions, so it is available to all foreign sites and for commercial uses. Detailed instructions for obtaining it by anonymous ftp are available by anonymous ftp as a.gp.cs.cmu.edu:/usr/garnet/garnet/README [128.2.242.7] Garnet includes the Lapidiary interactive design tool, C32 constraint editor, spreadsheet object, Gilt Interface Builder, automatic display management, two widget sets (Motif look-and-feel and Garnet look-and-feel), support for gesture recognition, and automatic constraint maintenance, application data layout and PostScript generation. Runs in virtually any Common Lisp environment, including Allegro, Lucid, CMU, and Harlequin Common Lisps on Sun, DEC, HP, Apollo, IBM 6000, and many other machines. Garnet helps implement highly-interactive, graphical, direct manipulation programs for X/11 in Common Lisp. Typical applications include: drawing programs similar to Macintosh MacDraw, user interfaces for expert systems and other AI applications, box and arrow diagram editors, graphical programming languages, game user interfaces, simulation and process monitoring programs, user interface construction tools, CAD/CAM programs, etc. Contact Brad Myers (bam(a)a.gp.cs.cmu.edu) for more information. Bug reports should be sent to garnet-bugs(a)cs.cmu.edu. Administrative questions should be sent to garnet(a)cs.cmu.edu or garnet-request(a)cs.cmu.edu. Garnet is discussed on the newsgroup comp.windows.garnet (which is gatewayed to garnet-users(a)cs.cmu.edu for those without access to netnews). LISP2WISH is a very simple demonstration of how to connect and communicate SYNCHRONOUSLY between a lisp process and a C process running a Tcl/Tk executable. The demo uses the vanilla 'wish' executable that is included with the Tcl/Tk distribution. Tcl/Tk is a very flexible system for building Graphical User Interfaces (GUIs), with the look-and-feel of Motif. One writes scripts in a high-level, C-like language, and an interpreter evaluates the commands and passes execution either to a built-in function (and there are many), or to your own C routines. Tcl/Tk is becoming increasingly popular because of its ease of use, and because it is freely distributable (even commercially, I believe). For more information on Tcl/Tk, look on the USENET newsgroup comp.lang.tcl, or get the distribution from the archive (listed below) or ftp.cs.berkeley.edu. The Tcl/Tk archive also has many user-contributed extensions which make Tcl/Tk even more desirable. Tcl/Tk was originally written by Dr. John Ousterhout, at Berkeley. LISP2WISH lets you make a window/menu/drawing interface for your lisp routines, where you can take advantage of all the stuff written for Tcl/Tk (and build your own!). LISP2WISH has only been tested under X-Windows and Lucid Common Lisp 4.0 and 4.1, but should work on other platforms that support Lucid (or Allegro) and Tcl/Tk. LISP2WISH is available at the Tcl/Tk archive harbor.ecn.purdue.edu:/pub/tcl/lisp2wish6.tar.gz, from the author through the WWW at the URL http://www.cis.upenn.edu/~kaye/home.html by anonymous ftp from ftp.cis.upenn.edu:/pub/kaye/lisp2wish6.tar.Z or in the GUI section of the Lisp Repository as ftp.cs.cmu.edu:/user/ai/lang/lisp/gui/lsp2wish/lsp2wish.tgz For more information, contact Jonathan Kaye . LispView is a GUI written at Sun that does not use CLX. Instead it converts Xlib.h directly into Lucid foreign function calls. It is intended to be fast and tight. Uses CLOS. Available for anonymous ftp from ftp.x.org:/contrib/lispview1.1 (formerly export.lcs.mit.edu) and xview.ucdavis.edu:/pub/XView/LispView1.1 Includes a general-purpose 2D grapher library. Written by Hans Muller (hmuller(a)sun.com). Runs in Sun CL and Lucid CL. Direct questions about the source provision to lispview(a)Eng.Sun.Com. WINTERP (Widget INTERPreter) is an application development environment developed at HP. It enables the rapid prototyping of graphical user-interfaces through direct manipulation of user interface objects and their attached actions. WINTERP provides an interface to the X11 toolkit (Xt) and the OSF/Motif widget set and a built-in RPC mechanism for inter-application communication. It includes an object-oriented 2.5D graphics and animation widget based on the Xtango path transition animation system, the XmGraph graph browser (with graph nodes as arbitrary WINTERP widgets), and GIF image support. The interpreter is based on David Betz's XLISP interpreter, which implements a small subset of Common Lisp and runs on PCs, IBM RS/6000, Decstation 3100s, HP9000s, Sun3, Sparcs, SGI, and NeXT. XLISP provides a simple Smalltalk-like object system, with OSF/Motif widgets as real XLISP objects -- they can be specialized via subclassing, methods added or altered, etc. WINTERP includes an interface to GNU-Emacs which allows code to be developed and tested without leaving the editor. WINTERP is a free-standing Lisp-based tool for setting up window applications. WINTERP is available free in X contrib directory, or by anonymous ftp from ftp.x.org:/contrib/devel_tools/ as winterp-???.tar.gz (formerly export.lcs.mit.edu) where ??? is the version number. The current version is 2.03 (X11r6 support). If you do not have Internet access you may request the source code to be mailed to you by sending a message to winterp-source(a)netcom.com. The WWW home page for WINTERP is accessible via the URL http://www.eit.com/software/winterp/winterp.html or mirrored on file://ftp.x.org/contrib/devel_tools/winterp.html Contact Niels Mayer for more information. To be added to the mailing list, send mail to winterp-request(a)netcom.com. Xgcl provides an interface to X Windows for GCL (GNU Common Lisp), formerly Austin Kyoto Common Lisp (AKCL). It includes a low-level interface to the Xlib routines, and an interface that provides graphics, menus, and mouse interaction via functions that are called from Lisp. Xgcl is built on top of GCL, and it is somewhat larger (e.g. 6.7 MB for Xgcl vs. 4.9 MB for GCL) because it incorporates Xlib. To make Xgcl, you must first obtain and make GCL. The code was written by Gordon Novak, Hiep Nguyen, and William Schelter. Xgcl is available by anonymous FTP from math.utexas.edu:/pub/gcl/ ftp.cli.com:/pub/gcl/ ftp.cs.utexas.edu:/pub/novak/xgcl/ and on the Web from http://www.cs.utexas.edu/users/novak as the file xgcl-2.tgz. To use, put the xgcl-2.tgz file in the same directory as gcl-1.1.tgz and uncompress it with gzip -dc xgcl-2.tgz | tar xvf - Then see the README in the directory xgcl-2. For more information, write to Gordon Shaw Novak, Jr. . YYonX is a port of the YY system to X windows. Runs in Lucid CL, Allegro CL, and Symbolics Genera. Supports kanjii. Developed at Aoyama Gakuin University. Available free by anonymous ftp from ftp.csrl.aoyama.ac.jp:/YY/ Written by Masayuki Ida Picasso is a CLOS based GUI, and is available from postgres.berkeley.edu:/pub/Picasso-2.0 toe.cs.berkeley.edu:/pub/picasso/ It runs on DecStation 3100s, Sun3 (SunOs), Sun4 (Sparc), and Sequent Symmetry in Allegro CL. The file pub/xcl.tar.Z contains X-Common Lisp interface routines. Send mail to picasso(a)postgres.berkeley.edu for more information. [Picasso is no longer an actively supported system.] XIT (X User Interface Toolkit) is an object-oriented user interface development environment for the X Window System based on Common Lisp, CLOS, CLX, and CLUE. It has been developed by the Research Group DRUID at the Department of Computer Science of the University of Stuttgart (druid(a)informatik.uni-stuttgart.de) as a framework for Common Lisp/CLOS applications with graphical user interfaces for the X Window System. XIT contains user interface toolkits, including general building blocks and mechanisms for building arbitrary user interface elements and a set of predefined common elements (widgets), as well as high-level interactive tools for constructing, inspecting, and modifying user interfaces by means of direct manipulation. Although the system kernel is quite stable, XIT is still under active development. XIT can be obtained free by anonymous ftp from ftp.informatik.uni-stuttgart.de:/pub/xit/ [129.69.211.2] ------------- End Included Message -------------

1 0

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