From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 24 Nov 93 15:13:23 EST Subject: Linux-Development Digest #257 Linux-Development Digest #257, Volume #1 Wed, 24 Nov 93 15:13:23 EST Contents: Re: Don't use Motif for free sw: it now requires runtime royalties! (Nhi Vanye) Re: Where are these gcc-libraries ? (H.J. Lu) Pentium GCC compiler ( Re: How many BogoMips on a Pentium?) (H.J. Lu) Comments from the "TAMU Crap" author (Dave Safford) Re: 1542B and DSP3160 bad I/O Performance (Rob Janssen) Re: Linux and Notebook Hotkeys (Rob Janssen) Re: Bug Report (.99.13q) (Rob Janssen) Re: olvwm for linux? (Dr Eberhard W Lisse) Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? (Amancio Hasty Jr) ---------------------------------------------------------------------------- Crossposted-To: comp.sources.d,comp.windows.x,gnu.misc.discuss,comp.windows.x.motif,comp.windows.x.i386unix,comp.infosystems.www From: offer@robots.ox.ac.uk (Nhi Vanye) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Wed, 24 Nov 1993 16:42:08 GMT I mailed MetroLink about this thread and got the following reply :- > There has been a large number of statements on comp.os.linux.* > regarding motif licensing, as I purchased a copy from you in august > (to run under linux) with the aim of porting all my code to linux I am > somewhat worried that I will now not be able to distribute (static) > binaries . Would you care to issue a statement ? > > Yours hopefully. > > Richard Offer. Richard -- As we understand it from OSF, you are allowed to compile your programs STATICALLY and restribute them without worry of royalty payments. If you have any further questions, please mail 'tech@metrolink.com'. They can provide you with additional help if you need it. Thanks! -ken Ken Maier Metro Link Inc. richard. ------------------------------ From: hjl@nynexst.com (H.J. Lu) Subject: Re: Where are these gcc-libraries ? Date: Wed, 24 Nov 93 17:17:35 GMT In article <2cfb1g$9m8@unidus.rz.uni-duesseldorf.de>, engels@darkstar () writes: |> [ Article crossposted from comp.os.linux.help ] |> [ Author was engels@darkstar ] |> [ Posted on 18 Nov 1993 08:15:06 GMT ] |> |> I tried to compile xvtdl5.0 with gcc using Linux (Slackware 1.10). I |> could solve some problems concerning the compilation, but now I can't |> solve a linking problem (I'm relatively new to Linux and gcc). |> |> The linker doesn't find the libraries libl and libintl. If I remove |> these libraries from the gcc-line, the linker can't find _compile and |> _step. The lines in the C-source seems to be |> |> (void) compile(regex_str, regex_buf, ®ex_buf[MAXPATHLEN], '\0') |> |> and |> |> step(s, regex_buf) |> |> s is a char* and step is defined as int. |> |> So my question is: where can I find these libraries or are these functions |> in other libraries ? |> |> Btw: the compiler couldn't find regexp.h, so I replaced it with regex.h. |> Maybe that's a clue. |> |> Btw2: I know that I can find xvtdl at sunsite, but I got a segmentation |> fault with that version. |> |> Thanks for any hints |> It will be in libc 4.4.x or 4.5.x. H.J. |> engelsg@uni-duesseldorf.de |> |> ------------------------------ From: hjl@nynexst.com (H.J. Lu) Subject: Pentium GCC compiler ( Re: How many BogoMips on a Pentium?) Date: Wed, 24 Nov 93 17:11:02 GMT In article , stock@dutsh7.tudelft.nl (Robert Stockmann) writes: [...] |> But of course no shame to linus, because at the moment there's even |> no commercial OS on the market that boost's the power of the pentium. |> So we just have to wait for the 100 MHz version to get 51.5 or something |> like that reported as the new record. |> |> Robert stockmann Since Intel will release/has released the infamous appendix H for Pentium, I won't be surprised to see GCC generate Pentium code. Then you can recompile everything for Pentium, including the kernel. But we have to a Pentium assembler first. H.J. P.S. Please don't send me emails. That is all I know. ------------------------------ From: drs0587@net.tamu.edu (Dave Safford) Subject: Comments from the "TAMU Crap" author Date: 24 Nov 1993 17:57:37 GMT Reply-To: drs0587@net.tamu.edu Dirk Hohndel has recently posted several attacks on the use of my TAMU Xconfig.1M configuration file. I believe quite strongly that his arguments are flawed, and a disservice to the linux community. The fact that he voiced them with inflammatory terms such "Crap", and "stupid" is inappropriate for serious newsgroups such as comp.os.linux.announce. Let's leave such behavior to the alt newsgroups please. (All my such usage is valid quoting of his initial post :-) I have spent the last week tracking down real facts on some of his allegations. I am sick and tired of the "I heard that someone had problems ..." line of argument, and everything I am about to relate comes from directly verified experience of actual linux users, not rumours or possible recollections. Here is a summary of his COMPLAINT: To summarize his technical argument, he believes that Xconfig.1M is dangerous because: 1. during configuration it can run the monitor temporarily at unsuitable (damaging) frequencies. 2. even when a stable looking mode is found, the frequency can still be unsuitable (damaging) for the monitor. Based on these technical arguments, he then argues that Xconfig.1M should NEVER be used, and that the only safe way to configure is to "Read the docs, try to find your monitor in /usr/X386/lib/X11/etc/modeDB.txt" Here are some FACTS: 1. Xconfig.1M has been in extensive use for around 2 years, both at Texas A&M University, and many other sites. 2. I have received numerous letters from highly satisfied users of Xconfig.1M, who have found it "infinitely easier" than the manual configuration methods. 3. In many cases I have been absolutely unable to do the manual calculations, as accurate technical information is NOT AVAILABLE. (We get a lot of no name clones here -- the joys of purchasing from the low bidder). When I received my latest and greatest Austin notebook, I couldn't even find out what chipset was used (turned out to be a wd90c31), let alone any detailed technical data. 4. In several cases, Xconfig.1M has found superior, and verified safe, modes compared to the entries in the approved database. Why? The manual calculations are time consuming, and many people stop when they find any usable display, not knowing that better configurations are possible. 5. Xconfig.1M (and its little brother Xconfig.512K) are absolutely appropriate for LCD displays, (which last time I checked do NOT have flyback transformer based power supplies :-) 6. I have found NO confirmed instances of monitor damage during configuration with Xconfig.1M 7. I did find ONE confirmed case of damage to a monitor due to running in a stable looking mode discovered by Xconfig.1M 8. I did find ONE confirmed case of damage to a monitor due to running in a stable looking mode calculated by the "authorized" manual method. (Apparently the monitor's manual had inaccurate data -- surprise) Here are my CONCLUSIONS based on the facts: 1. Using Dirk's logic, since both the manual and Xconfig.1M methods have caused damage to monitors, they are BOTH dangerous "crap", and must be avoided. Guess we can't use XFree any more. Bummer. Guess I can't drive, fly, or even cross the street, as I could get hurt. There are no absolutely safe things in life. The real question lies in the profit/risk analysis. For Xconfig.1M, I have heard a lot of compliments, and some risk. For manual configuration I have heard a lot of complaints, and some risk. Dirk would dictate to you which choice to make. I think individuals should be given the best facts available, and then be able to decide for themselves. Personally, if I have a new high res multisync monitor, I run Xconfig.1M. 2. The Xconfig.1M does need some method to guard against good looking modes that have clocks bad for the monitor. Okay, then let's fix it, rather than dismiss it out of hand. What arrogance. At least Patrick Volkerding offered some constructive ideas in this regard. 3. Methods to automate the configuration process, even when technical data is unavailable, are very important to general use of linux. Not everyone is an XFree guru, able to do the dot calculations in his sleep. I have a phd in computer science, and even I managed to scramble more than one screen during manual configuration attempts. Perhaps it is time to look at BSDI's X configuration program as a model. Perhaps we can roll in an automated dot clock calculator with a friendly front end. Perhaps we can use a sanity checked scanning system like Xconfig.1M, but with clock checking. None of these ideas are that hard to do, and the result would be a real boon to the general user. Dirk's attitude shows terrible disdain for the non-guru community. 4. The real "crap" in my opinion is the belief that the existing manual configuration system is either usable or entirely safe. OK, for all the reasonable linux developers/users out there, how about some constructive ideas on how to improve X configuration? dave safford ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: 1542B and DSP3160 bad I/O Performance Date: Wed, 24 Nov 1993 16:04:43 GMT In pcg@aber.ac.uk (Piercarlo Grandi) writes: >>>> On Tue, 23 Nov 1993 15:45:20 GMT, rob@pe1chl.ampr.org (Rob Janssen) >>>> said: >Rob> Look in the .../BETA/scsi directory on most mirrors to find recent >Rob> things. Eric Youngdale has, after I started the discussion for >Rob> what was probably the 25th time, done some real research on this >Rob> and has constructed some patches to improve the transfer block size >Rob> by clustering. >Eric Youngdale has done some real coding; the real research was done >well over thirty years ago. It was (re)discussed recently in >comp.arch.storage. Do you want a repost of that thread? (I am going to >get it from my home archive for some guy who wants a copy...). Well, I did not mean to say that Eric did the research on clustering in general. I heard that IDE drives were faster than what I found for my SCSI drive under Linux, and my setup was a lot faster under DOS as well. Therefore, I asked if there could be a problem with the SCSI drivers on Linux. That turned out to be a FAQ, and Eric had written a benchmark program that proved (by reading large chunks directly through the driver) that the driver was not the performance bottleneck. Apparently not satisfied with that, he proceeded to research the case, and found that because of unfortunate memory allocation effects, the driver was always asked to transfer (one or more) 1K blocks, even when full 4K blocks were being read to memory. He fixed that, and the performance increased notably. Forgive me if the term "research" to find the cause of a problem with a running system is inappropriate, and is associated with "fundamental research" only. What would be the English term to use instead? I can hardly think it is called "coding", I would assume that is the term for implementing the changes that improve things after you have done "research". Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | | e-mail: pe1chl@rabo.nl | Tel. BBS: +31-30715610 (23:00-07:30 LT) | ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Linux and Notebook Hotkeys Date: Wed, 24 Nov 1993 16:09:34 GMT In dmeggins@aix1.uottawa.ca (David Megginson) writes: >I am currently running Linux 99.12 on an MSDOS-free Samsung NoteMaster >386SX/25e and have been happily through quite a few kernel revisions. >I was wondering, however, what Linux does to make all of the special >buttons on my system stop working? >For example, there is a button near the power switch which puts the >notebook into SUSPEND mode -- it works while LILO is waiting for >input, but then stops as soon as LILO begins loading Linux (even >before the kernel is uncompressed). Is LILO at fault? I know that >this feature is built right into the BIOS, since there is no DOS on my >system to use it, and it works fine immediately after LILO has >started. Does Linux bypass the BIOS? Some of the special buttons >seem to work (ie. the simulated internal mouse), but most (ie. >switching from CRT to LCD) do not. Linux does not use the BIOS (it is unusable in 32-bit protected mode). This is definately not a LILO fault, LILO is merely the last program in your bootsequence that uses BIOS to get keyboard input. This kind of special support would have to be duplicated in the kernel, but you can only do that if you have documentation about the hardware being controlled. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | | e-mail: pe1chl@rabo.nl | Tel. BBS: +31-30715610 (23:00-07:30 LT) | ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Bug Report (.99.13q) Date: Wed, 24 Nov 1993 16:10:50 GMT In greg@serveme.chi.il.us (Gregory Gulik) writes: >I'm running .99.13q and there seems to be a problem with >the system clock. >After approximately 24 hours, the system clock slows down >about 40%. The sytem clock is accurate for the first >24 hours. >I did not see this problem in versions prior to .99.13 Weird, I have never seen that and I have had 0.99 pl13q running for several days... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | | e-mail: pe1chl@rabo.nl | Tel. BBS: +31-30715610 (23:00-07:30 LT) | ------------------------------ From: el@lisse.NA (Dr Eberhard W Lisse) Subject: Re: olvwm for linux? Date: Wed, 24 Nov 1993 13:18:05 GMT open look comes with SLS 1.03 complete. el -- Dr. Eberhard W. Lisse \ / Windhoek Central Hospital \ * | Department of Obstetrics and Gynaecology Private Bag 13215 \ / 61 203 2106/7 (Bleeper) 61 224014 (home) Windhoek, Namibia ;____/ ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.motif From: hasty@netcom.com (Amancio Hasty Jr) Subject: Re: TCL/Tk vs Motif/C++ or TCL/Tk with C++? Date: Wed, 24 Nov 1993 18:31:16 GMT In article <2cvusv$aqs@infosrv.edvz.univie.ac.at> bernhard@trick.ani.univie.ac.at (Bernhard Strassl) writes: >In article <2cregi$4cs@steffi.demon.co.uk>, robert@steffi.demon.co.uk (Robert Nicholson) writes: >|> hasty@netcom.com (Amancio Hasty Jr) wrote >|> I will accept that TK is suitable for whipping up prototype (abeit, >|> throw away ones but maybe that's actually an advantage. :-)) >|> applications or relatively small applications that require little maintenance. >|> A very good one that I use regularly is Tkman by Tom Phelps. >|> >|> I'd certainly be interested in a discussion of the merits of TCL/TK >|> mixed with C++ though for application development. >|> >|> Personally I'd like to see a tklib written in C or C++ rather than >|> relying on tcl bindings. >|> > >I'm also wondering about the advantages TCL/TK can have over a well >designed UI class framework in any object oriented environment (except >saving the effort of learning an OO language). > >Having a look at Tcl scripts they seem not to be much smaller or >easier to write than aequivalent Smalltalk samples. I personally prefer >C++ but this is not the place for another ST/C++ flame war ;-) >Again, why should one use TCL/TK instead of an OO framework? >Can anyone enlight me? > >-bernhard > This is a collection of announcements which I think address some of the concerns with respect to object paradigms in tcl/tck. Not including in this post are tclOBST a tcl/tk binding to an object oriented database, and XF2 a cool tk builder all written in tcl/tk. XF2 is not written in an OO paradigm but it is quite good. All packages with the exception of tclOBST can be found Host harbor.ecn.purdue.edu Location: /pub/tcl/extensions Browse through at the FTP site there many more goodies such as database interfaces to oracle and sybase, etc... Enjoy, Amancio ======================================================================== [incr Tcl] - version 1.3 ======================================================================== This version will only work with Tcl version 7.0 and beyond. At this point, it has only been tested with version 7.0. Please send comments or suggestions to michael.mclennan@att.com. ======================================================================== Copyright (c) 1993 AT&T Bell Laboratories ======================================================================== Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that the copyright notice and warranty disclaimer appear in supporting documentation, and that the names of AT&T Bell Laboratories any of their entities not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. AT&T disclaims all warranties with regard to this software, including all implied warranties of merchantability and fitness. In no event shall AT&T be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortuous action, arising out of or in connection with the use or performance of this software. ======================================================================== Implementation Notes: [incr Tcl] adds object-oriented programming facilities to Tcl. It was NOT designed as yet another whiz-bang object-oriented programming language; indeed, it is patterned somewhat after C++. It was designed to support more structured programming in Tcl. Scripts that grow beyond a few thousand lines become extremely difficult to maintain. [incr Tcl] attacks this problem in the same way that any object- oriented programming language would, by providing mechanisms for data encapsulation behind well-defined interfaces. In many cases, ideas for new widgets or objects can be prototyped using [incr Tcl], and if necessary, the code can be translated to C for more efficient execution; the public (Tcl) interface, however, could remain unchanged. READ THE INTRO: A tutorial explanation of [incr Tcl] is presented in the PostScipt file "Intro.ps". This tutorial describes a family of "Toaster" classes that illustrate many of the features available in this package. Source code for the example classes is provided in "demos/toasters". INSTALLATION AND TESTING: 1) Obtain this distribution from harbor.ecn.purdue.edu: ftp harbor.ecn.purdue.edu cd tcl/extensions binary get itcl-1.3.tar.Z quit 2) Uncompress and untar the distribution: uncompress itcl-1.3.tar.Z tar xvf itcl-1.3.tar 3) Run the configuration script: cd itcl-1.3 ./configure or, for systems that don't recognize "#!" in shell scripts: cd itcl-1.3 /bin/sh ./configure You may be queried for the location of Tcl/Tk include files and libraries. Note that this package also requires the path to the Tcl source code, since it requires "tclInt.h" and this file is not usually installed with the standard include files. The "configure" script generates new Makefiles from their respective templates (Makefile.in). If "configure" can't find something, edit the Makefiles in "src/" and "man/" by hand and insert the proper paths. 4) Build the libraries and the executables: make all 5) Test by running the demos: cd demos ../src/itcl_wish -f coloredit ../src/itcl_wish -f listboxes 6) Install the libraries (libitcl.a and libitcl.so.1.3) and the executables (itcl_sh and itcl_wish), along with the man page, onto your system: make install ADDING [incr Tcl] TO YOUR OWN APPLICATION: To add [incr Tcl] facilities to a Tcl application, modify the Tcl_AppInit() routine as follows: 1) Include the "itcl.h" header file near the top of the file containing Tcl_AppInit(): #include "itcl.h" 2) Within the body of Tcl_AppInit(), add the following lines: if (Itcl_Init(interp) == TCL_ERROR) { return TCL_ERROR; } 3) Link your application with libitcl.a NOTE: Example files "tclAppInit.c" and "tkAppInit.c" containing the changes shown above above are included in this distribution. DEMO CLASSES: Example classes in the "demos/widgets" directory illustrate how [incr Tcl] can be used to create new widgets that look (from a programming standpoint) like normal widgets but are written entirely in Tcl. These widgets are defined as object classes, and pack primitive widgets together to provide higher-level functionality. Two demos are provided which illustrate how these "mega-widgets" could be used in a real application: demos/listboxes .... Illustrates high-level listboxes: - ListBox - SelectBox - FilteredBox demos/coloredit .... Allows colors to be changed in another Tk application. Illustrates: - FilteredBox - ColorEditor Once you have created and installed the "itcl_wish" application which recognizes [incr Tcl] facilities, you can invoke these demos as: % cd demos % itcl_wish -f listboxes % itcl_wish -f coloredit It is necessary to sit in the "demos" directory when running these scripts, since they need to access the class definition files that reside in the "widgets" directory below. LIBRARY ROUTINES: The "library" directory contains a few useful Tcl procedures: library/auto_mkindex.tcl .... the usual "auto_mkindex" proc updated to include [incr Tcl] classes when building an index library/itcl_reload.tcl ..... a series of procedures for unloading and reloading class definitions; useful when debugging [incr Tcl] applications. SUMMARY: Widgets provide a natural domain for object-oriented programming techniques. They are not, however, the only domain. I believe that [incr Tcl] can be used in more diverse applications to add structure to Tcl programs. The "itcl_class" mechanism should be used to group related procedures and their shared data into a neat little package with a well-defined interface. Please experiment with this facility and send me your comments. --Michael =--=== /////////////////////////////////////////////////////////// =-----==== Michael J. McLennan 2C-226 michael.mclennan@att.com =------===== AT&T Bell Laboratories ==----====== 1247 S Cedar Crest Blvd Phone: (215) 770-2842 ========== Allentown, PA 18103 FAX: (215) 770-3843 ====== /////////////////////////////////////////////////////////// =========================================== A Simple Object System for Tcl (integrated with Tk widgets) theObjects-2.3 Juergen Wagner FhG-IAO Stuttgart, Germany J_Wagner@iao.fhg.de This is release 2.3 of theObjects, a prototype-based object extension for Tcl 6.7/Tk 3.2. The main difference between 2.2 and 2.3 is the fact that more widgets have been added (you've read that before, haven't you?). In particular, a rectangular table widget (Matrix) has been added for spreadsheet-like layouts, and the simple DAG layouter has been added to the DAG widget itself (i.e., no more LISP code!). A few bugs have also been fixed. :-) If you have not read README-2.2 yet, please do so. It explains how to build the library, and how to modify a Tcl 6.7/Tk 3.2 main.c to integrate this package into an existing "wish". If you download the package please let me know (feedback, comments, problems, bugs, flames, etc.). You can reach me by e-mail as J_Wagner@iao.fhg.de or gandalf@csli.stanford.edu Happy experimenting, --Juergen Wagner =================================== TooCL Tooltalk for TCL ---------------- Cedric BEUST (beust@sophia.inria.fr) TooCL is a Tooltalk interface to Tcl/Tk. It will allow Tcl/Tk applications to connect to Tooltalk and send and receive messages just like any other application. This is an almost fully-blown interface to Tooltalk 1.0.2. TooCL is based on Tcl 6.7 and Tk 3.2a. You must have these distributions handy to compile this package. -- This message brought to you by the letters X and S and the number 3 Amancio Hasty | Home: (415) 495-3046 | ftp-site depository of all my work: e-mail hasty@netcom.com | sunvis.rtpnc.epa.gov:/pub/386bsd/X ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************