========================================================================= (C) 1994 by Atari Corporation, GEnie, and the Atari Roundtables. May be reprinted only with this notice intact. The Atari Roundtables on GEnie are *official* information services of Atari Corporation. To sign up for GEnie service, call (with modem) 800-638-8369. Upon connection type HHH (RETURN after that). Wait for the U#= prompt.Type XTX99437,GENIE and press [RETURN]. The system will prompt you for your information. ========================================================================== ************ Topic 5 Fri Mar 15, 1991 S.MORRIS5 [MORRIS] at 21:28 PST Sub: SOZOBON A topic to discuss Sozobon C. 174 message(s) total. ************ ------------ Category 3, Topic 5 Message 1 Sun Feb 02, 1992 M.ABREU [Abe] at 09:56 EST So, before I download V1.33i, if I'm using Gulam and I'm happy with that environment, will V1.33i work for me? Since I've already got Sozobon installed somewhere, will the smart installer work OK for me? ------------ Category 3, Topic 5 Message 2 Mon Feb 10, 1992 R.GOFF [Bob] at 22:29 EST Yes, if you're already set up and running with Gulam, the smart installer should put 1.33i in the same place and let you run it normally. Bob ------------ Category 3, Topic 5 Message 3 Sat Mar 21, 1992 S.YELVINGTO2 [Steve] at 16:42 EST Dave Gymer in the U.K. has ported the MiNT C library to Sozobon. I have the sources, but I'm still waiting for the mail server at Michigan to send me the .H files. When I get them, I'll upload them. If I'm successful at building the object library, I'll upload it, too. Here is Dave's README file: ------------------------------------------------------ Here's my (dodgy) port of MiNTlib to Sozobon C. This has not been fully tested, and there is no floating point support, because I have no interest in that direction. I used the Sozobon C 2.0 source as distributed, built under GCC 1.39 as a UNIX hosted cross compiler, to do my original port (which was released as part of pl18 of the library). Later versions were done with Ian Lepore's 1.33i release. I used GNU make; your mileage under any other make may vary. I did carry on using a version of ar compiled with the GCC, since only a version compiled with the MiNTlib understands about long arg lists, such as the enourmous list of modules given. To build this library, delete all the *.s and *.cpp files from the main lib directory, and also linea.c, which clashes with linea.s. Then copy all the files in the sozobon directory into the lib directory, and hit make (some adjustment of the makefile may be necessary). You might look on this as a farewell gift to MiNT, since I'm awaiting delivery of a brand new 386DX-33 PC to try Linux out on; if it works, I'm unlikely to use my ST much any more other than for soundtracking and archival purposes (though I will try to build a cross-gcc, to keep an eye on how MiNT progresses). -- Dave Gymer (dpg@Cs.Nott.AC.UK) ------------ Category 3, Topic 5 Message 4 Thu Apr 02, 1992 S.YELVINGTO2 [Steve] at 04:05 EST A little Sozobon 1.33i bug report: The memcpy module in the C runtime library appears to be hosed. This isn't surprising; memcpy has been broken in several versions of dLibs as various people tinkered with the assembler source, trying to make it fast. Here's a fixed version lifted from the MiNT library that you can use to replace the memcpy.o module in dlibs.a. Note the test routine at the bottom; if you lift it out and compile it separately, you can verify the bug in the distributed library. If you don't know how to use the ar library-management utility to put this into your library, just ask and I'll explain it. /* from Henry Spencer's stringlib */ #define const /* sozobon doesn't do const */ #include /* for size_t */ /* * memcpy - copy bytes */ void * memcpy(dst, src, size) void * dst; const void * src; size_t size; { register char *d; register const char *s; register size_t n; if (size == 0) return(dst); s = (const char *) src; d = (char *) dst; if (s <= d && s + (size-1) >= d) { /* Overlap, must copy right-to-left. */ s += size-1; d += size-1; for (n = size; n > 0; n--) *d-- = *s--; } else for (n = size; n > 0; n--) *d++ = *s++; return(dst); } #if TEST char *src = "01234567890123456789"; char buff[11]; main() { int i; for (i=0; i<8; i++) { strcpy(buff, "XXXXXXXXXX"); memcpy(buff, src+i, 10); printf("i=%d, buff='%s'\n", i, buff); } } #endif ------------ Category 3, Topic 5 Message 5 Sun Apr 05, 1992 A.WESTON [Alan] at 13:36 EDT I'm having some problems getting up and running with Sozobon C. I have version 1.30I. I have installed it to drive C, in a folder labeled sozobon. I have set my environment variables (path, include, lib, bufsize) as the instructions say, and I have modified the make.ini file to use Sozobon's assembler and linker. When I run make to compile the examples, I get an error message saying that CC can't find the compiler. I'm lost here. Any ideas on what I'm doing wrong? -Alan ------------ Category 3, Topic 5 Message 6 Mon Apr 06, 1992 JLS [John STanley] at 02:55 EDT Note to Steve Yelvington (and everyone using dLibs 1.2): (note at end to Alan Weston..) Steve, thanks for the fixed C form of memcpy(). You may want to note that the original lmemcpy() has exactly the same (serious) bug and a small handful of changes to the memcpy() function you provided will provide a useable lmemcpy(). (Note, anyone using dLibs 1.2 should replace memcpy() and lmemcpy() with the version provided by Steve (or some other fixed version) ASAP. These functions are used in several key areas including the program startup code, realloc(), and the qsort() functions. The memcpy bug demonstrated with Steve's sample code could cause some rare bizzare results that may be difficult to trace.) Steve, I also noticed that it looks like the dLibs libraries provided with the 1.33i version of Sozobon appear to be slightly different than those posted earlier and the 1.33i sources were not uploaded to GEnie. Would you have the source for the dLibs distributed with 1.33i? Do you know if any work is in progress to combine the plethora of bugfixes and minor corrections along with the MNTLIB compatable with Sozobon? Do you have any idea if Dale is still involved with dLibs or Sozobon in general? - - - Alan Weston, You listed the environment variables you're setting as all lower case words. If that's how you're defining them, that's your problem. If you're putting a backslash on the end of the path name, then that could also be causing your problem. The PATH variable should be defined (for your setup) as: PATH=c:\sozobon\bin and not: path=c:\sozobon\bin -or- PATH=c:\sozobon\bin\ The other variables should be set up in a similar manner... If that doesn't fix your problem, try using the NAMETRAK.PRG (included with Sozobon 1.33i) or the SYS_MON.PRG programs to see where MAKE is looking for the compiler... ... JLS ------------ Category 3, Topic 5 Message 7 Tue Apr 07, 1992 A.WESTON [Alan] at 07:31 EDT I found the problem. I had the environment variables set properly, but I needed to uncomment a few lines in the make.ini file. Sozobon works fine now. ------------ Category 3, Topic 5 Message 8 Wed Apr 08, 1992 S.YELVINGTO2 [Steve] at 02:48 EDT John, I don't have the 1.33i library sources. From what I've been able to determine, Ian started with the Sozobon 1.2 package and did his own bugfixes and development work, and didn't ever see some of the stuff that was posted to Usenet, so some old bugs are cropping up in his version of the library. (I swear that memcpy bug has been fixed a half a dozen times!) He's also rewritten some of the internals, including the str* functions, in asm. I have a big file of bug reports and comments from Usenet that I'm going to copy to a floppy and mail to Ian one of these mornings. I'm going to send him the Gymer- modified MiNT library sources, too. Last time I talked with Dale he said he wasn't interested in any further development of dLibs. He seems to be devoting his off-work hours mostly to Wally-Ball and the Society for Creative Anachronism, plus a little bit of work on the Graphics Gems series of books. (I really ought to call him again ... I have a roll of newsprint out in the garage that he asked me to get about nine months ago. On the other hand, it's handy for cleaning the windshield....) ------------ Category 3, Topic 5 Message 9 Sat Apr 18, 1992 D.LEMAY2 [Darwin] at 08:19 EDT I disassebled the test program and found the bug(s) in the memcpy routine, which also contains the long memcpy better fix lmem.. or they won't have one. Here;s the code, fixed and commented, and I found one error in the sybex 68k book as well, in that it states it a btst success will result in a bne happening. This didn't prove to be true. This version passes the test Steve wrote fine. I haven't got time tonite link it into the library and through some other values at it. All lower case is mine, Upper case is the original. If anyone requests it, I'll put a dri linkable file up in the library here. I'll have to figure out how to replace the one in the .a file as I've never done that before. John Henders c/o D.LEMAY2 --------------------------------------------------------------------- _memcpy: MOVEQ #0,D1 MOVE.W 12(A7),D1 ; counter BRA.B skiplmem _lmemcpy: MOVE.L 12(A7),D1 ; ditto skiplmem: BEQ.B endit MOVEA.L 4(A7),A1 ; source MOVEA.L 8(A7),A0 ; dest MOVE.L A0,D0 MOVE.L A1,D2 EOR.W D0,D2 ; why xor the two addresses? BTST #0,D2 ; check for word boundary BNE.B L009F ; if the source isn't even, do a byte move BTST #0,D0 ; check dest for word boudary BEQ.B L0096 ; if even, go set up to do long moves MOVE.B (A0)+,(A1)+ ; if all else fails, move one byte SUBQ.L #1,D1 ; count-- L0096: MOVE.L D1,D2 ; copy counter LSR.L #2,D1 ; divide by 8, but where's there MOVE.W D1,D0 ; remainder gone. this is the bug lsl.l #2,D1 ; so lets set the word back to sub.l D1,D2 ; the new /8 number, then sub that move.l D2,D1 ; from old number SWAP D1 ; Let's play Hide the variable BRA.B L0098 ; L0097: MOVE.L (A0)+,(A1)+ L0098: DBF D0,L0097 BRA.B L009C L0099: MOVE.W #$1000,D0 BRA.B L009B L009A: MOVE.L (A0)+,(A1)+ MOVE.L (A0)+,(A1)+ MOVE.L (A0)+,(A1)+ MOVE.L (A0)+,(A1)+ L009B: DBF D0,L009A L009C: DBF D1,L0099 BTST #1,D2 ; now this should test true ; with 2 in d2 ,according to beq.b L009D ; my 68000 book, but it behaves ; the opposite as Sybex says MOVE.W (A0)+,(A1)+ ; the original bne should have worked bra endit ; but I watched it skipp happily by with L009D: BTST #0,D2 ; the z flag set beq.b endit MOVE.B (A0)+,(A1)+ endit: MOVE.L 4(A7),D0 RTS ********************************************************* * here beenden There are a lot of intelligent people on the net that will go ballistic when they are subjected to something stupid. -- Larry Smith on the rec.arts.manga debate jhenders@jonh.wimsey.bc.ca ------------ Category 3, Topic 5 Message 10 Wed Apr 22, 1992 S.YELVINGTO2 [Steve] at 02:44 EDT A little something from Usenet that you might find interesting: From: ilepore@isis.cs.du.edu (Ian Lepore) Newsgroups: comp.sys.atari.st.tech Subject: Sozobon v1.33i -- current status Date: 21 Apr 92 19:37:12 GMT Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept. I recently sent Steve Yelvington a little status report on my verson of Sozobon C and asked him to post it here. Now I've figured out how to post things here myself, so here's what up with the next release... I am planning another sozobon release soon, more so now that you've sent me more bug reports. My future releases of sozobon are going to be called HSC (Heat and Serve C) and are going to lose all connection to the sozobon name. After seeing what the sozo crew has done with their v2.0, I can see that they're going in different directions than I (they're after unix compatibility and other things I don't care about; I wanna concentrate on usability improvements, I don't care if it'll compile under unix or not). I've studied what sozo v2.0 did to get longer external names, and I'm planning on hacking the same (or a compatible) method into HSC. But, it won't be the next version, I just don't have time right now. The next version (which'll be called HSC v1.34) will fix minor bugs (listed below) and will have the v1.8 of gemfast in it. HSC v1.34 minor fixes planned as of now: - A table in LD is pre-sized to allow up to 100 modules in a library. GemFast now has more modules than that, so the table is expanded. - The HCC -I option is being handled wrong, I discovered. From now on it'll search the -I paths first instead of last. - memcpy() bug: I haven't fixed it yet, but I will for v1.34. - If someone can educate me on the ARGV standard I'll fix STMAKE. - There's a new tool to replace the (braindead) SZ and NM programs. As to bug reports you sent me: Ben Gilbert reports problems with using VDI. Offhand, they sound like coding bugs more than vdifast.a bugs. They sound a bit reminiscent of using the physical workstation handle directly instead of creating a virtual screen workstation. Hard to say, but hopefully GemFast v1.8, with it's new easy-to- use apl_vopen() function will help. Speaking of VDI, there were some radical bugs in the bindings. I got a nice letter from a gent in England detailing the bugs and fixes, and they've been applied. They affected all VDI escape functions, and a few other things as well. Bug in fsize() -- I've never used that function, I'll look into it. Bug in memcpy() -- I'll fix it, thanks for the detailed example. Definition of BYTE, WORD, and LONG in TYPES.H -- ::sigh:: As a general rule, I hate using words like that to (supposedly) make code portable. I wish folks would just use short when they mean short and long when they mean long and leave the int word alone. Anyway, I'm afraid that if I change TYPES.H a lot of existing code will break, especially in dlibs. Maybe I should just document this as "something you might wanna check." bugchk() in TOP -- I think I fixed this already, but I'll have to check my version notes to be sure. In general, I use bugchk in the same sense as VAX/VMS does: it means that somehow the program reached a point in the code that just "cannot happen" and it doesn't know what to do next. Usually it's a fatal error, but this mighta been some special case I was testing for in TOP. dlibs - I was planning on rewriting these, but now someone has uploaded to BIX the source code for the MiNT libraries, and instead of reinventing the wheel, I'm going to investigate using them in place of dlibs to whatever degree is possible. Not in v1.34 though, the next version after that. ------------ Category 3, Topic 5 Message 11 Wed Apr 22, 1992 S.LAUGHLIN at 23:07 EDT To Steve Yelvington, Could you tell me how to add DRI object modules to the the GEMFAST libraries. I have a few I've written to do Line A calls and would like very much not to have to link them as seperate modules each time I compile. Thanks Shawn ------------ Category 3, Topic 5 Message 12 Thu Apr 23, 1992 S.YELVINGTO2 [Steve] at 03:04 EDT Shawn -- See the documentation for the AR utility. I wouldn't add your Line A modules to aesfast.a or vdifast.a. I'd put them in a separate library and add that library to the LIB= line in your makefile. (You ARE using make, right? If not, you should. It makes life much nicer.) ar -rv mylib.a file1.o file2.o file3.o ... will place three object files in a library called mylib.a. The -r switch means ``replace,'' so any modules in the library bearing the same names will be deleted. I think the -a and -q switches do a simple add, but that can leave to identically named modules in the library. You don't want to do that. ------------ Category 3, Topic 5 Message 13 Thu Apr 23, 1992 S.LAUGHLIN at 08:34 EDT S.YELVINGTO2 [Stene] Errr... no...I mean er .. make file? Actually I've never figured how to *make* those darn things work right, not even the one the came with the HEAT AND SERVE as an example. So instead I have about 20 or 60 disk with filenames like "files.o, files2.o , files2b.c, control.c, main6a.o, etc..." Then I'm kicking myself because half of the time I forget ( too lazy ) to label the files and I sit there like idiot feeding my disk drive disks like pancakes hoping the file I'm looking for is on the next disk. Not what you'd call a fine tuned system . What I have figured out is how to use the .tmp file with the loader. I have all my object modules and libraries listed in that file and I run it with the loader. But as you've probably guessed my .tmp file is usually on an unlabled disk ... Shawn ( who aint that organized ) ------------ Category 3, Topic 5 Message 14 Fri Apr 24, 1992 S.YELVINGTO2 [Steve] at 03:07 EDT # GENERIC MAKE FILE FOR SOZOBON C 1.33i # change PROG= and OBJ= entries as necessary CFLAGS = -v -O PROG=yourprog.prg OBJ=file1.o file2.o file3.o $(PROG): $(OBJ) $(CC) -o $(PROG) $(OBJ) The format is: target: stuff it depends upon how to generate the target (optional) There's a general rule for generating .o files out of .c and .s, and one for generating .prg and .ttp and .tos out of whatever happens to be lying around in the directory. Therefore you don't always need to specify any rules -- indeed, you don't even need a makefile! If you're running from a command shell, you can type make filbert.prg and if filbert.c, filbert.s or filbert.o is available, MAKE will convert it into filbert.prg. If you run from the Desktop, just double-click on MAKE and type the name of the target in the .TTP dialog. Of course, this method has a BIG drawback in that the Desktop will try to put you in the same directory as MAKE.TTP, which is probably NOT where you have your program source code. I recommend that you get a smarter Desktop, such as Gemini. ------------ Category 3, Topic 5 Message 15 Fri Apr 24, 1992 JLS [John STanley] at 03:09 EDT Shawn, Rather than adding your LineA functions to the gemfast library (which would mean you'd have to RE-add them to future updates of the library and your make files would be invisibly incompatable with other setups). A better solution would be to create your own seperate linea.lib file... It's almost always a bad idea to add non-standard functions to a standard (or even semi-standard like gemfast) library. ... JLS ------------ Category 3, Topic 5 Message 16 Sat May 23, 1992 S.YELVINGTO2 [Steve] at 23:38 EDT I've uploaded the Sozobon/Heat and Serve C version of the MiNT libraries, version 20. The archive includes replacements for dstart.o, dlibs.a and libm.a (the floating-point library) plus a termcap library. To use the new MiNT libraries, you'll need the compatible header (.h) files, which were uploaded separately. Programs built with the old dlibs WILL multitask with MiNT. The advantages of the MiNT libraries include support for new MiNT OS calls, a more ANSI/POSIX- like library, and a lot of bugfixes. Programs built with the MiNT library can multitask more efficiently and spawn multitasking children. ------------ Category 3, Topic 5 Message 17 Mon Jun 01, 1992 S.YELVINGTO2 [Steve] at 00:13 EDT I uploaded MNTHL20A.ZOO, a bugfixed update of the patchlevel 20 MiNT library for Sozobon/Heat and Serve C. I think Sandy already has put it into the library, and the outdated versions are being sent off to a rendering plant or whatever happens to dead file carcasses. Ian Lepore is sending me Heat and Serve C 1.40 -- presumably a beta version. It will have a lot of changes/additions to the GEMFAST libraries. I'll have more to say after I get ahold of it. Steve Yelvington Marine on St. Croix, MN ------------ Category 3, Topic 5 Message 18 Tue Jun 02, 1992 M.DORMAN2 [Mike Dorman] at 19:28 EDT I've already got 1.40, and I've looked at the GemFast docs--1.8 is almost overwhelming in what it allows you to do. Dynamically moveable dialog boxes. Popus menus. The compiler seems a little more intelligent, but no big differences--still smaller, faster, and a (seemingly) better code-producer than GCC 2.1 (my other compiler). Mike. ------------ Category 3, Topic 5 Message 19 Thu Jun 04, 1992 C.HERBORTH [-Chris-] at 19:53 EDT Has anyone uploaded GEMFast 1.8 to the GEnie Library yet? Boy I miss my network account... :-( -Chris- ------------ Category 3, Topic 5 Message 20 Thu Jun 04, 1992 M.DORMAN2 [Mike Dorman] at 21:47 EDT Chris-- GemFast 1.8 isn't publicly available, yet. I don't think... I've only got it in the beta distribution of HSC 1.4, which I'm hammering away on with ill concealed glee. Speaking of which: Steve-- Have you had any problems with getting a "double define _itoa a2 a2" message with the HSC linker and the libs with 1.4? I've done everything I can think of to get rid of it, but it's still there. Haven't looked that the libraries, proper, yet. Mike. ------------ Category 3, Topic 5 Message 21 Tue Jun 09, 1992 S.YELVINGTO2 [Steve] at 02:32 EDT I don't have 1.4 yet ... Ian said he was preparing a disk to mail to me, but nothing has shown up so far. I'm looking forward to it -- I have a little beer-brewing recordkeeping program I'd like to code up one of these days, and I don't want to arm-wrestle with GEM until I get some more help from the libraries. ------------ Category 3, Topic 5 Message 22 Tue Jun 09, 1992 M.DORMAN2 [Mike Dorman] at 20:35 EDT Steve-- Would Internet mail do you for? I can send it that way, though be warned-- it's HUGE. The new GemFast docs are 255K. 94 pages. I basically killed a ribbon when I printed it. Mike. ------------ Category 3, Topic 5 Message 23 Thu Jun 11, 1992 S.YELVINGTO2 [Steve] at 00:36 EDT Holy cow, Mike. The DOCS are that big? Yeah, Internet mail would be fine, but I'll have to clean out some crud from my c: drive before it gets here. I'm down to 800K free, and that's not safe. Time to nuke rec.crafts.brewing and rec.sport.olympics. ------------ Category 3, Topic 5 Message 24 Thu Jun 11, 1992 M.DORMAN2 [Mike Dorman] at 18:20 EDT Well, the rest of the docs are smaller. I looked at the file, and it's about 350K for the whole package. I've also maybe found a bug--when running BOOZ.TTP (GEM-izing it is my current project), listing the contents of a file gets really screwy. The exact same code works fine under GCC, so I send Ian a good binary and the source. It worked under 1.33i. Mike. ------------ Category 3, Topic 5 Message 25 Sat Jun 13, 1992 C.HERBORTH [-Chris-] at 09:19 EDT 255k for the new GEMFast docs?!? Wow... That's almost as exciting as the possiblity of a new machine from Atari... -Chris- ------------ Category 3, Topic 5 Message 26 Tue Jun 16, 1992 JLS [John STanley] at 05:04 EDT Steve, When I last communicated with Ian, he suggested I should contact you for the beta 1.4. Please let me know when it arrives and I'll drop off however many blank disks you need at the STrib office... BTW, If you have any problems putting aside enough space for a monster internet-transfer from Mike, just let me know how big it is and he can send it thru me. Just let me know in advance so I'll be sure to have the space set aside for it. (I have one of the new Supra modems on order which, once it arrives, will make this even easier... :^) - - - Mike, Any idea if Ian fixed the assembler so it allows mixing long and short addressing/branches in the same module? I have a program that uses mixed- modes for the branches and fixed offset calculations for some of the address calculations that I need to patch. I've got it disassembled and patched, but I can't use jas to reassemble it because jas "optimizes branches" or "doesn't" which means it produced only short or long branches (totaly ignoring the cues in the opcode extensions..). ... JLS ------------ Category 3, Topic 5 Message 27 Wed Jun 17, 1992 M.DORMAN2 [Mike Dorman] at 02:10 EDT Steve and John-- Did either of you get 1.4? I got bunches o' bounced mail when I tried to send it, but I'd gotten it before, and wasn't sure if it made it and I just got bounce messages or if it really bounced. I have no idea why the stuff to Steve died, since I've sent stuff to him that way before... Grrr..... Mike. P.S. John--No idea. Nothing I remember int the update docs seemed to indicate it, so I'd just assume it doesn't :-( ------------ Category 3, Topic 5 Message 28 Thu Jun 18, 1992 M.DORMAN2 [Mike Dorman] at 23:03 EDT To anyone using Sozobon 1.33i & GemFast 1.(6? 7?): Anyone got any programs that use wind_calc or winx_calc? I've got this little fractal program I've hacked up (actually I stole some 2 year old sources from Bill Rosencranz on UseNet (they were PD, so it's not really stealing) and ripped out the calculation guts, and converted it to Sozobon, and made it use the VDI, and then slapped some GEM stuff on it, and it's up and running, but there's still a lot of neat stuff left to do...), and either I am misinterpreting the way wind_calc works, or it's broken. To wit: To draw the fractal as it's being generated, I'm generating it straight into an MFDB, and then blitting that to the screen. I want this in a window, so it can be dynamically resized. SO, for the first time a person decides to run a fractal, I grabbed the max window size (using wind_get with a 0 handle). From that, I run it through wind_calc to get the inside coordinates of the window. They didn't look right when I printed them, but I figured the system call knew what it was doing. For the MFDB to work, the width has to be an even integral of 16. So I chop the returned window width by the modulous of the width and 16. Great. When I try to get the new outside size, I end up getting *smaller* values. This is NOT what I want. And I pray for the souls of Atari personel if this is the way that wind_calc is supposed to work. :-) If it's Ian's screw up, well, I can just bug him about it. As it is, I end up doing a wind_get on the produced window, and then resizing my MFDB based on the biggest multiple of 16 that'll fit. That leaves an ugly grey band between the sliders and the image... Anyone have any ideas? I've put a lot of work into this so that it'll be a really nice GEM-based program--res independent and everything (Hell, I want to get a better machine so I can get it running faster & with more colors...) (actually, the color support is still just two color, but that's just for convenience--I'll have color gradiation any day now--probably Saturday) (in fact, does anyone have a TT that they'd like to test it on, in, say, a week? I want to add the capability to use the mouse to select a zoom area, and some other stuff, and clean up the little aesthetic warbles that it's currently got). It's really frustrating to have spent *all this time* (really just three days of working on it every time I've got an hour), and to have run up against a brick wall. So has anyone got some code that they can test on older versions of GemFast, so we can tell Ian it's an official bug? And other things: The reason I'm not willing to go back to GemFast < 1.8 is because it would be like going back to, oh, horse-drawn carraiges. I blit this image to the screen with *ONE LINE OF CODE*. Just one. Plus a whole host of other things. This program generates pretty good mono bitmaps of fractals in under 300 lines of code. That's with a good bit of GEM support. And resolution independence (if not resolution exploitation). Oh, and even more problems: Anyone ever used the libm.a that's supplied with 1.33i and up? The one that's fplib 2.0 by any other name? Ever noticed any problems with the atof() function? I *CANNOT* get it to work, and I need that capability *BAD*, so people can input different starting locations for generating Mandelbrots. When I try, when I stick the resulting float into the position variables, and then display them on the info line of the window before I draw them, all the values have changed, not just the one I fiddled with. Though that may just be my fault. Hints, tips, a pointer to the original source? (I plan to look on Atari.archive tomorrow--I think that's where I got it to give to Ian). To sum up: The 1.40 compiler is nice, but merely an incremental improvement over 1.33i. GemFast 1.8 kills. I hope to use so much of the VDI and AES that any lurking bugs will get taken to the cleaners (GDOS output? Might be nice. Anyone have specs on .IMG files? I also want to figure out GIF and the Fractint extensions, so I can save in that format and then render at 2048 * 2048 * 256 at work). Having some people test other versions to see if I'm doing something wrong would be invaluable, since I don't have the older stuff still installed, and besides, I'd have to write whole new programs to test stuff, since all this code is pretty attached to GemFast 1.8. Just to keep you guys excited. Mike. ------------ Category 3, Topic 5 Message 29 Fri Jun 19, 1992 S.YELVINGTO2 [Steve] at 03:46 EDT Jeez. No, Mike, I didn't get *anything* from you. Where did it bounce? Since you're now an Internet site, you should be able to get it straight through to the kksys machine, which is tcnet.mn.org. And tcnet should never bounce mail. You could try steve%thelake@cs.umn.edu, too. I have a UUCP connection with the university, and its mailer will untangle the %-hack. On the atof() thing -- I've used it without any troubles. I compiled a homebrew beer calculator last week using the floating-point library, and it worked just fine. All I did was #include and link the library. ------------ Category 3, Topic 5 Message 30 Fri Jun 19, 1992 M.DORMAN2 [Mike Dorman] at 20:29 EDT You should have it now--I sent it at about 2 p.m., and as of 6 p.m. I hadn't gotten any bounce messages. Did you recently change or delete some aliases? I think I was sending to s.yelvington@thelake.mn.org. I'm not sure why...I think it's just what I happened to have set up on the mainframe, and it worked there, but the mailer on the NET may not be as intelligent. So, it should be there. So, since I didn't seem to get anything to JLS, either, could you get him a copy? I'm pretty eager to have other people working this stuff over. BTW, have you heard anything from Ian in the last couple of weeks? He said he was going to send me the disks about, oh, two weeks ago, and nothing yet, and I've mailed him about three or four things with nary a response. As to the floating point stuff: There's no docs with the 1.40 stuff, and none with the 1.33i stuff, that I can remember--is there a chunk of docs on atof that you could post here--I don't even know how to check to make sure that there's a valid number being produced... Mike. ------------ Category 3, Topic 5 Message 31 Sun Jun 21, 1992 M.DORMAN2 [Mike Dorman] at 18:21 EDT Stonkered, that's what I am: float floatTemp, floatXPos; char charXPos[12]; voidMoveCursor(0,0); if ((floatTemp = atof(charXPos)) != 0.0) { floatXPos = floatTemp; } else { sprintf(charXPos,"%f",floatXPos); } printf("%f, %s",floatTemp,charXPos); By rights, that code should, if charXpos = "33.777" produce the output: 33.777, 33.777 Instead, I get something like: -27984.00000, 33.777 Obviously, the string's not getting screwed, so it's got to be atof. Steve (or someone) could you post a bit of code showing how to use atof()? I'm certain that it must be me, if you're not having any problems. Mike. ------------ Category 3, Topic 5 Message 32 Sun Jun 21, 1992 M.DORMAN2 [Mike Dorman] at 18:41 EDT Could someone else compile and run this program and tell me what the output is? I'm trying to test this winx_get problem. I think winx_get is in GemFast 1.7, in HSC 1.33i. #include #include main() { GRECT inside, outside; apl_xinit(); winx_get(0,WF_WORKXYWH,&outside); printf("%d %d %d %d\n",outside.g_x,outside.g_y,outside.g_w,outside.g_h); winx_calc(INFO|NAME|SIZER|MOVER|CLOSER|FULLER,WC_WORK,outside,&inside); printf("%d %d %d %d\n",inside.g_x,inside.g_y,inside.g_w,inside.g_h); inside.g_w -= inside.g_w % 16; printf("%d %d %d %d\n",inside.g_x,inside.g_y,inside.g_w,inside.g_h); winx_calc(INFO|NAME|SIZER|MOVER|CLOSER|FULLER,WC_BORDER,inside,&outside); printf("%d %d %d %d\n",outside.g_x,outside.g_y,outside.g_w,outside.g_h); getchar(); } It should just print four lines of values. On my machine I got: 0 11 640 189 1 23 638 177 1 23 624 177 2 24 622 175 I'm pretty sure that's not right. The first value (the Desktop work area) looks like it is. The second value's stuff is screwy--there sure isn't enough room for a name field *and* an info line, nor a bottom slider or a right slider. The third value shows up right--all I did was chop off anything that wasn't word-width integral. And then the last values. Boy are they screwy, if I understand what's supposed to happen. I'd expect (if we pretended that the height stuff from the second line was right (despite the obvious problems with it)) that the last line would return 0 11 626 189. Anybody got any corrections to me or my code or my interpretation? Mike. ------------ Category 3, Topic 5 Message 33 Sun Jun 21, 1992 M.DORMAN2 [Mike Dorman] at 21:17 EDT And another: (I've got two projects on the burners--a MIDI sequencer that I can live with (read: one that is oriented toward putting stuff in on-screen, instead of through a keyboard, since I can play guitar, and write music, but I may as well have 10 thumbs when it comes to keyboards), and this mandelbrot program) In order to get good time-resolution for MIDI events, you need to have a timer routine hooked to the MFP 200us timer, so that you can accurately timestamp a note, so you can then put it back out at the same relative "time". There's some code in the library to do this--MIDILINK.ARC. Unfortunately, it was written for, I believe, MWC, and as a result uses inline asm to install a timer interrupt handler. Of course, all the handler does is increment a variable (one declared in the C section of the program), and clears the interrupt. There's some other code in the library, from Alan Hamilton, that does the same thing (well, similar--it does something else, but it hooks the interrupt), also using MWC, I think. The difference is, his is written entirely in C, but it uses a special function, setrte() to tell the compiler that what's coming up is an exception handler, and that it should use rte instead of rts to return to the caller. The problem is this: Neither of these things exists for Sozobon. And I have no idea to access C variables from asm, so I have no idea how to squeeze this off into another module that I can run through JAS or MadMac. All the code has to do is increment as single unsigned long variable, do a bclr.b #5,0xffff0a (I think that's the address) and then rte. Can anyone help? I can sort of halfway read assembler, but I don't have any reference manuals. I figured out what the bclr.b did by digging through the devdocs and doing some interpolation and realized that all it was doing was clearing the flag. I have all the other code converted and totally undebugged, since I can't get this rather essential section of the program. Maybe I'll just get the compiler to output to a .s file, and then change the rts to an rte there, and assembling it. Maybe I should buy Clay Walnum's book and switch to asm. More and more, it doesn't look like it'd be that hard. But in the meantime, I'd appreciate any help anyone could offer. Mike. ------------ Category 3, Topic 5 Message 34 Mon Jun 22, 1992 M.DORMAN2 [Mike Dorman] at 19:26 EDT I just can't quit coming up with new things: Someone please try to compile this program...I can't--without exception, I get two bombs (well, actually, the compiler tells me that there should have been two bombs...). #include #include main() { int count, plane; for (count = 0;count < 4;count++) { for (plane = 0;plane < 2;plane++) { printf("\ncount = %d, plane = %d",count,plane); if (count &= (1 << plane)) { printf("\nZork!"); } else { printf("\nNo Zork!"); } } getchar(); } Thanks, guys. Mike. ------------ Category 3, Topic 5 Message 35 Tue Jun 23, 1992 D.LIVINGST11 [Big Earnest] at 01:26 EDT Mike Dorman, > switch to asm. ...it doesn't look like it'd be that hard. Right. It's much simpler than C. Since your compiler has no inline assembler, you could stuff your asm routine into an array, and pass the array address to Xbtimer. addq.L #1,counter is 3 words: $52b9 ( or $5279 for addq.W if counter is 16 bits ) &counter high word &counter low word bclr #5,($fa0f).w is also 3 words $08ad $0005 $fa0f interrupt in-service register rte is just $4e73 These 2 instructions don't use any registers so there's no need to save & restore regs. Note your bclr.b #5,0xffff0a is the wrong address, and isn't 32-bit clean (do you care?) Better to use absolute short addressing for bclr bclr #5,($fa0f).W which is shorter and faster than bclr #5,($fffffa0f).L Maybe Sozobon will let you fill the whole array when you declare it: unsigned short TimerA[] = { 0x52b9, &counter >> 16, &counter & 0xffff 0x08ad, 0x0005, 0xfa0f, 0x4e73 } else you'll have to stuff &counter in there, possibly a word at a time. C is so awkward at stuffing a long into an array of words. I know it can be done, but I can never remember how. ------------ Category 3, Topic 5 Message 36 Tue Jun 23, 1992 CBARRON at 02:51 EDT > C is so awkward at stuffing a long into an array of words... why not struct { short a; long b; short c,d,e,f; }iter_data={0x52b9,0L,0x08ad,5,0xfa0f,0x4e73}; the the counter can be stored iter_data.b= (long)(&counter); with no arithmetic! Also Xbtimer uses &inter_data as function address. Not so 'awkward'. Cast is probably not needed with sozobon... ------------ Category 3, Topic 5 Message 37 Tue Jun 23, 1992 S.YELVINGTO2 [Steve] at 03:34 EDT Mike, my suspicion is that you forgot the #include math.h in your atof example. I did this: #include #include float floatTemp, floatXPos; char charXPos[12]; main() { strcpy(charXPos, "33.777"); if ((floatTemp = atof(charXPos)) != 0.0) { floatXPos = floatTemp; } else { sprintf(charXPos,"%f",floatXPos); } printf("%f, %s",floatTemp,charXPos); } ... and I got the following output: 33.777000, 33.777 On your window dimension problem, it's a little too late (2 a.m.) for me to apply any brainpower, but I compiled your example after changing aplx_init to appl_init and got this result: 0 19 640 381 1 38 638 361 1 38 624 361 2 39 622 359 Note that I'm using a monochrome monitor. On the interrupt-handling code, I can't be much help since I've sort of ducked dealing with interrupts. You can access C variables from asm fairly easily, so long as they're global/static variables -- just prepend an underscore to the identifier. If it's an auto variable, you're going to need to mess around with the asm output. I often find myself coding in C, and then fiddling around with the asm, rather than trying to remember how to write from scratch in asm. (Sozobon DOES support inline asm, of course.) ------------ Category 3, Topic 5 Message 38 Wed Jun 24, 1992 D.LIVINGST11 [Big Earnest] at 05:18 EDT CBARRON, Yeah, great idea about using a struct to hold the interrupt code. Maybe C ain't so bad after all, once you get used to it. ------------ Category 3, Topic 5 Message 39 Thu Jun 25, 1992 M.DORMAN2 [Mike Dorman] at 18:43 EDT First: Big Earnest and CBARRON: Many thanks, I hadn't thought of that. But it looks like it'll be easier than that, maybe. Steve: First: Perfectly right about forgetting about math.h. I figured that out last night. Thanks, though. As far as interrupt stuff, no problem, I know what I've got to do-- surprisingly, easy, I think. Sounds like I need to unpack the 1.33i archive and look at the docs for Sozobon (1.40 only has the deltas about the pieces, for size reasons (and the GemFast docs)) to find out about inline asm. About winx_calc: So, you get the same results I do (I used it on a mono monitor, too). Just for those that don't use GemFast, winx_get/calc just uses a GRECT for passing and receiving the values, rather than individual variables. And your results look just like the ones that I got--wrong. Gotta get to Ian on this one. There's just not enough room for a slider, an info line and a title bar in that 19-pixel difference between 38 and 19. There just ISN'T. Grrrrrrr. This is starting to irk me. I can hardwire the stuff, but that defeats the whole device-independent thing. Or I can just stick it out and live with this ugly band down the left side of the window. Oh, my aching head--on top of all this I spent five hours at work bringing a PS/2 Model 70 up as a server on the Novell network at work, and it's still not done. Mike. ------------ Category 3, Topic 5 Message 40 Thu Jun 25, 1992 C.HERBORTH [-Chris-] at 21:27 EDT Mike, I compiled your first program (after changing apl_xinit() to appl_init() and adding an appl_exit() at the end) and got this: 1 38 638 361 1 38 624 361 2 39 622 359 0 19 640 381 My setup: TOS 1.4, Ian's H&S 1.33i, Gemini 1.21. I tried to compile your second program, and got: compiler bug : machine exception: 2 bombs There was a missing } at the end of the code you posted, but that should give an error, not something like this... Do you (or Steve) know if Ian is going to add longer symbol names to the next H&S version of Sozobon? Any idea of when the new GEMfast will be unleashed? -Chris- ------------ Category 3, Topic 5 Message 41 Fri Jun 26, 1992 S.YELVINGTO2 [Steve] at 04:26 EDT Mike -- The Sozobon asm syntax is the same as Alcyon's: asm(".dc.w $a000"); ... one line at a time. If you can write your function in C, you can probably just end it with asm("rte"); ... although you could just as easily edit the .s file. Chris -- HSC 1.40 doesn't have long identifiers implemented. Ian has said he's looking at either using the SozobonX format introducted in Sozobon 2.0, or something similar of his own design. But not real soon. ------------ Category 3, Topic 5 Message 42 Fri Jun 26, 1992 M.DORMAN2 [Mike Dorman] at 22:34 EDT Chris-- Thanks for the testing. I've got to get that second program to Ian, ASAFP. There's something in that that just kills the compiler dead, and I've no idea what it could be. Andif it kills both 1.33i and 1.40, well, it may be pretty major. Let's hope not. The window test results are interesting, since they seem to actually make some sense. Not that it matters now. Ever have a revelation, sort of a "I could've had a V-8" moment? I realized the other day that there *IS* a VDI routine to just paint a pixel, without having to resort to a big blit. So I can get around this screwy winx_calc() behavior, since the only reason I was using it was because I was convinced that Line-A was the only way to just plot one pixel. Boy do I feel stoopid. Longer symbols are, I think, in the works, but not for 1.40 as it stands. New GEMFast comes out with the new compiler, I think. Assuming that we find the reasons for some of these problems, that shouldn't take *too* long, depending on Ian's schedule (which translates to, "I have no real idea, it's not actually up to me, and Ian's pretty meticulous about killing the roaches."). Steve-- Thanks, though I seem to have actually got a handle on doing the separate compilation thing. Ghod, I may learn assembler yet. Mike. ------------ Category 3, Topic 5 Message 43 Sun Jun 28, 1992 S.YELVINGTO2 [Steve] at 16:04 EDT The usual way to plot a single pixel is to use the polymarker function. Just don't ``poly.'' ------------ Category 3, Topic 5 Message 44 Mon Jun 29, 1992 M.DORMAN2 [Mike Dorman] at 22:42 EDT I'd have never thought of it, though, if I hadn't come across some code. Grrrrr. I added some functionality, and now the program bombs when I try to do anything after I finish a fractal. And szadb won't help because I end up hitting an event_multi without access to a mouse pointer (and the window doesn't come up, either). frm_qtext() may be my favorite addition. Imagine being able to do instant dialogs with frm_qtext instead of printf. Same format string, same varlist, and GO! Zowie do I love GemFast 1.8. Functionality out the wazoo. Just got to get this program working. Mike. ------------ Category 3, Topic 5 Message 45 Tue Jun 30, 1992 C.HERBORTH [-Chris-] at 20:49 EDT Mike, I've wanted a frm_qtext()-like function for about five years! Ahhhhh.... I hope the new GEMfast/Sozobon is released soon! Wow... Talk about handy for debugging... ------- 8< ------- Guru-types, I'm writing a GEM-based program now... In fact, I just finished the last section a few minutes ago. I typed make, and it compiled (wow!)... Then it came time to link, and I got: ld: Undefined symbol '_lonh' from module do_unmsa ld: Unknown symbol or bad symbol type '_lonh' cc: loader failed There is nothing in any of my files called "lonh", EXCEPT for do_unmsa.o... I'm baffled as to how it could have gotten in there. There's lots of casting between int and long in the section, but no typos. I've grep'd for lonh, and searched for it in Elvis and emacs and Tempus. It's in the .o but not in the .c... Did I overload some table in cc for keeping track of casting? -Chris- ------------ Category 3, Topic 5 Message 46 Tue Jun 30, 1992 JLS [John STanley] at 23:44 EDT Mike, If you want to try sending a test-email message to me, you should be able to reach me at: jls@dynasoft.mn.org I'll respond right away when I receive a msg so if you don't hear back from me in a day or two, let me know and maybe I can try sending you a msg to see if that works... You may have had problems in the past due to mail-feed problems and a switchover to a new mail-domain server. - - - Regarding the problems you listed... First, be sure you have a define for atof() in-scope when trying to use atof. If not, Sozobon will assume this undefined function -thing- called atof is returning an int with the appropriate garbageing of the value... You may want to include math.h... Regarding your "two bombs" problem, the braces aren't balanced... Sorry, but no simple answers come to mind about the inline asm problem or the problem you're having with winx_get (since I don't have gemfast 1.7 yet....). BTW, just inserting asm("rte") into a C function won't suffice if you've declaired local variables since the stack gets shifted on entry to make room for the local variables. You'll need to restore (unlink) the stack (and also restore any registers used for "register" vars) before making the rte call.... ------------ Category 3, Topic 5 Message 47 Wed Jul 01, 1992 C.HERBORTH [-Chris-] at 22:31 EDT I found my "_lonh" problem! I'm also glad to report that it wasn't my fault... ;-) In osbind.h the macro for Flopfmt has a (lonh) casting one of the arguments instead of (long)... Whoops! Now all I need to do is track down the bombs... :-\ -Chris- ------------ Category 3, Topic 5 Message 48 Thu Jul 02, 1992 M.DORMAN2 [Mike Dorman] at 18:45 EDT More sundry stories: Anyone got any experience with the Sozobon implementation of strncat? I've got the source code for Booz 2.0, and I'm planning to make it use GEM. But first, I want to get the code to compile clean and work right in the first place. Everything works except listing a file. There's a whole passel of strcat's and such, and 1 strncat that's misbehaving. I've pretty objectively verified this--printf'ing the string after every operation, and after the first time through that strnicmp, every subsequent time just kills it. So I've got to assume that the routine's buggy. Anybody else used it? BTW, Steve--did you get my mail last night? Mike. ------------ Category 3, Topic 5 Message 49 Thu Jul 02, 1992 M.DORMAN2 [Mike Dorman] at 19:57 EDT Chris-- Grrr, I wish I could get in touch with Ian. Tell you what--there's a program with 1.40 that's designed just for the purposed of scanning .o files for symbols. I can package it up and E-Mail it to you. I don't see how Ian could mind, and maybe it'll help. And, yep, frm_qtext is *incredibly* handy for debugging. I wish I had some nice solid programs to test this with--all the stuff I'm working with is "new" and therefore succeptible to operator error (read: my screwups). Usually I can track the problem down, but not always. F'r instance: trying to get Booz to work, strncpy seems *very* broken. But it could be me (though it compiled fine with GCC, so I doubt it). Just read farther downstream: Oh, guess you don't need that, then. I'll check the osbind.h in 1.40 for the problem. John-- The float stuff's just great these days. It's amazing what #include'ing will do for you. I just sent Steve a batch of stuff. I'll send you the same batch, probably tomorrow. I've sent you mail a couple of times before, so there shouldn't be a problem. I actually got the rte thing working with a separate .s file. And upon getting it working, decided that it was just more work than I could justify-- writing a sequencer when I'm not going to have the keyboard I'm borrowing now in 6 weeks, and having no idea when I'd be able to afford one of my own. But it was good experience. Mike. ------------ Category 3, Topic 5 Message 50 Thu Jul 02, 1992 J.BARTLETT10 [JERRYB] at 20:50 EDT hello out there I need some help. I just downloaded sozoboni33 and have installed. I'm new to programming in C and using the compiler so I'm having trouble just understanding how to work it. I read the docs and tried running the two exmple programs. The bin files are on E:\sozobon\bin and the examples are under E:\sozobon\examples. Using the CC.ttp program in the bin file Put in the following in response to parameters query "E:\sozobon\examples\hello.c" and this created a program hello.prg and did not show any error msgs. I ran the hello.prg program the screen went blank flashed a couple lines (too quick to read) and returned me to the desktop (neodesk). I expected to see hello on the screen or something. Doing the same with the FPMATH.C example , I ran the cc.ttp program and got the following error msgs undefined '_sqrt' undefined '_cos' undefined '_sin' unknown symbol or bad symbol '_sqrt' loader failed application exited with status 1 I also tried writing a very simple hello program that ran like the hello.c. I thought that to compile the progam and end up with an executable program all I needed to do was run cc.ttp in the bin file. Recognizing this is probably simple stuff, could someone just briefly walk thru what I need to do to compile a progrm.c to get an executable program.prg. Do I have to have a program.mak file??? Any help would be greatly appreciated as I'm trying to learn and this is frustrating. Thank you! ------------ Category 3, Topic 5 Message 51 Fri Jul 03, 1992 S.YELVINGTO2 [Steve] at 04:04 EDT Mike: I'll take a look at strncat. By the way, strtoul() is VERY upscrewed; it's the root of all evil under Gemini. I sent you and JLS a bugfix via Internet mail. I'm going to recompile the 1.40 beta binaries this weekend using a fixed library. I got the mail -- or rather most of it. I think the rest is sitting at tcnet, waiting for me. I had to pull the plug after an hour to use the phone.... Oh, by the way, I sent you a disk with the MicroEMACS sources. JLS: Better make room in your spool directory! This stuff is b-i-g! Sorry I didn't get back to you Wednesday or Thursday night; we had a bit of news Wednesday (the boat going over the dam in St. Paul) and I got drafted to lay out the front page Thursday. JerryB: If you'll add a call to Cconin() at the end of hello.c, the program will wait for a keystroke before terminating and you'll have time to actually read the ``hello, world'' message. The problem you're having with the fpmath.c example is simple: you didn't link the floating-point library. cc -f fpmath.c will do the trick. Optimally, DON'T use cc; just click on the .MAK file. Learn to write makefiles; MAKE is your friend. (I know, I really need to write a MAKE tutorial.) -- Steve Yelvington / Marine on St. Croix, Minnesota ------------ Category 3, Topic 5 Message 52 Fri Jul 03, 1992 M.DORMAN2 [Mike Dorman] at 18:52 EDT Steve: strtoul() is killing Gemini? Good--send mail to Ian. I mailed Bob Goff here, who's the comoderator of the atari.st conference on BIX, and told him to tell Ian to read his mail. I'll get the bugfix this afternoon. I wonder how well Ian's makefiles will fly under my setup? Set to recompile the whole puppy, I am. I'll probably just start a *BIG* make before going to work Saturday (lowly students don't *need* Federal holidays off...) and it should be done when I get back. There's a lot of stuff, and I apologize about the screwy naming. I looked and looked and looked for a UUENCODE for the PC (where I was sending from) that would so names like .uaa, .uab, etc. No can do. What I got was the best substitute. Did you use part of a command line UUX to create UUCODER? Would it be hard to hack the important parts out and make a nice program for MSDOS that would do intelligent naming, etc? Guess I'll find out later today... Hope to see the disk soon. John, the same stuff should make it to you this afternoon, I promise. The files are still sitting in my subdir on the network at work, all I gotta do is hop into PMail, and send 'em. Gotta wait about 10 minutes for it to finish, though. FWIW, it's abotu 1.2 MB, and then you've got to UUDECODE them, which is another commitment of .9MB. The binaries archive is only about 300K, though, and that includes docs. Jerry-- I don't know why Steve wants to write a tutorial on Make, since Ian included one with the 1.33i compiler. Look in the documentation directory for stmake.doc. Read that. Afterwords, you should be able to write simple makefiles. For starters, though, the simplest makefile you can have is: frobbotz.prg : Make knows about how to go from .c files to .prg files, so it'll automatically look for frobbotz.c and compile it. The only other thing you might want to worry about is something like CFLAGS. If you changed the above to CFLAGS = -f fpmath.prg : it would compile the fpmath program correctly. I strongly recommend that you use "install application" to let you double- click on make files and execute make. It makes your life bunches easier. You might also want to hand-alter your desktop.inf to allow you to double click on .c or .h files and have it throw you into your editor. That's how I do everything, and with a nice small editor like Tempus, it's near instantaneous. Mike. ------------ Category 3, Topic 5 Message 53 Sat Jul 04, 1992 S.YELVINGTO2 [Steve] at 02:19 EDT I just got mail from Ian -- he has the strtoul() bugfix. He hadn't tested the new XARGS routines. The old version didn't call strtoul(). About UUCODER -- I recycled the Dumas UUE/UUD sources. That's definitely the most reliable uuencoder around. It compiles under Misery DOS as well as TOS and Unix. I'll send you a copy of the sources; they're quite short. I can't find anything wrong with strncat() ... do you have a short program that demonstrates a failure? ------------ Category 3, Topic 5 Message 54 Sat Jul 04, 1992 C.HERBORTH [-Chris-] at 11:06 EDT Mike, I've been using strncpy() but never strncat() or strnicmp()... Works fine for copying strings into dialog STRING or TEXT objects. One sec and I'll see if strncpy() acts as advertised... Ok, I just whipped off a little test program to see how strncat() operates. Looks like strncat( dst, src, limit ) will copy limit characters from src to dst. I thought it would copy src to dst with limit being the maximum possible length for the string after the concatenation (ie, it would drop a \0 into dst[limit] if dst was longer than limit). Here's the program for your own fiddling: #include #include main() { char string[256]; int loop; strcpy( string, "This is a test." ); puts( string ); for( loop = 5; loop < 40; loop += 5 ) { strncat( string, "Land of tests.", loop ); puts( string ); } exit(); } And here's the first few lines of output: This is a test. This is a test.Land This is a test.Land Land of te This is a test.Land Land of teLand of tests. I expected to get: This This Land This Land Land etc ------- 8< ------- Mike, grep works good for scanning .o files... I've got the complete source to BackupST... The GEM front-end is what I'll use to beta 1.40, since I know it works... Maybe I'll get around to adding high density floppy support, too. The author released BackupST into the public domain last year (there's a mailing list in the land of unix, but I've forgotten the address... hasn't had a message in months)... -------- 8< ---------- Steve, write your MAKE tutorial! I spent too much time a couple weeks ago hacking together a makefile that worked properly for my current project... Now that I know how to do it, it's easy (and saves SO MUCH time), but getting there was difficult... The docs that Ian wrote for STMAKE seem to assume you already know how to make... With the added hassle of make.ini, it just gets confusing (like, is there ANY way to temporarily add a C switch when you compile? like add -DDEBUG one time and just normal the next?) -Chris- ------------ Category 3, Topic 5 Message 55 Sat Jul 04, 1992 M.DORMAN2 [Mike Dorman] at 11:49 EDT I got the bug fix. I was going to apply it, and start a major recompile. Would the Dumas stuff have been released in comp.sources.atari.st? I found something called uuduue.Z, which was a shar file, which seemed to be said sources. It has #ifdef's for MSDOS, etc. I haven't sat down and written a short program to deomstrate the problem I think I've found with strncat(). However, Ian's got the sources to Booz, and they show the problem remarkably well, so I'm not too worried. I may develop a little problem-demonstrator tonight after work (yep, us students have to work on July 4). Mike. ------------ Category 3, Topic 5 Message 56 Sat Jul 04, 1992 M.DORMAN2 [Mike Dorman] at 12:09 EDT Chris-- I need a good grep. Heck, I need a good grep with a GEM-front-end that works as a desk accessory. I would use grep a lot if I had one of those. So which one of you's going to write it for me :-). Heck, I'll be nice--all I need's an fgrep. How fast is Backup ST? How reliable? Does it use normal floppy format, or is it image backup stuff? I might be interested. As nice as Turtle is, it's @$^$@& *5* files for a HD Backup program. Insane. Maybe Ian had some additional docs in the standalone release of Make, because I had a really good tutorial from him on how to write 'em. Of course, now I have the complete docs to GNU Make. The only problem is figuring out what stuff STMake will and won't do that GNU Make will. But it also has a pretty good tutorial section. Oh, Chris--put some dummy flag in your compile line, something like: $(CC) $(CFLAGS) $(THURBER) $< -o $@ $(LIBS) Then hold down the shift key when you double click on the make file. When it asks for parameters, enter THURBER=-DDEBUG. You probably want to make it the last parameter before the file names, since I believe that HSC takes the last value for a particular parameter, and discards the rest. That oughter work (though I _just_ thought of that as I was typing, so I may be wrong). I think Ian once suggesting something specifically like this to me. Mike. ------------ Category 3, Topic 5 Message 57 Sun Jul 05, 1992 S.YELVINGTO2 [Steve] at 15:04 EDT uuduue.z probably is the right one. I just mailed uuduue.zoo today, along with wd.zoo (Bill Silvert's improved uud). The Harbison & Steele 2nd Edition description of strncat says: ``If no null character appears among the first n characters of s2, then the net effect is that the first n characters of s2 are copied and then a null character is supplied to terminate the destination string; that is, n+1 characters in all are written....'' It also warns against overlapping strings. Nifty shift-double-click trick. I didn't know the Desktop would do that. About MAKE documentation -- I was thinking about writing an intro to make for people who have no idea what it is. If you don't understand what make is supposed to do, the docs are going to leave you at sea. I get mail periodically from someone who has downloaded the compiler and can't quite understand how all of those pieces fit together, or why it's necessary to have so many parts. ------------ Category 3, Topic 5 Message 58 Sun Jul 05, 1992 M.DORMAN2 [Mike Dorman] at 17:30 EDT I feel like such a rube...just a preface... The source to my fractal program finally started to get unwieldy--about 17K. So I decided to split it into several chunks. Now, one problem with this is the fact that it's got a *LOT* of global variables. I know it's bad programming practice, but it was the only way to keep from having to pass seventy bajillion things to different functions because they have to call other functions which need certain information that the function that's gonna call them doesn't. So, I said to myself, I'll just put all the variables in one include file. Depending on a what a module #defines before it included the file, I'll include the variables as either regular variables, or I'll declare them "extern"...seems simple enough, and heaven knows that I know these variables well enough to keep them straight. So I did all this. Just split about five strictly window-related functions into another file. Made some #ifdef's in the main include. Everything seemed to work until I tried to run the silly thing. No errors on compiling or linking, but when I try to run the program, two bombs. So I hauled out SZADB 2.1. It's an assembly debugger. I changed the makefile to make the compiler not strip out the symbol table, and recompiled. When my program tries to call the AES, it croaks. I can't figure out why for the life of me. This all happens before the program has a chance to do anything--it is literally in the first line of the program (which is a small function to set up some GEM stuff...and it only seems to get to the first line of that...). I'm open do ideas. Most of the stuff that I do is so small that I never get more than one file out of it. The wierd thing is: Before doing this, I decided to do some testing--I'd tried to do the same thing before (last week) and had gotten similar bombs, but I figured that I was screwing something up. And the test program had had similar results, but again, I figured it was me. So here's the test program. It's about as short as I could get--just three files: This is test.h: #include #ifdef TEST1_C extern int wombat(); char slime[]="This is a test"; #endif #ifdef TEST2_C extern char *slime; #endif This is test1.c: #define TEST1_C #include "test.h" main() { int temp; temp = wombat(); printf("%s = %d",slime,temp); } This is test2.c: #define TEST2_C #include "test.h" int wombat() { printf("%s\n",slime); return 5; } This is the makefile I was using: test.ttp : test1.o test2.o cc -o test.ttp test1.o test2.o $(LIBS) Needless to say, I'd appreciate any help you guys can offer. I'm about to run the test program through szadb, and see if that offers any help. I think I'm declaring stuff correctly, so I'm stonkered. Mike. ------------ Category 3, Topic 5 Message 59 Sun Jul 05, 1992 M.DORMAN2 [Mike Dorman] at 17:34 EDT Steve-- It's not the desktop that does that nifty shift-double-click thing, it's MAKE. Ian liked the idea of being able to give MAKE some commands "real-time" so he made the shift key the signal. Mike. ------------ Category 3, Topic 5 Message 60 Sun Jul 05, 1992 M.DORMAN2 [Mike Dorman] at 18:17 EDT Well, I ran test.ttp under SZADB. printf() is starting to look like the culprit. More specifically, strlen() when it's called from printf(). Here's the transcript of what I did (this is after several rounds of testing to narrow down the problem). > strlen:b > :c break at _strlen _strlen: move.l 4(sp),a0 > :s _strlen+4: moveq #-1,d0 > _strlen+6: addq.l #1,d0 > _strlen+8: tst.b (a0)+ > trap: bus error user data r addr 54686973 instr 4a18 > $> I set a breakpoint at strlen, and ran flat out until I hit the breakpoint. And the rest is history. I guess I should do it with a full register printout and send it to Ian, unless one of you guys has something to suggest... Mike. ------------ Category 3, Topic 5 Message 61 Mon Jul 06, 1992 CBARRON at 01:41 EDT extern char *name and extern char name[]; are not identical! In one file you define slime as an array in another as a char *. does extern char slime[]; work??? Something like this. /* test.h */ #ifdef TEST1 char slime[]="Welcome to slime ball!"; #else extern char slime[]; #endif As to sombody's strncpy and strncat function queries strncat() always should null-terminate the resulting string. Strncpy copies EXACTLY n bytes. If a null('\0') is found the result is null padded if a null is not found strncpy() does not null-terminate the result, according to the ansi standard, and any C compiler I have used.If you are building a string via strncpy fill the receiving area with '\0's first. As in memset(buffer,0,sizeof(buffer)); ------------ Category 3, Topic 5 Message 62 Mon Jul 06, 1992 JLS [John STanley] at 10:13 EDT Steve, I haven't been able to do anything with the 1.40 beta yet because I haven't received anything from Mike and the version I got from you had those archive problems... Maybe we could arrange for me to drop by the office again sometime this week? (Maybe after you finish including the changes you're working on to strtoul? :^) ... JLS ------------ Category 3, Topic 5 Message 63 Mon Jul 06, 1992 M.DORMAN2 [Mike Dorman] at 19:10 EDT CBARRON: Thanks. I'll try your fix. Mike. Later: It works! Thanks bunches. As usual, my screwup. Oops. I figured that it would be, for all intents and purposes, allowable to declare the variable that way. Guess I've got egg on my face. Mike. Nother update: My fractal program's working swimmingly, now. Thanks. Just for the record, what's your first name, if you don't mind my asking? It feels wierd to just refer to you by your handle. Mike. ------------ Category 3, Topic 5 Message 64 Mon Jul 06, 1992 M.DORMAN2 [Mike Dorman] at 19:25 EDT John: Sorry--I found out Sunday that the copy I had left on the network for distribution purposes had in fact, been deleted, and then purged. And I haven't been back with a disk with the software on it since I found out. That's why Chris doesn't have a copy, either (well, that and the fact that I keep forgetting to take a copy of his address into work). Mike.1 ------------ Category 3, Topic 5 Message 65 Tue Jul 07, 1992 CBARRON at 02:03 EDT Mike arrays and pointers are commonly confused to be the same. They are similiar but not the same as we have just seen. Carl. ------------ Category 3, Topic 5 Message 66 Tue Jul 07, 1992 D.LIVINGST11 [Big Earnest] at 04:06 EDT Mike D, If you get a bur error on _strlen+8: tst.b (a0)+ then a0 is bogus, and probably null. Since a0 was loaded with _strlen: move.l 4(sp),a0 then you should look at the last param passed in the call to strlen() i.e. before you call strlen(x), put in some debugging code to examine what x is. It should be 32 bits, and not 0. ------------ Category 3, Topic 5 Message 67 Tue Jul 07, 1992 D.LIVINGST11 [Big Earnest] at 04:07 EDT Mike D and everyone I'm curious about how you experienced C programmers declare/define your global vars and functions in a big program with lots of source files, where everything's types are changing during development. Does it make sense to define them all in one file, and #include a version of that file (with all vars' definitions made extern using #if xxx or a compiler option) in every file? Or is it better to define them in various files? And better to put "extern whatever_T foo;" within any functions that use them? And for functions: do you #include a file containing all the declarations (or prototypes) at the top of every file? Or do you put extern function declarations inside functions as needed? ------------ Category 3, Topic 5 Message 68 Tue Jul 07, 1992 M.DORMAN2 [Mike Dorman] at 09:53 EDT Big Earnest-- Well, I'm not that experienced, but now that I'm starting to hit critical size on single file programs, I've actually had to start having multiple files. What I've ended up doing is making a big .h file that has all the globals declared in it. For each variable, there's a #ifdef MAIN_C, where in it is declared normally. And then there's an #else, where I declare the stuff as extern. I find it works for me--especially when I really don't want to have to pass a bajillion parameters... Mike. ------------ Category 3, Topic 5 Message 69 Tue Jul 07, 1992 STARFALL [Alan] at 20:43 EDT For a lot of global variables, I use two files -- a .c file where the variables are declared, and a .h file where they are defined. The .h file is #included into each module, and the .c file is compiled and linked with the rest of the modules. For example: /* GLOBALS.C */ char msg[] = "This is a test\n"; /* end GLOBALS.C */ /* TEST.H */ extern char msg[]; /* end TEST.H */ /* TEST1.C */ #include main() { printf("%s", msg); do_other_test(); } /* end TEST1.C */ /* TEST2.C */ #include do_other_test() { printf("%s", msg); } /* end TEST2.C */ Compile it with "cc -o test.prg globals.c test1.c tet2.c". The only real trick is keeping the .h and .c files the same. If you change one file from "char" to "int" but not the other, you'll have big problems. / / * / Alan * * ------------ Category 3, Topic 5 Message 70 Tue Jul 07, 1992 J.BARTLETT10 [JERRYB] at 21:19 EDT TO: Steve Yelvington, Mike Dorman Thanks for the information, its been very helpful. I'm writing some simple programs and running using the cc program and they are working. I'm working my way up to make files but haven't got there yet. Steve, interesting to note your from marine on the St. Croix -- I used to live in Chisago City by Taylors Falls -- I expect to be moving back sometime in the fall (from Washington D.C. ). I didn't know you could still get Atari stuff up there in Minnesota/ Wisconsin. Thanks again! ------------ Category 3, Topic 5 Message 71 Thu Jul 09, 1992 M.DORMAN2 [Mike Dorman] at 05:11 EDT Steve-- Got your message about your HD. Does this mean that things at Yelvington manner are (computer-wise) at a standstill? Or was the node running on a second machine? Also got the disk today. Even had the foresight to not do something stupid like trash the envelope and lose the address. You Should Be Proud. I've also played with the program a bit. Kudos to John and Dale &c. Now, to the important stuff. I don't know if anyone else reads the "Ask _ANY_ Programming Question" topic, but I posted something over there a couple of days ago, looking for some sort of code library to simplify text output to a window. No responses so far, and I gather there probably won't be any. So, in the normal way around here, I decided to do it myself. There is certanly a purpose. I have to have these routines to make a truly GEM-ized Booz. And I'd really like to have a grep that runs as an accessory (I found a nice small source file for one the other day, looks like a good candidate, it's set up so that defining things as globals to ditch any memory allocation may well work). And some other things, all of which seem to require that I re-invent the wheel with regards to what should be (it seems to me) a relatively painless function of the OS (I've heard that MAC text is pretty easy to manipulate in windows. Of course, it doesn't have any other options...). So. The way I see it, this would have to be an extension to the GemFast stuff (well, not necessarily GemFast-based, but it's what I use, and this is an appropriate topic...). So I propose a bunch of new winx_XXXX functions. Maybe Ian'll like 'em so much that he wants to incorporate and release them (though he seems to have his own stuff in the works. Checked out Browser?). My first priority is to write some stuff that just makes handling windows a bit easier. Stuff for opening and closing at first. Not too hard, but I want them to take the business of remembering to clear the window with vs_recfl() and such off my mind. Then I want some routines that'll treat the window as a pseudo-terminal--text output with intelligent scrolling routines (Just blit a section up and write a new line at the bottom, &c). Cursor positioning (or at least text positioning using character coordinates. Heck, I'd like some routines to let people build "button bars" at the tops of windows. I actually like that little Windows-engendered idea. Is there any commentary that anyone else would like to offer? Am I off my nut? Any offers to help? Bug-test? Anything? Mike. ------------ Category 3, Topic 5 Message 72 Thu Jul 09, 1992 C.HERBORTH [-Chris-] at 20:57 EDT Mike, I got a grep and fgrep from atari.archive... Unfortunately, I haven't got any desire to make it run in GEM instead of TOS, or turn it into an ACC... ;-) Maybe Steve will write it. Backup ST isn't too bad... I think it uses its own file format, but it doesn't do image backups. It used to choke on a "&" in a filename though (I had about 10M of clip art online once, stuff like hand&bag.gem). I'd really prefer something that used normal files, but I guess that's the beauty of having the source... ;-) I'd also like to work in file compression some time, probably via an external arc, lharc, zip, zoo, arj or compress, since compression algorithms give me nightmares... The problem with your Make hint for getting a C option sometimes (which was $(CC) $(CFLAGS) ($STUPIDVAR) $< -o $@ $(LIBS)) and then running it with shift held is that I run make from a command line (the Mupfel shell, usually from within Gemini). Ah well, I can live without I suppose. Still, it'd be nice to go make -DDEBUG and have -DDEBUG passed to cc. Is there any way to get variables like in shell scripts? Hmm, that doesn't sound too coherent... You'll figure it out, you've been looking at dlibs source... ------ 8< ------ Steve, your idea for a Make document that assumes you have no clue would be *great*! Would have saved me a few hours (well, maybe I'm exaggerating a little) of fiddling. -Chris- ------------ Category 3, Topic 5 Message 73 Thu Jul 09, 1992 C.HERBORTH [-Chris-] at 21:19 EDT Mike, here's some window routines I'd like to see: A windowed puts() or printf() [maybe the print() stuff Ian has cloned for the new frmx_dialtext or whatever thingy would be handy] that would draw your text, and (depending on a passed flag) wrap it to the next line in the window. An advanced version of the puts()/printf() that would handle GDOS fonts, the three system fonts, etc, special effects, justification, etc, etc... How 'bout curses in a window? That'd make porting some things much easier... Much work there though. -Chris- ------------ Category 3, Topic 5 Message 74 Fri Jul 10, 1992 S.YELVINGTO2 [Steve] at 03:11 EDT JERRYB-- There are a couple of dealers still in business up here in the great frozen north -- a regular computer dealer in White Bear Lake and a music store in Roseville come to mind, but there probably are more. MAST, the Minnesota Atari ST user group, meets monthly in Falcon Heights and runs a BBS with Usenet and Internet email service. Mike -- I'm at a semi-standstill. Right now I'm running Aladdin off a RAMdisk. I can't do anything useful with HSC until I get the hard drive working again; all I have is one SF354 floppy. Oh, by the way, JLS stopped by the office tonight and picked up another (good) copy of the beta version, so he may have some bug reports soon. About the window output -- did Ian give you sources for a file browser program? Looks like he's making some little steps in the direction you outlined. Chris -- Curses in a window? I hope it'd be faster than the non-windowed curses I used to compile Anthony's Editor (with HSC) just before my hard disk died. The editor works, but it's so slow as to be almost unusable. Reminds me of the time I tried running WordStar over a 300bps modem link back in the CP/M era. ------------ Category 3, Topic 5 Message 75 Fri Jul 10, 1992 M.DORMAN2 [Mike Dorman] at 20:24 EDT Chris-- Are you sure that you can't hold down the shift key and enter a parameter? MAKE checks that first thing ONCE IT STARTS. It really oughter work, honest. [Editors note: It didn't. Well, first off, I couldn't run make from Mupfel. Oops. Then I tried it from the command-line in Emacs 2.19b. Still didn't work, but, looking at the command summary, you can define things there just by typeing DEBUG=1 or whatever. I think that solves the problem. In fact, I just checked, and you can go CFLAGS=-v or whatever, and it works fine. So all you would have to do is type DEBUG=1, I think.] Also, I think STMAKE supports sticking environment variables in the commands. So you could add a variable like $(DEBUG) somewhere in your makefile, and if DEBUG was defined in the environment that MAKE is passed, it would show up. You'd probably have to do something like "setenv DEBUG 1" to make sure that it was defined as having a value, though. [Editors note: I was wrong about this, too] Oh, and WRT some windowing text routines-- A windowed puts()/printf() was almost exactly what I was thinking of. I might or might not go for line wrapping at first blush, though. I think I may have hit upon a gold mine--or more like a map to one, written in Russian. It's the source to MW2, which is a MiNT based utility that lets you open multiple "terminal windows" and run shells and programs and things in it. Unfortunately, Allan Pratt doesn't seem to have believed much in comments. We'll see. Steve-- Hope the HD prob isn't permanent. I'm glad that John got the stuff today--I apologize to both him, and you Chris--I said I'd get that stuff out, but it's just been like a Marx Brothers comedy this last week, what with new classes and a new work schedule and such. Yep, I an included sources for a file browser--part of his OOC direction. Sort of impenetrable. I'm going to bother him for some docs in the next couple of days. Even just sketchy stuff would help. So, you gave AE a whirl? Is it any good? I haven't felt like screwing with the MiNT libs, which is the only place I know of that would have a curses for HSC. I'll get those disks in the mail on Monday, latest (earliest, too...). Mike. ------------ Category 3, Topic 5 Message 76 Fri Jul 10, 1992 C.HERBORTH [-Chris-] at 23:16 EDT Steve, WordStar over a 300 baud connection? Yuk... I get frustrated with vi over a 2400 baud link... *shudder* I grabbed a curses package from atari.archive, and compiled it. The demo that came with it didn't seem too slow, but then again, I've never actually _used_ curses... It's a just-in-case thing. Kinda like the XBRA and VBI code I've got (also from atari.archive). Good luck repairing the hard drive! Luckily, I've got two mechs in my setup, so if (when) one dies, I won't be quite as dead in the water... I'll still be stomping up and down the halls swearing though! :-) -Chris- I promise not to bug Mike about forgetting to send me the beta goodies... ------------ Category 3, Topic 5 Message 77 Fri Jul 10, 1992 C.HERBORTH [-Chris-] at 23:46 EDT Mike, You might want to look for the sources for the uw comms program... That's what mw was before Alan Pratt made it work locally for MiNT shells. I might be a little clearer (then again, it might be a little clearer in _German_)... -Chris- ------------ Category 3, Topic 5 Message 78 Sat Jul 11, 1992 M.DORMAN2 [Mike Dorman] at 11:21 EDT Chris: The UW stuff is, unfortunately, even more impenetrable than MW2. I looked. I just about *live* on atari.archive. If the fgrep you got was uploaded about December 1991, then it's *my* port :- ). I want one that doesn't make me get out of the GEM program I'm in, though. Although, GREP.TTP runs like a mother inside of Emacs 2.19b--and that may be all I ever need. Mike. ------------ Category 3, Topic 5 Message 79 Sat Jul 11, 1992 S.YELVINGTO2 [Steve] at 11:54 EDT I compiled AE mostly just to see if I could churn up any bugs in the HSC libraries. The editor is fairly primitive. The only notable item is that you can switch between EMACS-like behavior and vi-like behavior. I'm not sure that's a feature. :-) ------------ Category 3, Topic 5 Message 80 Sat Jul 11, 1992 C.HERBORTH [-Chris-] at 12:56 EDT Mike, FGREP TTP 32,822 Thursday, July 11, 1991 7:19:24 pm Is that yours? Or did you do the porting after that? I've also got an egrep from 1990... I should clean out \bin, I've got programs there I've *never* used! :-) Must be _nice_ to have a full Internet account... I curse and swear daily that I can't ftp out of the plant at NCR. Telnet would be real sexy too, then I could attach to the NeXT at the University and do some QRT ray tracing real fast... -Chris- ------------ Category 3, Topic 5 Message 81 Sat Jul 11, 1992 M.DORMAN2 [Mike Dorman] at 23:23 EDT Chris-- I think so. I don't even remember when I did the port, and I just recently started drastically downsizing stuff on my HD. I do that occassionally. I'll go through periods of Un*xness, and then not use anything but GEM for months. I think the one constant floating between the two has been EMACS, in one form or another (GNU or Micro)--I know the keystrokes as well as or better than those of Wordstar, which is what Borland uses...and that's all I use to program at work. One day, I'll probably go to the trouble of remapping those to Emacs commands. Steve: I could just never, ever, get into VI. Such an odd approach, one that I don't find intuitive at all. Then again, a friend who does most of his work on MSDOG platforms with Borland products (WordStar editing commands, so much like Emacs) can't stand Emacs, and uses VI whenever he's near Unix. That's the case that I can't figure out. Oh, I was asking about AE because, well, there's that old dream of hacking together a simple, efficient, GEM-Based editor "module". The one that Ian and Bob Goff and I dreamed up one night during the BIX equivalent of an RTC. It's never gone away, even though it's been shoved off the backburner even, and on to the countertop. I think I mentioned it to you, once. Maybe if I can get this window stuff done, and then get with Ian and do some serious interface designing, and hack some of the guts out of AE, maybe we'll get it done eventually. Mike. P.S. I just had a horrid realization a few days ago. In about a month, I'm not going to be a student any longer. I'm not going to have my cushy job any longer. I'm not going to have my Internet account any longer. Either of the last two might change/be replaced, but when you come down to it, it's kinda scary. At least there will still be GEnie. And once I get a new job, I'll be able to get back on BIX and hack around with Ian much more efficiently. ------------ Category 3, Topic 5 Message 82 Sun Jul 12, 1992 M.DORMAN2 [Mike Dorman] at 13:16 EDT Well, I've got a relatively "dumb" version of my winx_lib up and running. Haven't drop tested much of the error correcting code, really--it's not terribly intelligent about how it handles errors: most of it just gives you a message and dies, but the rest of the library doesn't check to see if something died. Next revision or three. This program, in conjunction with the library, will print stuff until you tell it to quit, and scroll the window appropriately (note that a good half the code is just some setup stuff and something to ask a question as to whether to continue or not. The actual library routines are the things that are prefaced by winx_): #include "winx_lib.h" #include main() { int vdihandle; Window ws; apl_xinit(); vdihandle = apl_vopen(); frm_defaults(FRM_MOUSEARROW|FRM_CENTER|FRM_USEBLIT|FRM_MOVEABLE); frm_enableblit(); apl_mmvectors(lalloc,free); winx_init(&ws); ws.type = CLOSER|FULLER|MOVER|INFO|NAME; winx_open(&ws); winx_clear(&ws,vdihandle); do { winx_outstr(&ws,vdihandle,"Hey!"); winx_outstr(&ws,vdihandle,"Hey!"); winx_outstr(&ws,vdihandle,"My!"); winx_outstr(&ws,vdihandle,"My!"); winx_outstr(&ws,vdihandle,"Rock and Roll will never die!"); } while (frm_question("Continue?")); frm_qtext("Waiting"); winx_delete(&ws); apl_vclose(vdihandle); apl_xexit(); } *I* think it's pretty neat :-). Not a big library at all. What's more, there's only about two places that it's actually tied to GemFast 1.8 (and although there's several more places where it's tied into GemFast, most of that amounts to a dependence on several easy-to-get global variables). Don't have backward scrolling set up yet (but that shouldn't take very long to build in), and it's hard-set to scroll three lines (I had it set to scroll 1, but it's just not quite fast enough). But I think I'm going to do what Ian did with GemFast in general, and give it a set of globals to determine some behavior: things like when to scroll, etc. And the output function is pretty much a putstr() replacement right now--it puts the text you give it on the screen, within the bounds of the window, and scrolls if appropriate. I'm working on a more printf()-like routine, and it'd be nice if it would do wrapping of text within the window. I wonder if it would be faster if I did clipping myself? Actually, I'm sure it would be, but I'm wondering if the gain is worth it...anyone have any figures on the speed difference? Well, it's back to the grindstone. Chris, I'll get that stuff to you tomorrow, and I'll probably include a copy of this lib. Heck, if things continue to go as fast as they have, I'll be uploading it here soon so you can all check it out, improve, heckle, whatever. Just to keep you updated. Mike. ------------ Category 3, Topic 5 Message 83 Sun Jul 12, 1992 S.YELVINGTO2 [Steve] at 17:01 EDT >I think I'm going to do what Ian did with GemFast in general, and give >it a set of globals to determine some behavior: things like when to >scroll, etc. Would it make sense to build that into the Window structure? Then you could modify that behavior on a window-by-window basis. ------------ Category 3, Topic 5 Message 84 Sun Jul 12, 1992 M.DORMAN2 [Mike Dorman] at 21:33 EDT Hmmmm. Hadn't thought about that, but it makes a certian sort of sense...:-). Heck, it's not *that* big, yet. I wish I had C++. I could use some dynamic late-binding + inheritance. Then you could use some of the same variables for displaying and scrolling bitmaps. But then I'd have to use GCC. Too big. Oh, well. Maybe I can work around that. Just make the structure bigger! Yeah, that's it! Is anybody interested in this? I've got a couple more routines I may add tonight/tomorrow, but they're quick hacks--just stuff for resizing, etc, which have to be set up to keep the window's structure contents up to date. Could someone explain the va_args stuff to me? None of the books I have tell me anything. I'd really love to build a winx_printf(). Maybe I should look into ripping out the guts of the printf() in dlibs (or libm, now that I think of it. I wonder if the fp code is that much more baggage). Well, enough nattering. Mike. ------------ Category 3, Topic 5 Message 85 Mon Jul 13, 1992 CBARRON at 02:04 EDT Mike Dorman I would like to see source to a good text windowing library. Preferrably not 'too closely tied' to GemFast bindings and special functions. I don't use sozobon/gemfast myself... Re stdarg.h va_list is a type to store some infromation about the argument list. (it is PROBABLY typedef char *va_list; as it is in most M68000 headers I have seen. va_start starts the getting of variable arguments, va_arg() gets the next arg and va_end() cleans up the processs. example: #include char *strxcat(char *string,...) { char *hold=string; /* concatenate an arbitrary # of strings arg list ends with NULL */ /* as in strxcat(string,"this","is","text",NULL); */ va_list arg char *p; va_start(arg,string); /* va_start args are the va_list and the last fixed parameter */ while((p=va_arg(arg,char *))!=NULL) /* va_arg parameters are the va_list and the type of the argument */ strcat(string,p); va_end(arg) /* parameter is the va_list */ return hold; } ------------ Category 3, Topic 5 Message 86 Mon Jul 13, 1992 CBARRON at 02:07 EDT re:winx_printf something like: (assuming an ansi like library). #include #include void windx_printf(WINDOW_STRUCTURE *w,char *fmt,....) { va_list args; char buf[BUFSIZ]; va_start(args,fmt); vsprintf(buffer,fmt,args); va_end(args); winx_outstring(buffer); } ------------ Category 3, Topic 5 Message 87 Tue Jul 14, 1992 M.DORMAN2 [Mike Dorman] at 05:27 EDT Chris-- Didja get the stuff? Steve-- Ever done any work with archiver source code? I've got BOOZ about 95% finished, but I just realized that it doesn't support extracting subdirectories, and I'm really looking for someone with some experience before I go hacking bits out of the main ZOO code to make this stuff work. Maybe Bill Shroka does. Mike. ------------ Category 3, Topic 5 Message 88 Tue Jul 14, 1992 M.DORMAN2 [Mike Dorman] at 19:25 EDT CBARRON: Thanks for the stuff with the va_list information. I've got to sit down and actually decide how much work it would be to decouple the winx_lib from GemFast right now. Not too much, but there would be a good bit of extra work...maybe I can look into including the C-based AES Utility functions from GemFast that I use in the winx_lib. Mike. ------------ Category 3, Topic 5 Message 89 Wed Jul 15, 1992 S.YELVINGTO2 [Steve] at 02:36 EDT I haven't tried to compile the ZOO or LHARC sources ... yet. I stared at the ZOO 2.1 sources for awhile the other day. They look pretty clean. Originally I had thought that it would make sense for main() to call a gem_main() routine if there were no args, and gem_main() could build an argv list and recurse through main() to do the work. But after looking at the sources, they're so logically laid out that there's no need for that sort of monkey business. But I won't be compiling anything until I track down a power supply so I can get my hard drive back into action. ------------ Category 3, Topic 5 Message 90 Wed Jul 15, 1992 JLS [John STanley] at 04:44 EDT Chris Herborth, Regarding your -DDEBUG question.. Well, if you define an environment variable in your shell, then you _should_ be able to use that variable in the cc command in your makefile. (I only say "should" because there are several versions of MAKE for the ST and a couple of them don't support auto-import of environment variables.) On the other hand... I'm fairly sure the Make that comes with Sozobon _does_ support auto-import because I have: set CFLAGS=-O -v in my shell startup and I ocassionaly modify the envar to: set CFLAGS=-v when I know I'm going to need to go thru a series of quick compiles when I'm working on something fairly complex. (Removing the "-O" tells cc to omit the optimizer pass...). For your example, just make sure you don't define CFLAGS in your makefile and change the CFLAGS shell variable to include -DDEBUG=1 (or whatever cc options you want) as you please. - - - Sozobon users in general, PLEASE NOTE! My comments below regarding bugs in dLibs are not related to any of the versions currently in public release. Ian had some problems since the most recient release and the library included with the beta test has a few glitches in it. If you're not a beta-tester, you can skip the remainder of this msg... - - - Mike Dorman >I've also played with the program a bit. Kudos to John and Dale &c. Assuming you mean me Mike, thanks... Errr... Exactly what program are we talking about? :^) - - - Steve and Mike, On the subject of the HSC beta-test version, I've finaly got the files installed in their own folder(s) on my hard disk and have started the, what appears to be, long process of examining the libraries for what's been changed and finding bugs. So far, I've found literaly dozens of places where either Ian has, for some odd reason, removed errno support from most of the functions (which I doubt) - OR- it appears he's working from what were at one time dLibs _1.1_ sources... (shudder...) I'm doing a detailed evaluation (which will probably take a couple of weeks) and will try to come up with a corrected set that combines the best parts of each. BTW, For the moment, vvoid use of any of the forklp(), forklpe(), and forkvpe() functions. They're all broken. It appears Ian got confused and munged the arguments to pfindfile()... Also, Mike... Ian broke fclose() when used with setvbuf(). Please relay to Ian that fclose() is -NOT- suppost to free() a buffer imposed on a file with setvbuf(). The only exception to this, is if the buffer pointer passed to setvbuf() is NULL and then, setvbuf() itself is suppost to malloc the buffer (which, BTW, is a setvbuf() option not supported by the current version of dLibs (1.1, 1.2, or his current version...)). Iff this happens, then this type of auto-created buffer is the only kind fclose() should free(). (I'll correct this in the combined lib I'm working on.) Regards, ... JLS PS: Mike. I've got (binary only) some version of FGREP for the ST that works fine only as long as I'm grepping one file. It doesn't handle wildcard file expansion on it's own (appears to expect the shell to do the expansion for it..) Is that your version? If so, any cance of an update that handles wildcards? If this is not your version and your verion does support file wildcards, could you post your version? ------------ Category 3, Topic 5 Message 91 Thu Jul 16, 1992 C.HERBORTH [-Chris-] at 00:57 EDT Mike, I go through the command-line/love-gem sequence every so often, too... Lately it's been fixed by using Gemini, which gives me both at once... ;-) Congrats on being about to graduate... I won't be done 'til next April or so, a time that I'm eagerly awaiting (can you say "Income" and, more importantly to a nerd like me :-), "Unix account"; pity it's not a full Internet site)... ------ 8< ------ Wow, are you ever fast at hacking together those window routines! I've always shied away from windows (Tim Oren's ProGEM series did that to me.. the section on AES redraws and windows was hellish!) Can you swipe the brains from frm_printf() in the AESFast source? I'm not help here either, the va_args stuff makes me twitch... ;-) HOWEVER, we are getting some funky sound routines up here... Once they're stable, I'll email 'em to everyone with unix accounts, to see if they like them... Should be nifty to have a USERDEF object that plays a sample instead of drawing something... Somebody'll have to keep me from using my "Darth Vader's Theme" from Star Wars in a 10k program, it's at least 150k... :-) Another thing I'm half-planning in my head is a little utility program... A makemake.prg that would build nice makefiles for people, and use a sexy GEM interface. With any luck, it'd help out the people that don't have a clue about make... (Yes, I'll figure the rest out completely before I do this... :- ) I'll even read make(1) before I do it!) ------ 8< ------ Mike, got the goodies. Steve, any chance of you whipping up an efficient unLZH? I know those unix sources will handle -lh1- through -lh5- (assuming they're the same ones I have), and most of the people around here really miss using unLZH instead of the (larger and harder to control) Questor LZH. I was going to try it some day, but doubt I'll have time RSN... -Chris- ------------ Category 3, Topic 5 Message 92 Thu Jul 16, 1992 S.YELVINGTO2 [Steve] at 04:37 EDT JLS: I sent Mike the sources and (I think) binaries to MicroEMACS 2.19b. Chris: Not until I get caught up with a bunch of noncomputer projects (such as painting the kitchen) and get a new HD power supply. ------------ Category 3, Topic 5 Message 93 Thu Jul 16, 1992 M.DORMAN2 [Mike Dorman] at 18:15 EDT Steve: Other than general code cleanup, I've changed two (2) modules for Booz. The first change was the biggie--booz.c. That's where I've put all the GEM code. The other change was to oozext.c, because Rahul was rather uncleanly (IMHO) exiting after the end of the extraction routine, instead of returning to the calling spot in booz.c. Needless to say, I could extract one (1) file at a time. Just changing the exit(1) to a return (1) at the end of the extract routine did the job. BTW--I replaced the strncat() from Ian's dlibs with the MiNTlibs version, and haven't had any trouble since. His strncat() is definitly broken... I've got the Zoo sources sitting at work. Haven't bothered to bring them home, but I concur, I don't think it'll be too hard, once I get a winx_printf() routine up and running. That seems to be all he uses for output, and thanks to Bill Shroka's method of giving Zoo the ability to do its own filename globbing, the routine to pass args to the zoomain() routine is simplified. I honestly don't think it'll be that hard. It'll be *work*, mind you, but not that hard. John: Ian is on the Internet, maybe. That's the only way I have to get to him as well--finances just couldn't afford BIX on student money. Of course, I just got a bounced message that I sent a day or so ago, so he may have changed addresses as he was threatening to...:-) As regards Chris' question: I did a quick test, and I'm not *sure* that what you propose will work. It should, but the only real shell I have right now is MUPFEL (gotta set gulam back up), and since the HSC pieces crash with that, well, I can't test it. As re: the program, it's Emacs 2.19b. Steve gave me a copy. I like it. Very nice. I don't see myself changing any time soon. Ian could be working from dLibs 1.1 sources. We had some problems with 1.33i and him finding out he didn't have sources to all the stuff that he had object files to. I thought we found most of them, but that doesn't mean that he replaced them...so, how's it feel to be back working on the dlibs chain-gang. Are the fork functions the ones that use ARGV or XARG? Roger on the fclose() warning. Makes sense. I think Ian does most of his stuff with the GEMDOS functions, which may be why he missed it. The FGREP port I did would expect the shell to do wildcarding--it's an almost untouched (may have been totally untouched) port of GNU fgrep, which would expect that. I can certainlu look into putting globbing routines in it. Mike. ------------ Category 3, Topic 5 Message 94 Thu Jul 16, 1992 M.DORMAN2 [Mike Dorman] at 19:09 EDT Chris: Gemini's cool. Time to tweak the binaries, I guess. The window routines just fell together. They're still pretty unsophisticated. Right now, to redisplay the contents, the main app will have to look for a redraw message and do all that stuff itself. If I had C++, I could probably make it otherwise. I think the stuff CBARRON proposed may work--I've got it stored off in a file, and I'm going to hack away at it this weekend. The only problem is, I can't seem to find the vsprintf() object file. Oh, well, it's got to be there somewhere. The sound routines sound like a devilish lot of fun. Make sure to send them to me. There are already makedep programs for creatine makefiles. With some source and the winx_libs, you could probably get it going in a couple of days. The hard part with just makeing an UNlzh will be figuring out which sources to keep and which to ditch. It might just be easier to go whole hog and gemize the whole thing. All: Oh, Ian left some mail in comp.sys.atari.st.tech. His new address is ilepore@[new]nyx.cs.du.edu. I tried some mail today, but it bounced. Time to get Bob Goff to get Ian to send me something so I'll have a guaranteed return path. Mike. ------------ Category 3, Topic 5 Message 95 Thu Jul 16, 1992 M.DORMAN2 [Mike Dorman] at 19:48 EDT Steve: Something odd. In preparation for re-Makeing the binaries for 1.40, I tried them out under Mupfel, just for kicks. They worked. I'm very surprised, since I know for a fact that I haven't already done the rebuild. Any ideas? Mike. ------------ Category 3, Topic 5 Message 96 Thu Jul 16, 1992 C.HERBORTH [-Chris-] at 23:22 EDT Mike, Weird thing re; Gemini is that I haven't had a crash since the _first_ day I installed the beta version of H&S... Very weird. I went back, recompiled the program (typed "make test.mak", same as last time), and it worked flawlessly the dozen or so times I ran it... I wrote a little program to try to track down the problem, no crashes. I wrote a little program to test a section of library code I'd changed (which, BTW, everyone should get in the mail RSN), and no crashes... Weird. Hmm, looks like you've run into my "problem"... Maybe Gemini/Mupfel suddenly decided that Sozobon was fine. That's the sort of voodoo I expect from DOS... If you find any makedep source laying around in your ftp travels, throw it at me! I'll add it to my list of things to hack with... A very useful tool if I can get it working properly! ilepore@[new]nyx.cs.du.edu... That's _weird_. I hope my mailer can deal with that sort of [weird]ness... ;-) The sound routines are going... well, they're going. The guy writing them has a problem, they don't make any noise. They take the proper amount of time, but no sound comes out. Anybody know how to debug Timer A code? He says Templemon can't look at Timer A stuff, since Timer A has a higher priority than the keyboard. (Personally, I don't have a clue! :-) -Chris- ------------ Category 3, Topic 5 Message 97 Thu Jul 16, 1992 C.HERBORTH [-Chris-] at 23:43 EDT Mike, Looks like my H&S1.40 and Gemini/Mupfel problem is time-dependant... I just tried it, and it crashed. The same program that ran this morning and early afternoon (before 2pm) without a bomb... Stranger and stranger... -Chris- ------------ Category 3, Topic 5 Message 98 Fri Jul 17, 1992 S.YELVINGTO2 [Steve] at 04:08 EDT Yeah, there's definitely some weird voodoo going on in Ian's startup code. I think the code I borrowed from MiNTlib fixes most of it, but I did see a couple of bombs on programs compiled with the repaired library. I was in the process of setting up SYSMON to track the problem when my hard drive died. ------------ Category 3, Topic 5 Message 99 Fri Jul 17, 1992 M.DORMAN2 [Mike Dorman] at 20:06 EDT Ooops. Chris: Ian's address is either nyx.cs.du.edu or newnyx.cs.du.edu. Meant for the brackets to be taken in a regex/command line option explanation manner. Sorry. Some days the rest of the world and I just don't mesh. ------------ Category 3, Topic 5 Message 100 Sat Jul 18, 1992 C.HERBORTH [-Chris-] at 00:04 EDT Mike, Oh, duh, silly me... Forgot all about regex... I guess we _were_ talking about your fgrep.. :) I saw a message from Ian today that had "ilepore@nyx.cs.du.edu"... -Chris- ------------ Category 3, Topic 5 Message 101 Mon Jul 20, 1992 M.DORMAN2 [Mike Dorman] at 22:23 EDT Anyone use lread()? I can't seem to get it to read data into a buffer without returning a negative error code. Grrr. It's insane. If I could get that to work, well, I'd be able to get BOOZGEM to save the default source and destination paths. As it is, I can use a binary file editor to do so, but that's not the point. Other than that, things are going fine. Mike. ------------ Category 3, Topic 5 Message 102 Tue Jul 21, 1992 CBARRON at 01:29 EDT I assume lread() is read() with a long buffer length. If so then do you know at least approx. (within 32K) where this data is in the file. if so then an lseek() and read(),write() combo might be a work around. BTW lread() is not 'portable' to my knowledge... ------------ Category 3, Topic 5 Message 103 Tue Jul 21, 1992 M.DORMAN2 [Mike Dorman] at 19:31 EDT Hmmmm. I sort of know where the data is. I could find out for sure, but the prospect of having to one day work around the possibility of the data ending up split across two blocks... Looks like I'm just going to have to be more sophisticated about the process, and use a read()/seek()/read()/write() algorithm. Darn, I was hoping it'd be simple. Mike. ------------ Category 3, Topic 5 Message 104 Wed Jul 22, 1992 S.YELVINGTO2 [Steve] at 03:04 EDT Mike, are you trying to get booz to patch its own binary? The MicroEMACS sources have code to do that. On another topic ... I saw a note on Usenet from somebody who's put together a Borland Graphics Interface library for Sozobon C. Supposedly you can port most PC software that uses BGI with a minimum of hassle. I haven't seen it yet; it's in the pub/atari/new/ directory at atari.archive.umich.edu if anybody wants to check it out. ------------ Category 3, Topic 5 Message 105 Wed Jul 22, 1992 M.DORMAN2 [Mike Dorman] at 19:17 EDT Steve: Yep, trying to save default source and destination paths. The wierd thing is, I was (still am, for that matter) having trouble with lwrite() in my fractal program. I wonder if the functions are just broke? Time to do some serious exploration. In a few days. For the moment, I'm taking some code to allow you to imbed resources in programs and making it work with HSC. Since it's a .o file that you link into the program in question, I wonder if it would be possible to make it a standard part of GemFast. That would be nice. I'm pretty convinced that once all these extension and new library things are integrated into GemFast (assuming they are--I don't see why not), I don't think there'll be a set of GEM libs that do anything nearly as well or easily. Heck, I think that's probably true already. Mike. ------------ Category 3, Topic 5 Message 106 Thu Jul 23, 1992 M.DORMAN2 [Mike Dorman] at 21:43 EDT Interesting Compiler Behavior Report: Well, I found out one interesting thing: If you try to initialize a structure that's declared local to a function (rather than global, etc.), you'll get the compiler to bomb twice. I think that there is a documented warning against this procedure (in relation, at least to autoinitializing strings--but I know that Ian's told me that once, himself), but it's interesting how the compiler handles it :-). Guess I'd better tell Ian. BTW--Ian has out-mail access to the Internet, as ilepore@nyx.cs.du.edu. However, whenever I try to send a message to him, I get a response that indicates that his site doesn't think he exists. I've seen several messages (at least one sent to you, Steve), but I can't even _reply_, much less send a mail with no reply to: field. Anyone got any ideas? For the moment, I got Bob Goff to tell him the situation by way of BIX. Hopefully this'll get straightened out soon. Mike. ------------ Category 3, Topic 5 Message 107 Sat Jul 25, 1992 C.HERBORTH [-Chris-] at 18:53 EDT Mike, I just noticed something that I thought was weird in dLibs... After your lread() problem, I looked, and lread() says: long lread( int h, char *buff, long length ); How come they don't have a FILE h? -Chris- ------------ Category 3, Topic 5 Message 108 Sat Jul 25, 1992 M.DORMAN2 [Mike Dorman] at 21:36 EDT Chris: Good question. There's a whole set of functions which I guess fall under the auspices of , but don't use (FILE *). Uh, open(), close(), read(), write() and their long equivalents are all, I think. Anybody know the great justification? Oh, and I may get the dlibs stuff to you tomorrow. I think I'm going to build one mother of a makefile to recompile all the dLibs stuff. That way, when JLS gets done with his shuffling through the stuff (thank Ghu for John or I might have gotten it into my head to get that far *over* my head (excuse me while I mix metaphors with wild abandon)), I'll be here and ready to go. Well, I haven't been working on BOOZGEM much lately, because it seems that no one has any problems with it...:-). I started tinkering with my fractal program again (Ghu, but I wish I had a 68030...). Looks like this is going to be the impetus to add a whole host of new functions to winx_lib--stuff to handle resizing and other such cruft. Nothing hard to code, but winx_lib depends on some variables in the Window structure that need to be updated when such things happen. A couple of questions of preference: Would people rather keep the strings for the window's name and info-line in the program's data, or as part of the Window structure itself (statically or possibly dynamically allocated)? Or would you like to keep pointers to the data space that the program allocates in the structure. Or would you like to do all the work yourself. I'm thinking of writing some sort of winx_name_printf() function that'll allow you to use a printf string to define the title and info lines. This is just something that occured to me, because my fractal program displays the coordinates of the current fractal in the info line. Thoughts? ********** To the non-HSC users ********* For that matter, does anyone have any code for saving a portion of the screen, and blitting it back in a different place? This is the only big headache in moving this thing to not be dependent on GemFast--I don't like MFDBs, &c. If someone would like, I can ship them the code in a week or so, when it's got a bit more functionality and is a bit cleaned up, and if they want to work to make it more general and less GemFast dependent, I'd be more than willing to help. The only real problem is that I don't have anything other than HSC installed any more, and it's kind of hard to be sure that I've got all the GemFast stuff out if I'm still using GemFast to compile it. Besides, I'd love a co-conspirator. Or, if there's no takers, I may just re- install GNU C and have a go at it myself. Whatever. Mike. ------------ Category 3, Topic 5 Message 109 Sun Jul 26, 1992 STARFALL [Alan] at 01:28 EDT The functions open(), close(), read(), etc., are low-level Unix functions. They're roughly equivalent to the ST's Fopen(), Fclose(), Fread(), etc. Like the ST functions, they use a int as a file handle, rather than a FILE *. Since many C programs were written for Unix, quite a few libraries support the Unix calls on non-Unix machines to make porting Unix programs easier. (Not that it helps all that much....) / / * / Alan * * ------------ Category 3, Topic 5 Message 110 Sun Jul 26, 1992 M.DORMAN2 [Mike Dorman] at 11:27 EDT Alan: I figured on the Un*x derivation, but I will probably never understand why the functionality of these calls wasn't just left to fread/fwrite, etc...I mean, it's not like Un*x has to worry about non-binary mode when stuff's open (or at least I understand that there isn't anything _but_ binary mode)... Oh, well. Mike. ------------ Category 3, Topic 5 Message 111 Sun Jul 26, 1992 STARFALL [Alan] at 12:39 EDT Actually, Unix is older than C, and the STDIO library wasn't added until after C had been out for a while in any case. I believe the first Unix kernel was written in PDP-7 assembly language in 1969. The main reason people still use open() etc. is that they have less overhead than the STDIO library. / / * / Alan * * ------------ Category 3, Topic 5 Message 112 Sun Jul 26, 1992 CBARRON at 20:01 EDT Not to mention that stdio functions in unix are ussually written with the open(),close(),read(),write(),lseek() primitives. Reading a fairly large binary file such as a screen image with stdio library either requires resizing the internal buffer of the stream or a lot of small reads with one function call, while FCNTL lib. functions do it in one swoop... Also I was under the impression that system 7 unix was written entirely in C, except for some kernal table which was assembled, probably to use duplication directives of an assembler to create a table of recurring data easily. C was originally written to write unix in.... Also STDIO io and FCNTL io are part of the C library and not C. C itself does NO IO, making it next to impossible to write useful C code without using libc.a, even if there is no lib calls for any standard arithmetic operation, which there usually is as in long a=4,b=6,c; c=a*b; ------------ Category 3, Topic 5 Message 113 Tue Jul 28, 1992 C.HERBORTH [-Chris-] at 01:20 EDT I think I've found a bug in either TOP or HCC, but I'm not qualified to track it down... It shows up when JAS tries to assemble the .s file created by HCC/TOP, and I know almost nothing about assembly... Who wants to take a look? I've already made an archive with the C source, the .s file generated by HCC/TOP, and the error it produced. It's about 2k. Actually, I'll go out on a limb and say it's a TOP bug. Without the -O (for optimising) switch, there's no problem... Also, I've been playing with the GDOS VDI functions. So far, I've discovered that AMC-GDOS (comes with Gemini) does some funky things to the normal GDOS font commands... Crashes when you do a normal vst_load_fonts( vdi_handle, 0 )... Does anyone have _anything_ (I don't care how gross) that is VDIFAST and uses GDOS? ------ 8< ------- Thanks for the explanation Alan! ------ 8< ------- Mike, My classes are winding down, so I might be fiddling with that frm_dialog code I fiddled with before (JLS gave me a _great_ idea)... Those fixed dLibs should be nice, too... ;-) I had a few bug reports for BOOZGEM, but they vanished when my hard drive got toasted Thursday night (I do backups on _Friday_...). Nothing major, just interface ugliness... ;-) A mixed metaphor is worth two in the bush... I'd like the winxLib stuff to want a pointer to a string... They could stuff this into a part of the Window struct for easier access from sub-routines. I prefer to either delcare my strings in the code or to dynamically allocate them (and sprintf() on the buffer)... re; Other compilers I think I've got a gungy old copy of Laser C laying around somewhere... Haven't used it in years, but that's what I learned the VDI and AES on... -Chris- ------------ Category 3, Topic 5 Message 114 Wed Jul 29, 1992 M.DORMAN2 [Mike Dorman] at 20:18 EDT Chris: Try to send it to Ian. I sent him a message a couple of days ago, and it didn't bounce, but I haven't been into work to find out if there's a reply. TOP occasionally does some dodgy stuff, Ian once said. If it doesn't show up without optimisation, it's prolly a problem. Send me the file and I'll corroborate. Ian's always maintained that some of the VDI stuff ain't quite so stone-cold- reliable as he'd like. Have you tried regular GDOS? Do you have access? If you want to send me something to test that, I've got both normal GDOS and G+plus. Complain about the interface to BoozGEM all you want. I never claimed to have mastered the interface thang. Heck, I can even _fix_ it. Imagine that. B'sides, I've got to finish up the configuration saving stuff and then wade through 800K of Zoo source to try and get subdirectory stuff working. I pretty much decided that I'm going to malloc a buffer and store the pointer in the structure. I fiured that, while I was at it, I'd just drop in a wx_name_printf() command (shouldn't be hard, thank Ghu)--I need that sort of facility for my fractal program, so why not make it generic. Of course, productivity has been for lately. Sick, and then my SO has been in Montgomery taking the Alabama Bar for the last few days. Due back any minute. Thank heavens that's over, it's been pretty tense for both of us. That's why I've been so productive lately, she's been so busy I didn't have anything else to do. And then there was a going-away party for a Creative Writing professor who's a really good friend last night, and I drank too much and hung out with friends and reminisced. Fun, but not too much to show for it. Mike. ------------ Category 3, Topic 5 Message 115 Fri Jul 31, 1992 JLS [John STanley] at 07:53 EDT Mike Dorman, Which version of the libraries are you using when you have problems with lread() and lwrite()? lread() and lwrite() are both just shells for the simple gemdos Fread() and Fwrite() calls with a long buffer size. Could you send a sample of what's failing? ------------ Category 3, Topic 5 Message 116 Fri Jul 31, 1992 M.DORMAN2 [Mike Dorman] at 20:02 EDT John: I'll whip up some examples. I'm using the dLibs that Ian supplied (if they're broke, I might as well find out, I guess). I can't get them to return the correct (according to the docs) error codes, even when they write what I calculate is the correct amount of information... Mike. ------------ Category 3, Topic 5 Message 117 Sat Aug 01, 1992 C.HERBORTH [-Chris-] at 13:57 EDT Mike, Ok, I'll send you that file... It's broken code, but it's useful for finding that TOP weirdness... ;-) I'll probably send it to Ian, too... He's probably the most familar with TOP's code. Oh, I got the GDOS stuff going, as my message in the Ask _ANY_ Programming Question TOP indicates... -Chris- ------------ Category 3, Topic 5 Message 118 Sun Aug 02, 1992 M.DORMAN2 [Mike Dorman] at 19:33 EDT I've uploaded version 1.0 of wx_lib. It includes source, object libraries for both GCC 2.1 and HSC 1.4/1.33i, source to a test/example program, binaries of the example program, produced with GCC and HSC, and some documentation that would kindly be called, er, sketchy. It'll get better. Check it out, make suggestions, delete it from your HD, whatever. Mike. ------------ Category 3, Topic 5 Message 119 Wed Aug 05, 1992 JLS [John STanley] at 05:57 EDT Mike Dorman, >I can't get them to return the correct (according to the docs) error >codes, even when they write what I calculate is the correct amount of >information... Huh??? Err... What "error codes" are you expecting? When they work ok, they just return the number of bytes they wrote, no error codes.... ... JLS ------------ Category 3, Topic 5 Message 120 Wed Aug 05, 1992 M.DORMAN2 [Mike Dorman] at 19:35 EDT Sorry, John, I phrased that badly: When I use lwrite(), I consistently get negative error codes, even when the function seems to write the correct number of bytes. So I get error codes, when there doesn't seem to be an error condidtion--and the codes are usually -29xxx or so... Mike. ------------ Category 3, Topic 5 Message 121 Wed Aug 05, 1992 C.HERBORTH [-Chris-] at 20:45 EDT Mike, I'm downloading your wx_lib later... "Bugs found, suggestions made, while-U- wait" :-) Oh yah, I should study for those things... what were they called? "Exams"? Hmm... I can't remember, but I could probably quote some pretty vile theory to you... -Chris- ------------ Category 3, Topic 5 Message 122 Thu Aug 06, 1992 E.SMITH10 [Eric Smith] at 00:44 EDT Mike: Did you remember to declare lwrite() as "extern long lwrite()"? If not, Sozobon may well think that it is returning an "int", and then will proceed to sign-extend the low order 16 bits. This could account for the negative numbers you're getting back, depending on how many bytes you were writing (i.e. if it was more than 32767 bytes). ------------ Category 3, Topic 5 Message 123 Thu Aug 06, 1992 M.DORMAN2 [Mike Dorman] at 10:12 EDT Eric: I refuse to believe that it's something so bloody inconsequential as that. Having said that, I will admit to having gotten in a a horrible habit or just including relevant header files and never worrying a second about "extern"ing anything. Comes from much too long using GNU C, where that was all you had to do. Mike. ------------ Category 3, Topic 5 Message 124 Wed Aug 12, 1992 JLS [John STanley] at 07:08 EDT Mike, Sorry Mike, I have no idea why lwrite is returning negative error codes on your machine. Are you 100% sure you're passing the right size values for each of the parameters? The last time I had something like that happen to me, it was a long time ago, but I think I was either passing it a sizeof(struct) which needed to be cast as a (long) to work properly with lwrite/lread, -or-, forgetting to declare lread as a function returning a long. Could you construct a tiny (5-10 line) sample and email it to me to see if I can get the same results? ... JLS ------------ Category 3, Topic 5 Message 125 Wed Aug 12, 1992 M.DORMAN2 [Mike Dorman] at 19:57 EDT JLS: I guess we're Alladin Lagging at each other. I'm apt to believe that Eric Smith's right when he suggests that maybe I didn't cast the function, and thus was getting erroneous results. I'll check though, though it'll prolly be a few days, since I'm moving Friday... Mike. ------------ Category 3, Topic 5 Message 126 Sat Aug 15, 1992 C.HERBORTH [-Chris-] at 12:26 EDT Does anyone else compile programs in the console window of Gemini? A nifty "feature" of Sozobon under Gemini is that you get a sort of progress display as it compiles... Little inverse spaces (ie, black boxes) appear for ever n lines processed. Kinda neat, it's a pity they don't show up under Mupfel... -Chris- ------------ Category 3, Topic 5 Message 127 Wed Aug 19, 1992 S.YELVINGTO2 [Steve] at 01:45 EDT Heh... Those progress bars are an unintended feature. The compiler is throwing nuls at the console so that it can be interrupted by ctrl-C. Apparently the Gemini VT52-to-GEM driver replaces unknown bytes with black cells. Looks nifty. I thought Ian was doing it on purpose until I ran the compiler from MicroEMACS instead of from Gemini and found that it didn't happen. ------------ Category 3, Topic 5 Message 128 Sat Aug 22, 1992 C.HERBORTH [-Chris-] at 16:24 EDT Steve, Ah, so they're an accident... Still cool! Very reassuring when you're compiling something large... I missed them when I started using Mupfel again (I really need to go to 4M soon)... -Chris- ------------ Category 3, Topic 5 Message 129 Wed Oct 07, 1992 C.HERBORTH [-Chris-] at 19:30 EDT Has anyone heard from Ian Lepore or John Stanley lately? I've got a few questions, and I think I've found a bug in the dLibs fread/fwrite in binary mode (haven't had time to track it down)... Hello? Is anyone there? :-) -Chris- ------------ Category 3, Topic 5 Message 130 Wed Oct 14, 1992 S.YELVINGTO2 [Steve] at 13:17 EDT I haven't seen anything on Usenet from Ian in quite awhile, Chris. JLS is around -- try sending him a note in GEnie mail. My hard disk system is still kaput, so I'm not doing anything with Sozobon at the moment. ------------ Category 3, Topic 5 Message 131 Sat Oct 17, 1992 S.SCHAPER [Meneldil] at 12:26 EDT Steve, Your hard drive is down! What a bummer! If you need something compiled, I have it, you'll have to tell me how to use it :-) ------------ Category 3, Topic 5 Message 132 Sat Oct 17, 1992 C.HERBORTH [-Chris-] at 19:23 EDT Steve, I got a message from Mike Dorman (via his girlfriend's email account in Boston) this week! I haven't heard back since... I'll ask him to get Ian to email me from his account again. I saw a message from someone I assume to be one of the Bix beta testers... He posted a bit of source compiled with H&S Sozobon 1.44i (!)... Are you still looking for a case/power supply? I've got a custom case that will take two 5.25" HH devices and has a nice power supply. It's also got four switched outlets on the back with lit switches on the front... I'd be quite happy to get $75 for it if you're interested... -Chris- ------------ Category 3, Topic 5 Message 133 Tue Oct 20, 1992 S.YELVINGTO2 [Steve] at 03:19 EDT I got a good deal on an old Supra case ... only to discover that the (secondhand) Seagate N-series drive that I've been using has decided that its usable life is over. Sigh. I haven't replaced it because I (and my bank account) have been too busy with real-life concerns, like a new baby, serious car repairs, etc. And, now that it's cold outside, heating bills -- we have an inch of snow outside right now, and the ski lift just north of us opened this weekend. Seriously. ------------ Category 3, Topic 5 Message 134 Wed Oct 21, 1992 S.SCHAPER [Meneldil] at 01:47 EDT Steve, Which ski lift is that? Snow! I hadn't heard. Congrats on the new baby!!! Anything interesting from Mast + this past year? ------------ Category 3, Topic 5 Message 135 Thu Oct 22, 1992 S.YELVINGTO2 [Steve] at 02:39 EDT Wild Mountain, north of Taylors Falls. Haven't heard anything from MAST+ lately. I haven't been to a meeting since you left town. ------------ Category 3, Topic 5 Message 136 Thu Oct 22, 1992 S.SCHAPER [Meneldil] at 07:09 EDT Wild Mountain. Can't place that one. Unless it has a billboard for a waterslide. Makes sense that it's north of town. Here I am at four in the morning studying for a final. What a deal. ------------ Category 3, Topic 5 Message 137 Sat Oct 24, 1992 C.HERBORTH [-Chris-] at 22:34 EDT Steve, Yikes! A new baby (congrats!) and _snow_! It's cold up here, but no snow (that stayed) yet... I think I'll try to get my hands on John STanley... He's probably the best person to look for this bug I think I've found (dLibs fread() or fwrite() bug! uh-oh!). I can definitely sympathise with your tight budget... -Chris- ------------ Category 3, Topic 5 Message 138 Fri Dec 11, 1992 K.HOUSER [Kevin MQ Def] at 13:26 EST Guys, Why does Sozobon clean the SP by doing things like the following addq.w #4,sp Rather than... addq.l #4,sp It seems that adding words rather than longwords could cause some problems. Thanks, --Kevin ------------ Category 3, Topic 5 Message 139 Fri Dec 11, 1992 W.PARKS3 [Dr. Bob] at 18:52 EST Kevin, Due to habit, I always code it "addq.l #n,sp" rather than the 'word' size you mentioned but.... it _is_ totally legal to use word size instructions. To quote Motorola'a MC68000 user's manual: ADDQ: Add the immediate data to the operand at the destination location. The data range is from 1 to 8. The size of the operation may be specified to be byte, word or long. {now here come the good part, continuing with their quote} Word and Long operations are also allowed on the address registers... ... The entire destination address register is used regardless of the operation size. {end quote} This means that ADDQ.W #n,An will add a WORD but it will use the whole 32 bits of the ADDRESS register when adding (meaning that any roll-over will be carried up into the hi-word of the register). Yeah- it looks that way to me too. Why bother specifying the size when using address registers, eh? I mean.... it's not like you could addQuick a negative number or anything. :-) Bye: Dr. Bob ------------ Category 3, Topic 5 Message 140 Fri Dec 11, 1992 K.HOUSER [Kevin MQ Def] at 19:25 EST Dr. Bob, [8') I'll, chalk that one up to failing memory from my 68k class in college back in '87. --Kevin ------------ Category 3, Topic 5 Message 141 Sun Dec 13, 1992 STARFALL [Alan] at 06:06 EST I don't know how the 68000 handles it internally, but effectively, the .w and .l are equivalent for ADDQ when used on an address register. That weirded me out when I first saw it, too. The entire address register is always affected with any operation on it. / / * / Alan * * ------------ Category 3, Topic 5 Message 142 Sun Dec 20, 1992 C.HERBORTH [-Chris-] at 23:29 EST I noticed that GEMFAST 1.8 has made it into the library here... Have any of the other H&S Sozobon 1.40i beta testers heard from _anyone_ at all about a possible release date? I haven't heard from Ian Lepore in months. Is his Nyx account still active? I've got Hermes UUCP running on my ST now, so I should be able to contact him here. -Chris- cherborth@semprini.tdkcs.waterloo.on.ca ------------ Category 3, Topic 5 Message 143 Mon Dec 21, 1992 EXPLORER.5 [Robert Goff] at 21:59 EST Ian is pretty busy on a Falcon project, but if you don't get a response on his Internet mail account I can get a message to him on BIX. |) | |)O|) Robert Goff ------------ Category 3, Topic 5 Message 144 Mon Dec 28, 1992 C.HERBORTH [-Chris-] at 23:53 EST Bob, I got Internet email from Ian Lepore the other day... Quite a surprise! :-) He's re-validated his account on Nyx, and should be more "alive" again in a little while... He's working on something for the Falcon... An update of one of the coolest paint/animation programs available for the ST... -Chris- ------------ Category 3, Topic 5 Message 145 Fri Jan 15, 1993 S.SCHAPER [Meneldil] at 19:24 EST Is this where to discuss Heat n Serve C and the shells for that and Sozobon? ------------ Category 3, Topic 5 Message 146 Sun Jan 17, 1993 J.FOY2 [JLF] at 06:05 EST s.scraper I hope this the place. Help! Can some tell me step by step, how to get a simple program complimed with heat and serve C. Like printf("hello"); ------------ Category 3, Topic 5 Message 147 Sun Jan 17, 1993 S.SCHAPER [Meneldil] at 12:02 EST JLF, Download the PWCSHELL here in the libraries. Then run it, set up the CC and the Defaults in the leftmost menu. Then run CC in the middle menu. If your code is good, then it should work. ------------ Category 3, Topic 5 Message 148 Sun Jan 17, 1993 J.FOY2 [JLF] at 23:43 EST Thanks! ------------ Category 3, Topic 5 Message 149 Tue Jan 19, 1993 S.YELVINGTO2 [Steve] at 02:56 EST > Can some tell me step by step, how to get a simple program >complimed with heat and serve C. Like printf("hello"); There's no need for a shell. 1) Download Heat and Serve C. 2) Unarchive it. 3) Run INSTALL.TOS to install it on your system. In addition to unpacking the files and creating the directories, it will put an environment-setting utility in your /auto/ folder and modify your DESKTOP.INF file. Reboot when you're done with INSTALL. 4) Write your C program using any text editor. 5) Double-click on the .C file. HSC will compile it. If you want to write multi-module programs, read the documentation and learn to write .MAK files. ------------ Category 3, Topic 5 Message 150 Tue Jan 19, 1993 S.SCHAPER [Meneldil] at 23:34 EST Steve Y, Thanks! I am running into C dialect incompatibilities, so I've actually started to look at the docs This is absorbing. BTW, in addition to HnSC, are there any other library files that I should have? I have run into non-existant include files. (compiling source from others, my own program compiles - with the guts of it commented out. HiSoft C Interpreter/editor gives it an ok, it compiles just fine, but then it crashes when run. Whee! Lots to learn yet! ------------ Category 3, Topic 5 Message 151 Wed Jan 20, 1993 STARFALL [Alan] at 12:30 EST What are the names of the missing #inclue files? The crashing-when-run problem is almost always caused by a pointer that's not initalized, or getting pointers and ints mixed up in a function call. / / * / Alan * * ------------ Category 3, Topic 5 Message 152 Thu Jan 21, 1993 M.SLAGELL [Mark] at 21:32 EST Has anyone else had trouble setting environment variables via $(SETENV) in the new STMAKE? Methinks Ian L. only did his testing with GEMENV installed. ------------ Category 3, Topic 5 Message 153 Sun Jan 24, 1993 EXPLORER.5 [Robert Goff] at 13:16 EST How are you setting the variables, and when are you trying to use them relative to running STMake? I have a sneaking suspicion that any environment variables created in STMake disappear when it terminates. |) | |)O|) Robert Goff ------------ Category 3, Topic 5 Message 154 Sun Jan 24, 1993 M.SLAGELL [Mark] at 17:40 EST Robert: >How are you setting the variables, and when are you trying to use them >relative to running STMake? I have a sneaking suspicion that any environment >variables created in STMake disappear when it terminates. Yes, they're supposed to disappear when ST Make terminates. That's fine with me, and it's not the problem. In the MAKE.INI file try something like this (with GEMENV not installed): .INICMDS: showenv $(SETENV) TMP=M: showenv (SHOWENV.TOS is the environment viewing utility distributed with Heat and Serve C.) When I run this, SHOWENV first shows the default environment set up by the desktop: PATH=C:\ After ST Make tries to add the TMP variable to the environment, SHOWENV says only: env Not only does it not get the new variable, it corrupts the old one. ST Make still works fine with GEMENV installed, but I'd rather not use GEMENV because it screws up something else I can't live without. (Not GEMENV's fault, I'm sure, but you know how that is.) -- Mark ------------ Category 3, Topic 5 Message 155 Mon Jan 25, 1993 EXPLORER.5 [Robert Goff] at 23:39 EST Ah. Then I can't offer any help -- I've never used STMake. Good luck. |) | |)O|) Robert Goff ------------ Category 3, Topic 5 Message 156 Fri Apr 02, 1993 S.YELVINGTO2 [Steve] at 04:12 EST Here's something Ian posted on Usenet that bears repeating: From: ilepore@nyx.cs.du.edu Organization: Nyx, Public Access Unix at U. of Denver Math/CS dept. Subject: Re: HSC atol function > HSC 1.40 atol() and strtol() broken I'm not sure about atol(), but a bad old version of strtol() found its way into the v1.40 release. (mea culpa). Here's a version of strtol() that should work: #include #include #include /* * note: For strict ANSI conformance, these functions need overflow * checking and should set errno. */ static char digits[] = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; unsigned long strtoul(string, pnextchar, base) char *string; char **pnextchar; int base; { register char *p; register char *numstr = string; register int nconv = 0; register int neg = 0; register unsigned long value = 0; register unsigned long lbase = base; register char *pdigits = digits; if (base < 0 || base == 1 || base >= sizeof(digits)) { goto BADBASE_EXIT; } while (isspace(*numstr)) { ++numstr; } if (*numstr == '-') { neg = 1; ++numstr; } else if (*numstr == '+') { ++numstr; } if (lbase == 0) { if (*numstr == '0') { ++numstr; if (toupper(*numstr) == 'X') { ++numstr; lbase = 16; } else { ++nconv; // a standalone 0 counts as 1 converted digit! lbase = 8; } } else { lbase = 10; } } else if (lbase == 16) { if (numstr[0] == '0' && toupper(numstr[1]) == 'X') { numstr += 2; } } while (NULL != (p = memchr(pdigits, toupper(*numstr), base))) { ++numstr; ++nconv; value = (value * lbase) + (unsigned long)(p - pdigits); } if (nconv == 0) { value = 0; numstr = string; } BADBASE_EXIT: if (pnextchar) { *pnextchar = numstr; } return (neg ? -value : value); } long strtol(string, pnextchar, base) char *string; char **pnextchar; int base; { return (long)strtoul(string, pnextchar, base); } ------------ Category 3, Topic 5 Message 157 Fri Apr 02, 1993 MIKE.DORMAN [Slammo] at 18:50 EST Steve: When did Ian post this? I just got the message that there was a problem today. Is BU's Usenet that screwed? BTW, how's the HD? Mike. ------------ Category 3, Topic 5 Message 158 Sat Apr 03, 1993 S.YELVINGTO2 [Steve] at 20:50 EST No hard drive yet, Mike. I supposedly have one coming from a guy in Colorado. It's an unused Seagate 20-meg N-series -- cost me all of 45 bucks. Assuming it gets here. The seller is a Mac user @aol.com. ------------ Category 3, Topic 5 Message 159 Sat May 29, 1993 C.HERBORTH [-Chris-] at 11:45 EDT Hi folks and friends, This will probably be the last you see of me in the ST RT... Since I got my UUCP feed, I haven't been using GEnie very much. If anyone wants to contact me, try sending Internet (USENET/unix/whatever _you_ happen to call it) email to: cherborth@semprini.tdkcs.waterloo.on.ca Just thought I'd let you all know (as a H&S C beta tester)! :) -Chris- ------------ Category 3, Topic 5 Message 160 Mon May 31, 1993 S.SCHAPER [Meneldil] at 18:19 EDT Well, I'm back to trying to teach my self C. In addition to the tutorial in the manual, what other book would you most recommend to teach a programming neophyte C? Sort of figured out scanf the other day. Still am confused on For loop structures. ------------ Category 3, Topic 5 Message 161 Thu Jun 03, 1993 J.KRZYSZTOW [JEFFREY] at 00:30 EDT S.SCHAPER [Meneldil] I would highly recommend Clayton Walnum's C-Manship Complete. It will take you through learning about C in general and then learning about programming GEM based programs in C. If you happen to be in the Kansas City Area June 26 or 27, Taylor Ridge Books will be at the Kansas City AtariFest'93 and you can pick up a copy then. Jeffrey ------------ Category 3, Topic 5 Message 162 Sat Jun 05, 1993 S.YELVINGTO2 [Steve] at 03:15 EDT Take scanf out and shoot it! Seriously, the world would not be materially harmed if scanf were removed from the C standard library. It's dangerous. Avoid it. Steve, I can only tell you what I found useful: -- Kernighan and Ritchie. You might as well start with this, because you're going to have to deal with it sooner or later. -- Alan Holub's "C Chest." Holub is a very readable, human writer who used to have a column on C in Dr. Dobbs' Journal. He's not a compsci guy; his background is in the humanities. He explains well. -- Dale's source code to dLibs. OK, it's not a book, but it's really, really useful. It also helped to have Dale and JLS on the other end of the telephone line! There's an appendix on C in the back of Andy Tanenbaum's Minix book ("Operating Systems Design and Implementation") that's a very clear and very short overview of C. A lot of people recommend books by Herb Schildt. If you've read one, you've read most of them all -- he's the master of recycling. He's worth reading if you can check him out of a library, but take everything with a grain of salt -- he's dangerously sloppy. You know what I really think helped me? A decade ago I read a book entitled "Pascal for Basic Programmers," published by Addison-Wesley. It did a pretty fair job of outlining the basics of Dr. Wirth's theories on software development. Once you get the general idea of how to lay out a program in pseudocode, then progress toward a real program by stepwise refinement, you're well on the way to understanding C or any other procedural programming language. Don't rush out and buy a bunch of books until you take advantage of the library! Most of the books I've collected sit up on the shelf covered with dust. Steve Yelvington Marine on St. Croix, Minnesota ------------ Category 3, Topic 5 Message 163 Sat Jun 05, 1993 S.SCHAPER [Meneldil] at 17:06 EDT Steve, Well, I'm obviously trying to run before I've learned to crawl. . . All the local library system had was _Teach Yourself C_ which I've got a hold order for, and _Atari ST Applications Programming_, for which I am not yet ready, although I did check it out. I've got the Microsoft C Bible, which probably doesn't really apply. ------------ Category 3, Topic 5 Message 164 Sun Jun 06, 1993 A.FASOLDT [Al Fasoldt] at 03:23 EDT Meneldil, The C Trilogy is excellent, from (I think) Tab Books. Al ------------ Category 3, Topic 5 Message 165 Tue Jun 08, 1993 J.ROY18 [Jonathan] at 23:52 EDT Scanf is evil... You just need cin and cout. :D I wish there was a 1meg C++ compiler for the ST. It's so cool. -- I'd also recommend the 2nd ed of the K&R book. It's a great reference. C++ Primer is so fantastic, I assume C Primer is also good, if you want to check it out. -- If you have the memory for GNU C, though, bypass C and buy C++ Primer, and learn the language of power. :D ------------ Category 3, Topic 5 Message 166 Wed Jun 09, 1993 S.SCHAPER [Meneldil] at 01:03 EDT Jonathan, What I have is the Hi-Soft C editor/interpreter, and Heat n Serve C. 4 megs RAM. Shouldn't one learn C before C++? cin and cout? Not in the list of functions in the manual I have. ------------ Category 3, Topic 5 Message 167 Wed Jun 09, 1993 S.YELVINGTO2 [Steve] at 03:20 EDT I wouldn't get into C++ before C ... but perhaps I say that because I haven't. ------------ Category 3, Topic 5 Message 168 Sun Jun 13, 1993 J.ROY18 [Jonathan] at 12:29 EDT Well, I started learning C, but then jumped to C++. I'm glad I did. C is so incredibly crippled, I don't see how people can program in it. :) C++ is definatly the way to go! (You'd have to get gcc though... It's up to 2.4.1 in binary form now.) There is a thread on comp.land.c++ about which to learn first, and most people it's best to learn C++ instead of C then C++. Of course, if you need to know C for whatever reason, then go for it. :) -- I'm just in love and awe of object-oriented programming. It's very powerful. cin and cout are C++ functions... You can do neat things like have 'input' declared as a file and go: input >> a >> b >> c >> d Where a-d are varibles. It doesn't matter if they are integers, strings, floats, or whatever. C++ will figure it out for you, based on the varible types of a-d. If a is an integer, and you try to load a char, it'll convert it to integer automagicly. Same goes for output as well. :) cout << x Will print x to the console, regardless of its type. (There are various formatting options as well, of course, this is just a simple example.) printf/scanf/etc are a thing of the past. :) ------------ Category 3, Topic 5 Message 169 Tue Jun 15, 1993 S.SCHAPER [Meneldil] at 19:19 EDT Jonathan, What book teaches you to program in C++? ------------ Category 3, Topic 5 Message 170 Wed Jun 16, 1993 J.ROY18 [Jonathan] at 23:06 EDT I'm using C++ Primer, and highly recommend it. Of course, my real secret is nightly chats on IRC with a super-guru C++ programmer. :) Still, the book is very useful, and very clear. ------------ Category 3, Topic 5 Message 171 Sat Jun 19, 1993 S.SCHAPER [Meneldil] at 02:58 EDT IRC? ------------ Category 3, Topic 5 Message 172 Tue Jun 22, 1993 S.YELVINGTO2 [Steve] at 02:47 EDT IRC is some sort of Internet chat system to which we mortals cannot aspire. ------------ Category 3, Topic 5 Message 173 Thu Jun 24, 1993 J.ROY18 [Jonathan] at 02:35 EDT Internet Relay Chat. :) It's a giant RTC of sort, with an unlimited number of channels. There are at least 600 people on there at any one time, sometimes over 1500. (Worldwide) Pretty cool! ------------ Category 3, Topic 5 Message 174 Sun Sep 12, 1993 R.WHITTAM [Ron - ABUG] at 02:01 EDT Any chance of a SOZOBON C 3.0 that is ANSI compliant?????? Ron - ABUG ------------