Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!math.fu-berlin.de!opal!unido!rwthinf!cip-s02.informatik.rwth-aachen.de!u31b3hs From: u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) Newsgroups: comp.sys.transputer Subject: Re: Origami 1.5 Message-ID: <4148@rwthinf.UUCP> Date: 15 Mar 91 10:54:49 GMT Sender: news@rwthinf.UUCP Reply-To: u31b3hs@cip-s02.informatik.rwth-aachen.de (Michael Haardt) Organization: Informatik RWTH Aachen Lines: 63 Hello, in "RE origami ...." Phillip M. Hallam-Baker writes: > This only obliquely concerns parallelism but all this hassle >because people did not cast their mallocs properly reminds me of >an article in parallelogram where a company was crowing over it's 64 >bit database they had written for CRAY. They claimed that a lot of >their competition could not do so because their programmers had >used integers to hold pointers which is a limited value trick once your >pointers get too big... just goes to show that moaning type checkers >can be a real advantage! I read the discussion about porting Origami to different machines in this newsgroup, but I was too busy to posting an article last time. At first, I want to say something to the above article: malloc needs no cast. The correct definition is: "void *malloc(n) size_t n;" A pointer to void is compatible to any other pointer. Not all compilers handle this correct, but a pointer to malloc can always be assigned to any other pointer. If you use a broken compiler, you will get a warning which can and should be ignored. The "extern void *malloc();" (k&r!) definition is in , if your header files follow POSIX. If it is defined as "extern char *malloc()", the manufacturer shows, that he believes in old k&r. Anyway, the resulting pointer is aligned for use for any data type. A cast could me made to avoid warnings, but it does not influence the function. If you use SunOs 4.0.x, your include files and libraries are not up to date. Do not waste any time with porting it, Origami runs ok with 4.1. If you want to use it on 4.0, compile a version on 4.1 and use static linking. The resulting binary runs on 4.0. (We tried it a week ago on our systems). I assume (or hope), that those people who have problems with their keybaords use the right keybindings. Meta-z will be only defined in Emacs-mode. If your return-key does not work, try linefeed. I had the same problem with MINIX. We solved it by binding both return and linefeed to the function newline-and-indent. I can't imagine, why half of the keys are not working while using Origami. We never had any problems on SunOs 4.1 and PC MINIX 1.5.10. It must be a local problem, either with the header files or with the libraries. The code is not very clean. Some people bemoaned this and it is true. Origami compiles and works, but changes are difficult. A big clean-up is made at the moment which results in a modular, well-structured and commented code for the next version. The current version should be used for using, not for extending this editor. A lot of new features will be available too, but this new version 1.6 is neither finished or well-tested. The current version 1.5 should be stable for using it. There will be no support for old systems in Origami. We made this decision to encourage using POSIX. I really hate the divergencies between Unices, and POSIX tries to prevent this. Most manufacturers accept this in their newest releases. A program should not contain 50 percent #ifdef MY_SYSTEM, #ifdef YOUR_SYSTEM. Namaskaar Michael Haardt (u31b3hs%cip-s01.informatik.rwth-aachen.de@unido.bitnet)