plogan@mentor.com (Patrick Logan) (10/13/90)
I'd appreciate receiving bits of history and words of advice wrt Actor, particularly Actor 3.0. What problems/limits have you run into. What are the great things about it. Etc. Note: I'm asking about the product Actor from The Whitewater Group, not the actor language research at MIT! Thanks -- Patrick Logan, uunet!mntgfx!plogan Mentor Graphics Corp. 8500 SW Creekside, Beaverton, Oregon 97005-7191
pcb@cacs.usl.edu (Peter C. Bahrs) (10/13/90)
>From: plogan@mentor.com (Patrick Logan) > >I'd appreciate receiving bits of history and words of advice wrt >Actor, particularly Actor 3.0. What problems/limits have you run into. >What are the great things about it. Etc. > >Note: I'm asking about the product Actor from The Whitewater Group, >not the actor language research at MIT! > I don't think the name similarity is by accident. I like Actor and the philosophy for OO design and programming. The documentation is very good and the base system is very powerful. You are presented with an interactive development and debugging environment. You can easily change methods and code and quickly rerun them. Each application will produce and prog.exe and a prog.ima file. Both must be present to run these standalone and they are about 250k I think. This seems kind of clumsy. I suspect one module is a binary encoding of the program and the other is an interpreter that reads the binary encoding (ima) file and calls sdk type calls. I have rewritten several base classes to closely reflect the new features in win 3.0 such as track menus. There is a debuggin anomoly in actor though. If you app barfs on something the debugger pops (another application). This does not step-lock your program though and it will still try to process window manager messages such as PAINT. If your PAINT routine uses values that were bad, BOOM. bye bye actor. (Try just hitting return on the barchart demo without entering values for numbers. Then move the debugger when it comes up !) I understand why this happens and there are two solutions 1) Do value checks on your variables (of course) 2) Redo some internal's such as the way the debugger reacts with your application. This is what I am about to finish. Basically, your app freezes until the debugger sayso on. hhhhhuuuuu. well there is also the graphics classes which I can't (do not want to) afford yet. I have been using Actor for 2 months solid. I have a 30000 line SDK and C application and I am evaluating the ability to perform the same tasks in Actor. Peter
kevin@msa3b.UUCP (Kevin P. Kleinfelter) (10/15/90)
plogan@mentor.com (Patrick Logan) writes: >I'd appreciate receiving bits of history and words of advice wrt >Actor, particularly Actor 3.0. What problems/limits have you run into. >What are the great things about it. Etc. I found it had an annoying tendency to hang my machine. Little things like entering example code from the manual should not force a reboot! I sent it back. Here is a portion of a memo to my manager on the topic: ======= Here is why we are returning Actor: * No screen painter. The salesthing said it has one. The only one I can find is a dialog editor, and the Windows SDK provides one already. * The "wordAt" function does not behave as documented. This function supposedly provides access to data located at any address. If it is passed an address outside of the data area for the executing program, it hangs the system. (Probably a Windows 386 mode restriction, but there is no mention of this in the doc.) * Setting "NMIBreak=1" in WIN.INI does NOT enable Ctrl-Alt-SysRq to trap to the debugger. It is documented to do so. * Error messages are terrible. For example, loading a DLL, where a function referenced in Actor is not in the DLL produces the message "Can't convert to Windows short argument". * No support for any DBMS; we would have to write it. * Not possible to switch Actor to another project/program without restarting Actor. * One must copy ACTOR.EXE and ACTOR.IMA from a backup copy in order to get back to a "clean" environment. ===== They took it back very nicely after a little delay. -- Kevin Kleinfelter @ Dun and Bradstreet Software, Inc (404) 239-2347 {emory,gatech}!nanovx!msa3b!kevin "Don't hold your finger on the button if the motor ain't goin' roundy-roundy."
patrickd@chinet.chi.il.us (Patrick Deupree) (10/15/90)
In article <16477@rouge.usl.edu> pcb@cacs.usl.edu (Peter C. Bahrs) writes: >I don't think the name similarity is by accident. You're probably right. However, the part line at Whitewater is that "they didn't have MIT in mind when they named it." >Each application will produce and prog.exe and a prog.ima file. Both >must be present to run these standalone and they are about 250k >I think. This seems kind of clumsy. I suspect one module is a >binary encoding of the program and the other is an interpreter that >reads the binary encoding (ima) file and calls sdk type calls. You're right. That's exactly what it does. As for clumsy, it's really not any more clumsy than any of the other interactive development tools for Windows. Well, any of the ones that currently exist, that is. @:) -- "What's in a name? That which we call a rose by any other name would smell as sweet." William Shakespeare Patrick Deupree -> patrickd@chinet.chi.il.us (708) 328-3800 (Please note there are both a patrick and a patrickd at this site)
patrickd@chinet.chi.il.us (Patrick Deupree) (10/21/90)
In article <1413@msa3b.UUCP> kevin@msa3b.UUCP (Kevin P. Kleinfelter) writes: >* No screen painter. The salesthing said it has one. The only one I can > find is a dialog editor, and the Windows SDK provides one already. That's interesting. I don't remember any of their sales literature having a reference to a screen painter. Maybe the Resource Toolkit. >* The "wordAt" function does not behave as documented. This function > supposedly provides access to data located at any address. If it is > passed an address outside of the data area for the executing program, > it hangs the system. (Probably a Windows 386 mode restriction, but > there is no mention of this in the doc.) Hmm. I know I've used this function a bit and it worked for me. However, I do know of a few customers that did have some trouble, though it mostly seemed to deal with getting data that wasn't really at that address. >* Setting "NMIBreak=1" in WIN.INI does NOT enable Ctrl-Alt-SysRq > to trap to the debugger. It is documented to do so. This was due to some stupidity in the art of communications. I'm afraid that the Ctrl-Alt_SysRq feature used one of the interrupt vectors. Unfortunatly, when running Windows 3.0 in enhanced mode, this doesn't work because you can't reset interrupt vectors (from a high level program). I even told the testing department this, but it didn't seem to reach documentation. >* Error messages are terrible. For example, loading a DLL, where > a function referenced in Actor is not in the DLL produces the > message "Can't convert to Windows short argument". I have to defend them here and say that the error messages in any development system I've used are pretty bad. I've seen systems where every error says "segmentation fault" and I've seen others that tell you an error is in one place when it's actually 400 lines up. >* No support for any DBMS; we would have to write it. And you probably won't see any for quite a while. This is another topic that I got on their case about and nobody seemed to listen. Too bad for them. >* Not possible to switch Actor to another project/program without > restarting Actor. I can't support this as a "complaint" really. You can't switch to another project easily, but you can switch. However, I did find myself with quite a few "Fred" icons since I had 5 projects going on at once usually. >* One must copy ACTOR.EXE and ACTOR.IMA from a backup copy in order > to get back to a "clean" environment. Actually, it's only the Actor.ima that you have to copy. Actor.exe will only get messed up if your disk has a problem. If you want to strip out extra resources that you've added just use the actor.rc file to reset it. Actor certainly does have its problems, but it's great for students that want a cheap system for Windows development and for commercial developers/ corporations that want a quick, but complete system as Actor will cut development time in half. However, if you want database support and a screen painter, I'd look at Object/1. If they havn't released the Windows 3.0 version yet, they should be doing so soon. I'd also recommend looking into SmallTalkV/PM as it should be out in December. If they follow suit with previous versions, you should be able to compile SmallTalk programs into binary, native code (e.g. fast and efficient). Patrick Deupree DKW Systems Corporation -- "What's in a name? That which we call a rose by any other name would smell as sweet." William Shakespeare Patrick Deupree -> patrickd@chinet.chi.il.us (708) 328-3800 (Please note there are both a patrick and a patrickd at this site)